dwhughes08

Sorry for the delay, I finally got back to the system.
I did not try Chillipeppr, as I do not have internet access at the machine location, and in reading from the web site that it was limited to 27,000 lines, as my files almost always exceed that number.

I have rerun the same file that had several zero resets at various
times in the gcode file, this time with no reset and completion of the
job correctly. I made two changes: First, changing $qv to 1, $sv
to 1, and keeping $si at 250 to receive reports. Second, I added
a limit switch to the X and Y axis in order to keep from running
into the end of the axis, using settings of $xsx to 2 and $ysx to 2.
Originally $xsx was set to 0 and $ysx was set to 0, and left
unwired.

I recorded the output to a file to monitor for any errors, and
found none. The report qr: stayed at between 3 and 5 most of
the report.

I suspect that the unconnected and disabled condition of the
limit switches may have cause the strange zero reset.

If I running into the probelm again, I will contact you.
Thank you for your help.

When the failure occurs, I do not see an error but since the commands are buffered I may have missed an error response. The system continues from the middle of the job as though a new zero has been set and picks up the job without stopping with the new zero reference – considerably offset from the original. The error does not always come from the same location in the gcode file, and if allowed to continue will get another error, once again with a large offset from the correct zero established from homing. I am using CTS for the interface control. I have run the gcode file through a simulator to check the job, and it shows the correct run without strange offsets. It looks as though the hard reset is not coming from the gcode file. The power source (24 volts) is run from an UPS and seems to be stable, as the computer supplying the gcode is on the same UPS.