Is there an issue with the gcode widget right now? I was about to cut some letters for a customer but the widget seems unresponsive and won’t run the file. You can see the gcode listing is showing 4 lines and I brought in another file to test - no change. The simulator runs the files no problem. Machine jogging is fine. Behaviour is identical on 2 different computers.
Have you tried clearing history/cache completely? I have to do that every now and then.
I’ll try that. It is behaving exactly the same on 2 computers so I didn’t think it was the cache. I’ll give it a shot now.
Interesting, that did the trick! Thanks Richard!
If you are logged in to Chrome, it is possible your cache is the same on both machines. I have found that Chilipeppr is extremely stable and that my cache is often the cause of any little “buggies” I have.
Yeah I’ve never had to fully clear the cache like that. Sometimes I find it’ll produce very choppy motion and the whole computer and tinyg need a reboot.
So halfway through this 400kB file and it starts to stall every few seconds. That really trashes the surface finish. Is this still an issue or is there something I can do to keep it moving smoothly?
I have seen this happen occasionally when I have my machine connected directly with USB to the same machine that I run the JSON server and the browser with Chilipeppr. I honestly never could figure out what caused it.
It was because of this that I built a little raspberry pi machine to run as a dedicated JSON “host” for my machine. I even run the rPi machine on WiFi. I have run some very long (hours and hours) “air tests” and it runs flawlessly.
If you look at my pics, you can see that my latest machine is not finished, but the electronics are completely done. I’m doing a lot of testing, A LOT! The rPi setup is very stable. I also got the shuttle module running, but every now and then it just stops. Touchplate works perfectly as well.
I’m going to plug my machine directly to my pc and do some long jobs and see how they run. I’ll let you know if I see that issue again.
You may want to get Universal gCode Sender v 1.0.7. (or is it 2.0?) It works well with tinyg. It’s good to have a backup way to send jobs and test things.
I have not experienced what you are discussing, but don’t tent to run long jobs either.I would suggest that you track and report FW and SPJS versions your are running.
When I read the comments here, particularly Richards on his various CP to SPJS connections, I see perhaps an indicator that if SPJS and CP are communicating ‘too fast’ unfortunate things can happen, sometimes caused by interprocess timing issues(race conditions). There could also be dependencies on the core capability of your compute platforms - so perhaps keep an eye on CPU utilization by the CP and SPJS processes while they are running.
For example, I note that SPJS 1.86 consumes much less CPU than prior versions, so conclude it is ‘running faster’.
Faster may not be better here.
Thanks for the info guys. I’ll double check the versions but I believe I’m on the latest version of FW and SPJS. It could very well be the laptop that I’m using as it’s not exactly high performance. Also it wasn’t a long job really, only about 8 minutes of cutting time. I think maybe my laptop isn’t keeping up with the tinyg and the buffer is being starved. I find it usually happens with jobs that have lots of small line segments and curves. I was in the process of setting up a different Linux PC to run the CNC so I’ll try that machine as well.