Programming the Acramatic 950 control?

Boss ended up buying a machine with an Acramatic 950. Need to know the ins and outs of this control. Are there things it can't do vs fanuc controls? I was told it was very capable and could do scaling, macros, subroutines, etc. I still don't have a G/M code list to know how different it is and still not sure how we will handle the post processor issues for MCX5. I know we don't have one though!

main difference is arc centers need to be specified in absolute terms from program zero, not incremental distance from current location, like most controllers.
good luck with memory limitations....

Might help if we know the machine, too!

Don't even try to run a Fanuc post on it. It took months for Ezcam and Featurecam to get me a true working post when the 950 came out and still the out of the box post need a lot of work. Bite the bullet and let mastercam build yours for what you need.

Gee, is there not an MCX post that is close enough to work with? Never had someone do a post from scratch (which they won't, but will make it seem that way!). How bad will that hurt? (ballpark)

Is there a good place to gather resources and info on these controls? I find it hard to believe the control cannot operate as incremental, only absolute?

I know the Dynapath stuff we mess with is quite different but really just as capable and sometimes easier to work with. More canned stuff and routine cycles.

As far as memory, I believe it had 75,000ft of tape (virtual tape, lol). I understand that to be about 9megs of storage?

You could try emastercam but proceed with caution.

mkd said:

main difference is arc centers need to be specified in absolute terms from program zero, not incremental distance from current location, like most controllers.
good luck with memory limitations....

Click to expand...

huleo said:

Is there a good place to gather resources and info on these controls? I find it hard to believe the control cannot operate as incremental, only absolute?

As far as memory, I believe it had 75,000ft of tape (virtual tape, lol). I understand that to be about 9megs of storage?

Click to expand...

you would be correct in finding that hard to believe. But that's not what i said. i was talking about how arc centers are specified compared to most Fanuc based controls.
IIRC large programs need to be chopped into smaller segments due to buffer constraints of old_a$$ architecture.

mkd said:

you would be correct in finding that hard to believe. But that's not what i said. i was talking about how arc centers are specified compared to most Fanuc based controls.
IIRC large programs need to be chopped into smaller segments due to buffer constraints of old_a$$ architecture.

Click to expand...

But this is a simple setting in most CAM softwares, is it not? Select absolute for arcs? Or maybe I don't totally understand this issue. Sample code to help understand?

Regarding memory, this has nothing to do with buffer or processing unless I again do not understand. You have a program in hard memory but the control still needs to bring each block in and digest it for motion. Are you saying the processing speed is limited? You would usually only break up a program if the memory is limited?

you got it, buddy. :-)
it is an easy change in most cam systems.

not saying the control has a hard time to munch each block, just that on larger programs, the control needs to break it into segments the size of one of the buffers. when that buffer is completed the control seamlessly switches to the other buffer with the next segment.... If I Remember Correctly.

another difference are commets also mentioned on other threads here that you can search. no parenthesis used; they have to be started with "MSG;"

Again, it would be great to see an example of this to better understand. I can specify how many characters per block in a program but I have not heard any specs for the control. I have heard others specify their block/sec rate with up to 27 characters/block. This type of data would sure be helpful to optimize performance!

OH, upon further thinking of what you said, you are actually talking about the buffering of the program to part memory? No other program processing issues during making an actual part? I am sure we can figure out something on the transfer issues. Have some sharp computer guys to work on it.

huleo said:

, you are actually talking about the buffering of the program to part memory? No other program processing issues during making an actual part? I am sure we can figure out something on the transfer issues. Have some sharp computer guys to work on it.

Click to expand...

BINGO!


"sharp computer guys"
LoL your average 20-something IT geek will be about as useful as a bag of rocks.
what we need is a crusty 60y.o. machinist that has a better memory than me.

mkd said:

BINGO!


"sharp computer guys"
LoL your average 20-something IT geek will be about as useful as a bag of rocks.
what we need is a crusty 60y.o. machinist that has a better memory than me.

Click to expand...

What I've got is a 40 something professional engineer with a hobby in writing source code, writing code for PLCs and controllers, and building ground up PCB assemblies. I assure you, he has amazed me a few times but is blood so what can I say......lol

right now, I am specifically looking at this control for processing speed and look ahead ability as with a few other controls around here. Seems there are some G codes specific to this control to invoke 2 or 5 block look ahead (which ain't much) but when you know the control, you can sort of work your programming and code around that to make it happy. IE, I might slack way off of the contour precision which will generate less code and step off of the part a little more and plan for a nice finish pass. I know lots of guys that just post their file and run but seems these old controls benefit with smart programming.

I know I got into sub programming out of need for both program simplicity and storage. I friggin LOVE IT!!!! So much cleaner and easier.