From the beginning I have had problems with jobs stopping in the middle, even with surfacing code generated by gsender. Initially I thought it was because of an old computer, and it was better when using the “lightweight” feature. However, I now have a sort of “state of the art” computer hooked up and the problems remain.
I am trying to run very large codes generated from mesh objects by Fusion. The stoppage often doesn’t happen for tens of minutes, and oddly enough sometimes the job resumes on its own after a few minutes. I was willing to blame a connection problem, but then I discovered that even the “verify code” function sometimes hangs up in the middle. Also, often the stoppage takes place at the end of a parallel path tool path line, if that is any clue.
So I am baffled. Does anyone recognize these symptoms and have a solution?
Other bugs in gSender:
*When you switch back and forth to lightweight mode the screen goes black and you have to reload.
*The timing display updates slowly or not at all, and is often incorrect.
Is this a tool change issue? Is there an M6 in your gcode?
You can have gsender ignore M6 requests
I noticed this thread today that could be what you are describing. (assuming it is an M6 thing)
No there are no M codes in the bulk g-code. The codes in the places where the run stops are totally normal. The run happily continues if you restart at the last line. 90% of the time it is when the x-motors reverse. The only thing I notice then is a clunk as they turn around and the y-axis activates. Are there any issues with vibration interfering with the controller?
I have been doing longmilling for about a year and a half now and have had my fair share of stops where stops weren’t due. I, too, have tried a lot of things.
I went from connecting over a 10 m (30ish ft) shielded USB cable via an old I5 PC at the machine to a new I5 PC without solving the issue. At last, I replaced the printer cable connecting all those computers to the machine with one I found in the old cable box. It’s only half a meter (2ish ft) long, so the PC ballances on one LM, blocking my Y range, but I managed to mill through a clock without problems other than filling my precious PC with teak chips.
I am leaning towards having found the problem, so now I need a good-quality shielded cable and will try again with my PC safely tugged away and with jobs running a little bit longer.
It took me so long to find this problem, for I was looking everywhere but that last cable. I blamed the length of the shielded cable, the power of the second-hand PC, and my doubts about the USB connectors on the new one, the gcode created by light burn (laser jobs tend to take much longer, so more stops during etchings), and static noise. (The colder it got, the more stops I encountered.)
I have put much effort into setting up jobs so that losing zero settings would be recoverable. I look forward to running jobs without hickups.
I hope you find your problem, but I would take a look at that USB cable. It can do bleep-up jobs like a champ.
Thanks! I think I have solved my problems and they are related to the USB issues you had. Today I ran the system for 5 hours with no stops!
Originally I had my computer on the other side of the table from the controller. The USB cable ran under the table, where it could be bathed in the RF noise from a vacuum cleaner and the router. Short jobs ran okay, but longer jobs continued to stop at the turn-around points during tool paths that scanned back and forth along the x-axis, which is common. Stopping at the turns confused me into thinking it had something to do with the code until I realized it was only at those points that all four motors are energized, and apparently must be putting out an RF burst. Only occasionally will the RF from the different sources be in phase, but then there might be enough intensity to get into the USB cable and confuse the controller.
To solve the problem, I put the computer on a shelf above the controller and ran the USB cable directly down to it. The keyboard and mouse are wireless, so the only cable that does under the table is an HDMI cable to the monitor, which doesn’t seem to care about RF.
I did try to buy a new USB cable, but the new one performed worse than the one that came with the machine. The odd connector on the controller makes it difficult to select a really high quality cable of different lengths. Recommendations for specific cables from specific vendors would be appreciated.
Thanks again to those who sent suggestions!
Great news phmjo. It’s alway good to find the cause of problems so they can be adressed.
Using the list gwiki provided I’m going with this one. Gilded USB2.0 A-B high speed with dual ferrite cores 1.8m for some wiggle room.
No idea if this vendor will ship abroad but I bet you can find simular providers in your area. I might get a few lower quality cables for comparison, and use as spare if they work.
https://www.allekabels.nl/usb-printer-kabel/4578/1043114/usb-printer-kabel.html
Hi Spammy_Eddie! You mean 2 ferrite rings will also be a solution for IDLE and “USB Disconnected”? That would be good! I have tried UGS, OpenBuilds CONTROL, now also gSender… One thing is clear - that it is not a software problem. I will try to do it with a 1m USB cable.
https://www.instagram.com/up2a1plus - my custom build Arduino/GRBL pen plotter.
It’s not an end all solution, but they choke noise and if you can improve noise to signal ratio, you might just choke out an idle/disconnect problem using some cores.
A good shielded cable with an active amplifier could help out much too.
Here’s a quick vid on the sub.
In my case, this will probably be the solution! Just finished the 83502 lines of G-Code “Crash Test” on my DIY Arduino GRBL large format plotter. Three hours of work and no USB interruptions and machine freezes. https://amzn.eu/d/55GR7um 