Welcome to Our Community

Some features disabled for guests. Register Today.

Openbuilds Control becomes unstable during long projects

Discussion in 'Control Software' started by RoosterTX, Jul 12, 2019.

  1. RoosterTX

    RoosterTX Well-Known
    Builder

    Joined:
    Feb 1, 2019
    Messages:
    16
    Likes Received:
    9
    This has happened to me on two different computers. My old system (Win7) and my new system (Win10) both experience problems with long projects stalling out and the software becoming unusable. More so the older system, but the new system as well. The new PC is a Intel I5 with 12GB of RAM and a fresh install of Win10. No other software is failing.

    What I experience is that during a long project, say with 3-4 different pieces of gcode in that needs to be run consecutively against the same XY zero point, is that eventually I can no longer make the software jog, run code, or navigate menus. Also, displays of position and buttons freeze up and no longer respond. The only fix is to stop the software completely and reload, which of course causes me to lose my XY zero. Much frustration follows.

    I'm now using Universal Gcode Sender nearly exclusively. There are more features in the Openbuilds software but it's cost me too many projects and I just don't trust it. Suggestions?
     
  2. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Resident Builder Project Maker Builder

    Joined:
    Mar 1, 2017
    Messages:
    1,392
    Likes Received:
    737
    We did fix a memory leak bug in the 1.0.17x versions. 160s and older had an issue.

    So if you last tried it in the 160s, try the newest version once again and report back.

    If issue persist, post sample files and order they have to be loaded so I can try replicating the issue on this end to analyze and fix
     
  3. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Resident Builder Project Maker Builder

    Joined:
    Mar 1, 2017
    Messages:
    1,392
    Likes Received:
    737
    That statement is incorrect

    Zero position is stored in Grbl EEPROM and persists even through power cycles :)
     
    Joe Santarsiero likes this.
  4. RoosterTX

    RoosterTX Well-Known
    Builder

    Joined:
    Feb 1, 2019
    Messages:
    16
    Likes Received:
    9
    I will check my version and the newer version as you suggest and report back. Thank you very much for the rapid response!
     
  5. RoosterTX

    RoosterTX Well-Known
    Builder

    Joined:
    Feb 1, 2019
    Messages:
    16
    Likes Received:
    9
    Ok I'm showing my ignorance I think :) if the zero position is stored, how do I use it again? I ask because when I restart the locked-up software, it reports a different position, so the software is reporting that zero is a different location. For example, yesterday when the software locked up my current position (as I was preparing to load the next gcode file), my present position was X= -105, Y = -150, but when I restarted the application it reported X= -105, Y= -180 (or something like that). It was weird that the software came up and the X position was accurate from the last cut, but the Y position was off. If I was to override the location in the tool to drive it to zero, it would be moving +180mm in the Y axis, which would not be the good zero spot.

    How do I get the last (good) XY zero location out of GRBL? And thank you as well for the fast response and information Peter.
     
  6. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Resident Builder Project Maker Builder

    Joined:
    Mar 1, 2017
    Messages:
    1,392
    Likes Received:
    737
    The 150 (last processed display uodate) might not have shown 180 (actual value) as it was already hanging?

    All we do is display what grbl says it is. Thats all :)
     
  7. RoosterTX

    RoosterTX Well-Known
    Builder

    Joined:
    Feb 1, 2019
    Messages:
    16
    Likes Received:
    9
    The incorrect value was displayed after the software was restarted from the hung state. To restart the app, I could not close normally so I right-clicked in task bar by the clock, and selected quit/close (with the message that all integration would stop, etc). Then I restarted the app from a shortcut on the desktop. Once it was back up, I got a different number.

    I'm going to check my version and see if I'm down rev. Your software is much more robust that UGS so I hope I can make it work for me. Thanks again.
     
  8. RoosterTX

    RoosterTX Well-Known
    Builder

    Joined:
    Feb 1, 2019
    Messages:
    16
    Likes Received:
    9
    Just confirmed - I'm already running v1.0.179.

    I suppose it could have been like you say - the display stopped integrating before I realized it, so it was displaying a stale value and not what was in GRBL. I'll just have to monitor it.
     
  9. Peter Van Der Walt

    Peter Van Der Walt OpenBuilds Team
    Staff Member Moderator Resident Builder Project Maker Builder

    Joined:
    Mar 1, 2017
    Messages:
    1,392
    Likes Received:
    737
    Well, the correct value, again, we only show the output Grbl gives to '?' command. What it shows is just what grbl says it is. Refer to Grbl Wiki > Interfacing (read the whole page)


    Just like many other apps (skype, printer drivers, many more) the close button minimises to tray. That ensures its always running to use with the integration functionality (cloud API for cam, fusion coming soon etc). To quit, use the systray menu.

    Correct, we query Grbl once every 200ms only

    Cool, then next time it happens, refer to ny request above:

     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice