search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.9k stars 765 forks source link

Console lags output #1278

Closed BallscrewBob closed 4 years ago

BallscrewBob commented 5 years ago

Product Version: Universal Gcode Platform 201609300101 Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13 Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13

Win 7 x64

Can also reproduce on latest version but one above is more stable here. NOTE the visualiser was OFF ! for the whole run.

Job has finished and the machine is at "safe Z" but not ZERO. The console is still running and preventing other functions from working properly. The file attached (and many others) will eventually bring up the box "Timeout waiting for GRBL to idle during cancel. cancel incomplete" I hit "OK" and can hit the stop button again but still zero response. Only way out is to close UGS and then re-find Z zero again for the job if I need to add another cut or open a second file for further processing on the job.

130 dia 2mm ball FINE.zip

Found the log for this issue too but not sure it is going to be much help to you. messages.log.zip

BallscrewBob commented 5 years ago

Can also reproduce on this version.

Product Version: Universal Gcode Platform 20190423 Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13 Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (ugsplatform) User directory: D:\Users\Bob\AppData\Roaming.ugsplatform\2.0-SNAPSHOT\dev Cache directory: D:\Users\Bob\AppData\Roaming.ugsplatform\2.0-SNAPSHOT\dev\var\cache

rlwoodjr commented 5 years ago

We are experiencing the same issue.

My understanding from our testing is that in a large file run at a "fast" feed rate causes a lag between the GUI and the serial communications. Therefore the GUI is not live. It lags behind. When we finish a large file (spindle returns home and the project is complete), the UGS screen still has 30% to 50% of lines to process. I actually let it continue to run a few times and it does finally finish up and give you back the GUI. This is true with 16Gb dual processor or 2Gb mini computer.

We started the same file on 2 different CNC's on at 100% and the other at 200%. The computers were identical.

The "remaining rows" in the "send Progress" window stayed relatively close during the entire process. Seems like it is running at some max process speed.

With our normal production files (small and lots of straight lines) the GUI stays in sync.

breiler commented 4 years ago

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

Mar4M commented 3 months ago

experiencing the same issue with UGS 2.1.7 on mks dlc32 v2.1 after pressing the jog arrows continuously. the gantry will just drift off slowly with the other controls unresponsive - until it crashes. doesn't occur with candle. noted problem after upgrading a windows 10 laptop to 11.

breiler commented 3 months ago

@Mar4M this problem was considered fixed four years ago. What you are experiencing is likely not the same problem. Please create a new issue.