Whenever I run a script to my TinyG/Sherline (even a short script of 4 or 5 lines), the non-Gcode widgets seem to lose contact and lock up in some way. The “Axes” widget will continue to post some seemingly random positions even when the cutter has in fact moved on and the TinyG widget also shows a constant state for the latter portion of the run time.
Then when the script is done, the Gcode and Serial Port Console widgets will also be non-responsive and I’ll have to restart the json server to get Chilipeppr to talk to the TinyG again. Any thoughts on what might be going on or what settings might need adjusting?
Hmm, I take it back. It doesn’t happen every time. Curiouser.
OK, it is apparently not related to running a script necessarily, it seems that json just loses access to the USB port intermittently. I’m running Win7 64 bit. Any way to troubleshoot this?
When you say “run a script” do you mean “run Gcode” or “run macro”.
If you mean run Gcode, then I’m a bit perplexed what’s happening to you. Are you running ChiliPeppr on a remote machine like a laptop that’s on mediocre wifi? Too many packets lost can seem to drop the websocket connection between the browser and the Serial Port JSON Server.
I’ve been finding that the listing out of serial ports on Windows can crash the Serial Port JSON Server. I tried to get fancy by querying the Windows Registry for the friendly name of the port, but it’s not perfect yet because I sometimes see crashes. There would be no querying of the serial port list when you run Gcode though, so that wouldn’t be the reason here.
Any other thoughts? Could you post a video perhaps?
@Dat_Chu , I could try plug in in my Linux box, it’s super old and only able to run Lubuntu reliably, but it might be worth a shot. Would complicate my work flow somewhat though, so probably not worth the current hassle of just restarting json when it disconnects.
@jlauer , sorry, I just mean running a Gcode file. I’m not using any CAM yet, so the files I’m writing are pretty simple/small as you can imagine. I’m writing them in a text editor and saving them as .gcode files and they seem to run fine. And as mentioned in my comment, I no longer believe the drop is related to sending the Gcode anyway.
I’m running my laptop plugged directly into the TinyG via USB.
Not sure I can predict the failure reliably enough to capture a video, and not sure how to capture video of my screen other than with my cell phone (surely there’s a better way?). If you think it would help I could give it a try though.
Is there any debug output on the Serial Port JSON Server right after it disconnects/crashes? Run serial-port-json-server.exe with a -v option to get debut output. Then if you see this happen in the future cut/paste the part where it crashes.
May be power saving settings turning off the USB serial device when IRS idle while json server is still running. I think you can disable thus feature for specific USB devices
Interesting. Could be. I have done lots of tests of yanking the USB cable, losing the serial port, and catching that. Although, I do know that’s only in version 1.71 which is downloadable right now, but is still labeled as 1.7 even though it’s one minor rev up.
@Daniel_Joyce Thanks for the tip, that sounds like a likely candidate! I turned off the USB suspend “when plugged in” in my power savings settings and I’ll see if that does the trick. If not, I’ll try running json verbose
This is why USB-Serial port converters are tricky. It may be a better idea to purchase a serial port card and use that so you don’t bump into usb weirdness. The USB standard is incredibly complicated, and bugs are common in the drivers and even in the chips.
Given that those cards easily cost the same as a Raspberry Pi, it would be good to keep Raspberry pi as a solution in mind. Adding a Rpi as your remote controller allows for a few things: relays to turn on and off systems, lower power consumption, easier machine relocation, …
Thanks guys! I’ve got a Pi that I intend to use for wireless printing with my printrbot, so if I have luck with that there may be another one in my future.
@jlauer OK, it looks like it’s still happening although less often. Here’s the log I captured from json verbose output when it happened a few minutes ago.
The line showing the error in that log is:
2014/09/20 16:01:34 serialport.go:266: Error writing to COM5 A device attached t
o the system is not functioning. Closing port.
That means it tried to write to your serial port but got an error doing it. That’s an operating system error coming back. I’m not sure there’s much I can do about that error. What OS are you on?