ugsplatform lags and freezes after stopping/pausing job

[Harvie]

I've been using ugs platform to cut relatively big job (21MB g-code) and everything was cut perfectly. Job was finished in two hours. But when it stopped the ugs was still showing like 80% (10 hours approximated) remaining. And these coordinates followed by ok continued to run in console window:

The same happend when i tried to stop/pause the job in the middle. ugs was frozen except for showing coordinates that were not received by grbl. This even happened when i pressed reset button on grbl. New g commands still kept showing even when machine was already stoped.

[winder]

What version of GRBL are you using? Could you share the gcode file?

[Harvie]

grbl v1.1e, stopping mid job works perfectly with smaller files. This is the g-code: holes.txt I don't remember exactly, but i think it was generated by jscut and then panelized/tiled using bCNC.

[winder]

@Harvie thanks for the file. After loading the file and running it for a bit I think this is most likely a performance issue. The way the arcs are made using hundreds of short line segments means there is a lot of work to do for processing GRBL responses and notifying the GUI.

I was still able to pause the job, but sometimes I had to click it several times before it responded, probably some sort of race condition caused by UGS processing so many events.

Now the strangest part... you mentioned that the job finished but you still saw the gcode/ok messages coming through the console AND the machine location being updated?

[Harvie]

Yes, IIRC the stop/pause button was greyed out after first click, but everything kept running. I think there should be something that will synchronize threads, so nothing will send more g-code commands to machine as soon as button was clicked. If there's some arc processing on background it can finish separately after sending is terminated.

[BusbyGT]

I'm currently experiencing this same thing. The GUI worked for the first hour of the carve and then I got an update maybe an hour later that increments the elapsed time by like 20 minutes. I did a feed hold on my controller and let it sit idle for 1.5 hours and when I came back, still no GUI response until about 30 mins later and it catches up to the point where I did the feed hold. The job is still running with no issues, I can update when it's done cutting. It's an 11MB Gcode file that I'm streaming for a 3D finishing toolpath (629,000 lines).

GRBL v1.1f, Xcontroller, RaspberryPi 3, the July 23 nightly semi-stable build.

[Harvie]

@BusbyGT i think to unfreeze by waiting you might want to try exact oposite. click on pause in ugs-platform and wait for looong time, then it maaaaaybe will get unstucked. if you pause controller the ugs will not be able send any buffered commands to it and therefore it will not clean itself up. but it's just what i think. haven't really tried.

[winder]

Could you try closing the console tab before running your program? I think the console is the only module which grows over time, so it might be causing the performance issues.

Netbeans has a built-in console that I've been meaning to try out instead of my home-made console. If this fixes the problem that could bump the priority of making that switch.

[breiler]

I've made some changes in the visualizer that might fix this. I'm closing this, please reopen if the problem still exist.