Zero reset in running job

Home › Forums › TinyG › TinyG Support › Zero reset in running job

Tagged: ,

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • April 20, 2016 at 3:19 pm #9565
    dwhughes08
    Member

    I keep getting a zero reset in a long running job. The job continues but with a new zero centered at the location of the reset. Stopped job, rerun homing for the proper zero, edited off top of gcode file to pickup where the fault occurs, and run the job — which continues for awhile, then reset zero occurs again in the middle of the job.
    Configuration:
    TinyG
    Firmware build: 440.20
    Firmware ver: 0.97
    Platform: 1
    Hardware ver. 8
    ID: 3X35566-WQQ
    Motor Setup: Motor 1 = Y, Motor 2 = Y, Motor 3 = X

    CoolTerm 1.4.6 software to spool to the TinyG
    Gcode file has 136,806 lines with approximately 45,602 G01 commands. This is X and Y only using M3/M5 to turn on and off a laser. The job can be completed successully with multiple restarts, but I have to watch continuely for faults.

    Any suggestions on what I am doing wrong?
    Regards,
    David

    April 21, 2016 at 6:07 am #9567
    cmcgrath5035
    Moderator

    Here are a few somewhat random questions in an attempt to narrow the universe of possible areas for investigation.

    Can you better describe “zero reset”?, Does the job come to a halt, reporting that it is now at position (0,0)? Does it behave as if a Gcode command caused the new position, or does it look like the FW crashes and causes tinyG to hard reset, which would set a new zero at that location?

    Does the reset event occur at the same location in the Gcode file, or is it random?

    If it appears to be a random hard reset, any reason to suspect power droop or similar?

    What Flow control ar you using between CoolTerm and TinyG (RTS, Xoff, …)?

    Are you monitoring tinyG status messages? Are they revealing any useful info?

    I’ll pause there.

    April 21, 2016 at 9:40 am #9569
    dwhughes08
    Member

    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.

    April 21, 2016 at 11:14 am #9570
    cmcgrath5035
    Moderator

    Interesting.

    My interpretation of what you write is somewhat different than yours.
    AFAIK, there are 2 correct ways to set a zero
    1. A hard or commanded tinyG reset
    2. A Gcode sequence, such as G28.x
    To that list I suppose we have to add the possibility of a major tinyG barf while interpreting G code that has similar effect to #2.
    A #1. event would be obvious, I think, due to flashing LEDs and startup messages issued to the upstream channel, which you do not see.

    I believe there is a way for CoolTerm to T the upstream response into a file, so you could scroll thru it and see where the change to zero position occurred. Have you tried that?
    I find it difficult to comprehend a #2 event, intentional or barf, that would not be revealed in status messages.

    What generates your Gcode?
    Did you make manual ‘enhancements’ ?

    RTS/CTS flow control is probably the most reliable of the two.

    Have you ever tried Chilipeppr?
    It implements a closed loop flow control and command aduit mechanism that might be helpful debugging here.

    • This reply was modified 8 years, 7 months ago by cmcgrath5035.
    April 22, 2016 at 8:29 am #9572
    dwhughes08
    Member

    The gcode file is generated from Inkscape, then modified. This particular file includes a first line G28.2 X0 Y0, the subsequent lines are a series of three lines staring with M03, G01 X… Y…, and M05. The last line G00 X0 Y0. The machine performs homing then contiues correctly until a zero reset in the middle of the “plot”, then continues with the correct offset from that point out of alignment from the start. The hard reset occurred approximately 45 minutes in the operation.

    I have not investigated if CoolTerm can capture the output while spooling the gcode file. I will check to see.

    I have not tried Chilipeppr, but will look into it.

    Regards,
    David

    April 22, 2016 at 12:38 pm #9573
    cmcgrath5035
    Moderator

    What are your values for
    $qv (1 is typical)
    $sv (1 typical)
    $si (250ms typical)

    With these typical settings, you should get 4 reports per second streaming across CoolTerm window.

    A useful debug feature in CP is that the execution of each line of G code is tracked – an on screen indicator changes status when a line executes (as well as having been sent to the queue)

    April 27, 2016 at 4:10 pm #9609
    dwhughes08
    Member

    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.

    April 27, 2016 at 9:18 pm #9612
    cmcgrath5035
    Moderator

    Looks encouraging.

    For sure, disable un-connected limit switches.

    Good luck

  • Author
    Posts
Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.