New issue today that I’ve never had happen before…
Job was running in the middle of a pocket/peel when the gantry lifts maxed Z then proceeded to X0Y0 and then tried to raise Z again until I killed it.
Code was created with ESTLCAM
Used CNC.JS to run the job
Job was running ok until the issue and was in the middle of a toolpath.
Any ideas?
Could it accidently be trying to do a tool change in the middle of your job?
Hmmm don’t think so, its in the middle of a pocketing path. I simulated the job in ESTLCAM and it shows the proper path with no returns to 0,0.
I’ll run it again and see what happens. Thanks!
Do you have any predefined text scrips in estlcam?
No it’s just stock settings.
It’s really a nothing job 1 hole, 1 part, 3 pockets all with the same bit. Run time is about 40 mins it was about 25 in when this happened. It was still working on the first tool path.
And I misspoke previously when I set it went to 0,0 in fact it went to machine 0,0 as work zero had been set before run. It’s like it tried to xy home in the middle of of a print.
As I type this I have a theory … the laptop went to sleep during the job it’s possible rhat when I woke it up I might have clicked a button inadvertently and queued up a macro from cnc.is does anyone know if it’s possible to inject gcode while a job is in progress?
Absolutely it is. That’s how printers deal with things like pause requests, or babystep adjustments
Also, are you printing via the SD card or USB? I’ve had some WEIRD stuff happen over USB. Once I started using the SD Card and LCD exclusively, never had another hiccup.
CNC.js running on a PI connected via USB my guess is that I somehow hit a homing macro though. Once I fix my current power issue I’ll rerun and see how it goes.