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

Sender stop working #766

Closed inFamousMcGrath closed 4 years ago

inFamousMcGrath commented 7 years ago

Hi, i'm using last nighty build of UGS Platform, and i have Arduino Mega 2560 with GRBL 1.1f. I'm working with a large G-code files(aroud 1-2 million rows), which have onli G1, G0 and M3/M5 commends. So here is a problem - sender randomly stops to send a rows, without any messages. It shows only on big Gcode files (current file size is 25 MB). GRBL status in verbose is Idle, spindle don't disable, so it just stay on last XYZ position with enabled spindle)). p.s. Sorry for bad English.

inFamousMcGrath commented 7 years ago

Update - it happened only on notebook with 1 GB ram and Atom n450. i7 6700 +8Gb ram works fine.

winder commented 7 years ago

@inFamousMcGrath try closing the console window, if that doesn't work also close the visualizer. If one or both of those fixes it I can investigate why they're leaking memory over time.

inFamousMcGrath commented 7 years ago

I'll try, but there more bad news by this hour - it's stopped even on i7 6700 - after 6 hours, but stopped. I cant stop sending, it dont react to my actions, only restart helps. There 111000 rows, that less that previous file, which was around 1000000 rows. Visualizer disabled, but console not, i'll try to disable it. default

vMeph commented 7 years ago

that pendant sender have alot bugs, wish someone would fix,would be a great app for the smart phone

winder commented 7 years ago

The pendant is another variable I wasn't even considering. When I wrap up with the features I'm working on now I'll try profiling the code to find where the memory is leaking. Until then if you leave the pendant disabled along with the console and visualizer hopefully the problem goes away. If it doesn't there is a much bigger problem than I realized.

inFamousMcGrath commented 7 years ago

So, turning off the console doesn't helps me. It's strange, it happens only at night time, when i left my work)) Well, i have some ideas, what it can be. Sender does not receive exact number of "ok" answers from GRBL (or it's an UGS bug), which need to continue sending. If there no error messages from UGS - i think it really main option. I reccomend to synchronize UGS counter with verbose - GRBL 1.1 response number of queued motion and avaliable buffer. Looks like Candle use right this method with GRBL 1.1. But Candle does not operate with corrupted answers from Arduino.. Another guy here write a list of probably errors: a) UGCS is somehow missing an "ok" response from GRBL b) UGCS is expecting one more "ok" responses than it should c) GRBL is not returning an "ok" when it should d) PC is somehow losing a response back from GRBL So really, you need to check verbose messeges from GRBL to know, is queue full or empty. Because i send Gcode wit small micro lines, up to 0.05 mm length, so at speed of 500 mm/min it might be very fast sending process, and there can't be any errors in this process, so if i was author - i might be to add maximum checks as i could.

Siand commented 7 years ago

@inFamousMcGrath I've read some of the code base for the UGS and the reveiving of responses happens through events, and there is no frequency of checks there - the code triggers by receiving a message.

scratchboom commented 5 years ago

@Siand so do you think it's GRBL problem?

breiler commented 4 years ago

I've made some changes in the visualizer that seems to have a big impact on the performance. Please reopen if the problem still exists.