Is 512K memory enough to end data starving?
Close
Login to Your Account
Likes Likes:  0
Results 1 to 11 of 11
  1. #1
    Join Date
    May 2006
    Location
    Illinois
    Posts
    237
    Post Thanks / Like
    Likes (Given)
    91
    Likes (Received)
    38

    Default Is 512K memory enough to end data starving?

    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

  2. #2
    Join Date
    Jan 2014
    Location
    Temecula, Ca
    Posts
    2,842
    Post Thanks / Like
    Likes (Given)
    1277
    Likes (Received)
    3675

    Default

    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.

  3. #3
    Join Date
    May 2017
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    1,001
    Post Thanks / Like
    Likes (Given)
    1200
    Likes (Received)
    628

    Default

    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.

  4. #4
    Join Date
    May 2006
    Location
    Illinois
    Posts
    237
    Post Thanks / Like
    Likes (Given)
    91
    Likes (Received)
    38

    Default

    Quote Originally Posted by mhajicek View Post
    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

  5. #5
    Join Date
    Jun 2015
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    269
    Post Thanks / Like
    Likes (Given)
    6
    Likes (Received)
    86

    Default

    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

  6. #6
    Join Date
    Oct 2007
    Country
    SPAIN
    Posts
    3,409
    Post Thanks / Like
    Likes (Given)
    1903
    Likes (Received)
    1242

    Default

    Quote Originally Posted by mhajicek View Post
    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.
    Regarding processors IF my memory serves me...And I know we're talking Yasnac here but...
    The Fanuc 0iC controls which were launched in 2005 (?) had a 486 processor driving it.
    I haven't a clue what a 1994 machine would have but it won't be faster!

  7. #7
    Join Date
    Jun 2012
    Location
    Michigan
    Posts
    4,658
    Post Thanks / Like
    Likes (Given)
    4266
    Likes (Received)
    2821

    Default

    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.

  8. #8
    Join Date
    Sep 2002
    Location
    People's Republic
    Posts
    3,069
    Post Thanks / Like
    Likes (Given)
    222
    Likes (Received)
    2094

    Default

    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

  9. #9
    Join Date
    May 2006
    Location
    Illinois
    Posts
    237
    Post Thanks / Like
    Likes (Given)
    91
    Likes (Received)
    38

    Default

    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

  10. #10
    Join Date
    Jun 2015
    Country
    UNITED STATES
    State/Province
    Minnesota
    Posts
    269
    Post Thanks / Like
    Likes (Given)
    6
    Likes (Received)
    86

    Default

    Either will work.

    Dave

  11. #11
    Join Date
    Mar 2011
    Location
    MASS
    Posts
    943
    Post Thanks / Like
    Likes (Given)
    394
    Likes (Received)
    289

    Default

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

    look into the Risc proessor for fanuc


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •