Visualizer got lost, could not abort

[RecceDG]

Running a fairly long cut, about 1/5 of the way in, the visualizer stopped updating.

Program ran to completion, cut successful, turned off spindle.

UGS remained in "run" mode, started updating visualizer again, duration in progress meter went high negative.

It looked like it was going to play out all the (buffered?) executed commands in visualizer, so I tried to stop it. No response to "stop" or "pause" buttons.

Had to kill task (it would have been an hour updating).

Thank Lob the XController retained work zero...

[breiler]

Which version of UGS Platform are you using? Would you mind sharing the GCode-file you were running?

[RecceDG]

Daffodil Roughing 25 flat.nc.zip

It's the March 15 version of the nightly (I know that one works and I have an important cut to make)

[breiler]

Wow, that's a pretty big job!

UGS crashed on my laptop while trying to load it. Closing the Visualizer helped and I would probably need to close the Console as well if I were to run the whole file. So I'm guessing this is just a performance issue with large files.

Regarding the issue with GUI lockups, if I'm allowed to guess there was a couple of issues that may have been resolved around the March 25 nightly build. A similar issue #718 and the issue with a couple of fixes #759.

I don't have the time trying to run the whole file in the old version to reproduce the issues.

[BallscrewBob]

Think this may be the same issue with large files...

mermaid greyscale 75x57 fine inverse.zip

There is no set point for a crash. It can happen anywhere in the G-CODE. Bummer if that I have to guess the start point again as it doesnt have the ability to remember where it was. Not too much of an issue if I am only on a rough cut but a real pain if I am on a finish cut.

The "large file" issue does seem to be a common problem. The program can only be shut down from task manager and even if some of the buttons remain responsive to the mouse they are unresponsive to the commands that should happen.

TM reports no issues as the screen shot shows its running normally but the upper screen shot from the same session shows that a catastrophic failure happened.

[winder]

@BallscrewBob thanks for the report, and the file. In addition to the crash/hang it looks like UGS is also having a problem visualizing the file. Although 81,000 lines is much larger than most jobs I see, my understanding is that laser jobs can be even larger. I'm wondering if there is some sort of memory leak in addition to the known "large file" issues with the visualizer/console.

Could you tell me the expected runtime of these jobs? Have you seen this more than once? Approximately how many minutes/hours into jobs this large do you see the hang?

If you have time, please run a couple tests for me. Ideally, run the tests one at a time to see which change (if either) helps with the problem -- of course I understand that shop time is valuable (whether it is hobby or production), so if you need to make both changes at once just let me know.

1) Close the visualizer/console when running large programs like this.

2) Update to the latest nightly build, @breiler has made a number of stability improvements this year which can prevent UGS from getting into bad UI states.

If you don't have time to run either of these tests go ahead and update ugsplatform/etc/ugsplatform.conf by changing -J-Xms64m to something larger -- say 50% of your systems RAM (i.e. if you have 4 gigs of ram use -J-Xms2G. That is a sort of brute force solution that should mitigagate the issue without fixing the bug.

Thanks!

[BallscrewBob]

I have plenty of time Will... Runtimes vary but are always more than 2 hours. That one is about 4.5 hours. I can assure you it is nothing to do with power saving BTW.

Yes seen it multiple occasions with two seperate jobs.

The hang as mentioned can be anything from a few minutes (>15) to a couple of hours. Visualiser was OFF for two of these occasions but it does help to have it off.

If I do the "check for updates" it is reported as the latest.

Will make the test changes one at a time when the next job has finished a pass and then again on the next pass.

Side note:- I also dev test for the Arduino CREATE team so I generally don't report a bug until I know it is repeatable or has some basis for further investigation. Much prefer your program over many of the others so I would rather help you so that others can benefit.

Current system is on a decent spec win7 pro box but do have a win10 box and a server available for other testing if needed.

Use "LaserGRBL" for laser work as it is simple to do the type of jobs I need for that aspect. Both CNC's are home brew but pretty reliable (3rd in development)

[BallscrewBob]

Making any changes to the CONF file causes UGS not to fire up properly... Either it looks like it will work then drops out or just flashes the splash very quickly and drops out. Directly CP's from your post and so long as I put back the "-J-Xms64m" it will fire up properly.

Just had a full pass of the program I attached with no errors. That's the first time I have not had to use another program to finish a cut. Visualiser was off and that time I also shut down the console. Your assertions of visualiser and / or console are correct ! It would seem that with large files they both have as you say either a leak or some other issue.

Tried a few different ways of implementing that mod BTW. It does work in the meg range..managed to get 128m to stick.

[BallscrewBob]

Just had another fail UPDATE this link is now to a DUMP FILE for the crash https://1drv.ms/u/s!AqSzk5so2vXinQP7KUssAs0T5d1Z

As you will see there was no console or visualiser open at the time and the program failed about 7 minutes in (shortest failure to date)

[BallscrewBob]

UPDATE - Since changing to 128m the program has become a lot more stable... Couple of other minor issues show with the change in that sometimes the whole program becomes very slow to respond to commands but at least it does respond. Visualiser and console still OFF (only way to keep it 100% working) Does seem slow to load a CNC file above 4 Mb in size with NULL errors popping up until the file is fully loaded. Will try snag pics next time unless you are already aware of those messages ?

Going to try to update the memory number when it finishes the next job.

[BallscrewBob]

Managed to snag a dump file but it is too big for GIT so here is a link to an external source

https://1drv.ms/u/s!AqSzk5so2vXinQIgnfoGa6q0fQ1Z

It is quite large but hopefully contains a few clues as to what is going wrong. Even without the visualiser and console open the program was getting slower and slower. JAVA warnings were appearing and disappearing before I could snag a screen shot and if I did manage to click on one it just brought UGS back up slowly. This is with 512m set from your earlier suggestion.

Think it is safe to say that it is not console visualiser directly related however they do speed up the problem.

[ukoksoy]

Hi @BallscrewBob I am trying to deal with large files as well. I build my own DIY wood router and use it with Arduino GRBL v1.1f.

At first, I was having more problems. Eventually, I managed to complete attached gcode for roughing surface which contains 355080 rows. It took about 3 and half an hour. First errors that I was having were related with G2/G3 arc commands. I managed to solve it by enabling arc expander from the settings. Tools>Options>UGS>Controller Options>Arc Expander. It converts G2/G3 commands to linear motion (G1).

My second problem was that during the middle of the carving, the computer freezes suddenly and machine stops without giving any errors. After reading your comments above, I closed visualizor and the console. And it worked. But this time I had had another problem. Et the end of the wood carving, the spindle returned back the start position. When I checked it, it was 3-4 mm away from the original start point. When I realized it, I home the machine and upload the second gcode file for finishing. It is a small file, it would take about 20 minutes. However, It started to finish surface 5-6 mm away where it supposed to start, so I stop the UGS.

I am not sure if the root cause of the problem is UGS or my DIY machine. I think large files problems are also related with the computer processor speed and the arduino performance.

To be able to find the exact problem, I will try the same gcodes with another software at weekend. If it works, that means the problem is with UGS. If I face the same problems, I may think about using faster computer and original arduino. I will share my experience with you.

gcode files.zip

[winder]

@BallscrewBob thanks for all these clues, they will be a big help the next time I debug these performance/memory issues

[BallscrewBob]

You are most welcome Will...If I find anything definitive I will drop it in this section.. Hopefully the crash dump attached above gives enough to plug this hole with large files.

It looks like it might be reading the file from the beginning when its already a long way into it, causing the slow downs with maybe a buffer issue ?

A side effect of the problem is that the screen buttons work but the program does not reflect the changes. EG if you change the feed rate with over ride then the machine responds but the screen does not update so you cannot tell (unless you count the mouse clicks) what the new feed rate percentage is.

P.S. its moments like this where a LINE counter would be useful along with a "restart from line xxx" I could maybe restart the program afresh from a set point and see if the issue is still there.

[BallscrewBob]

As if right on cue...here is a video of UGS getting ready to fail showing the semi buttons and the DRO updates slowing down to stutter

Ugs getting ready to fail 2018-07-03 at 07-58-21.zip

[ukoksoy]

Forget about my above comment. the last problem I faced is because of the loose bolt on x axis coupling. I just noticed it.

[BallscrewBob]

Are you any further along on the large job problem ? New router just arrived and I was looking forward to getting some real work done but getting the jog options greyed out if I stop a job from the program.

[breiler]

This should have been resolved in the latest nightly build.