What's new
What's new

Is 512K memory enough to end data starving?

gmoushon

Cast Iron
Joined
May 18, 2006
Location
Illinois
This may be a difficult question to answer given the number of variables, but does anyone know if a 512K memory expansion would be adequate to fix a data starving problems on a 1994 Yasnac MX3 control or would I have to go to 1 meg? I just can't seem to get good 3D tool paths without starving in Fusion 360, even with adjusting the smoothing and tolerance parameters.

Thanks,
gm
 
like you say, there are a lot of variables, but I would say 512k isn't even going to get you started. Most of our surfacing paths end up in the 1-12meg range.
 
Depends on the reason for the data starving. If the machine's control can't process the lines of code fast enough to keep up with the tool, no amount of memory will fix that. A 1994 machine of any kind will be severely limited in 3D surfacing and dynamic paths; you'll have to heavily filter the code and perhaps run at a reduced feed rate to let the control keep up.
 
Depends on the reason for the data starving. If the machine's control can't process the lines of code fast enough to keep up with the tool, no amount of memory will fix that.

That makes sense. I guess the easy test is to load the biggest 3D surfacing path the machine will hold and see if it can keep up. So, if I understand the process correctly, a memory upgrade will simply eliminate the need for drip feeding. It won't necessarily eliminate data starvation. Correct?

gm
 
That's correct. Try lowering the feed rate as that can only help smooth out jerkiness and starvation. Remove all spaces and do not use block numbers in your program, as this will greatly reduce file size, and might help in other ways.

I have a mid/late 90's OM that had jerkiness problems on a 3d contour chamfer pass. Only way to smooth it out was to slow the feed. The machine didn't hang and wait, it was just jerky. (It was a million small linear moves type program.) I ran that same program on a mid/late 90's 18M with Look Ahead, and had zero problems at four times the feed rate. My point being, it's all in the control capabilities.

Dave
 
I agree with the above, your control is unable to process lines of code quickly. Your best bet is to just feed it slower and/or make your moves longer.
 
Make sure your post is set up to utilize the capabilities of your control

I cut thousands of lines out of programs by making seemingly minor changes.

Also changing some strategies can save a lot of space. Like a helical ramp can be hundreds of lines.

Most of my changes were based on trying to get the total program size under 1000 lines so it would fit in my machine, but the concept follows
 
All great advise. Thanks.

When it comes to slowing down the feed, I assume you're meaning adjusting the "feeds and speeds" in the cam and not just turning down the feed pot manually at the machine?

gm
 
The memory that added will not change the computing proessor that the control is equipped with,

look into the Risc proessor for fanuc
 








 
Back
Top