Recently I have been using UGS to send my Gcode. I am using the nightly build.
When I run a program, the Xcarve moves much faster than the display on the screen. I have been running a few 1-hour long carves, but when the carve finishes, UGS is only showing that the process is less than 1/2 done. UGS continues to roll the Gcode and to show the Tool paths long after the carve is finished.
I can not set up the next carve until this process finishes, which could take another 1/2 hour or so. The only solution that I have found is to close UGS, re-open it, Re-Connect, Re-Home, return to zero, now start next program.
I cannot figure out why UGS moves slower on screen than what the actual Xcarve runs.
I have performed a few 10 minute carves and UGS keeps up. But the longer carves, UGS drags behind. This does not affect the carve, it only becomes a nuisance when I’m ready to move on to the next carve and UGS still thinks it’s workkng on the last project.
Does anyone know a solution for this?
I’ve seen this before. It has been reported to Will.
I believe he recommended closing the console but I think in newer versions, the Console is disabled when streaming.
What nightly build are you using?
Thanks Justin. I’m not in front of my pc but I downloaded the most recent version less than two weeks ago.
The only thing I have been able to do is shut it down and reopen it when this occurs. Nothing else helps. UGS seems to be locked up while the process occurs. It does show that I am attempting to stop the program but then just returns to what it was doing.
Really odd in my opinion. The CNC is outrunning the Software on the PC even though the PC is the one sending the Info to the CNC.
What version of UGS are you using?
What type of PC, and how fast is it?
I will verify the UGS Platform and speed tonight.
The computer is a MacBook Pro and is pushing about 10 years old now.
I will try using a new Dell the next time I run the program and see if I have the same issue with it.
Thanks, this is probably a performance problem in the Platform version of UGS. It has been a long time since I’ve done any benchmarking. I guess the silver lining is that the separation between GUI and Sender works – meaning that even though the GUI is slow, the gcode stream is doing its thing at (hopefully) full speed.
The first thing I’d recommend trying is reducing the status poll frequency (the default value is 5x per second). Also, closing extra windows like @JustinBusby suggested will also help. You may need to restart UGS in order for the closed-windows to improve performance.
Mid-2009 15imch MacBook Pro
2.66Ghz Intel Corp 2 duo
4 GB 1067 MHz DDR3
OSX El Capitan
10.11.6
Universal Gcode Platform
(Version 2.0 [nightly] / October 29,2017)
