TinyG suddenly misbehaving

Home › Forums › TinyG › TinyG Support › TinyG suddenly misbehaving

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • June 26, 2015 at 11:32 am #7872
    Rural
    Member

    So yesterday our TinyG-controller router started to misbehave. I’m still trying to figure out the details but I can say that on some jobs it just locks up before doing anything. On the Chilipeppr logo job it starts and then quickly begins to do moves that have nothing to do with the job (luckily, all in the X-Y plane). Interestingly, Chilipeppr show the bit moving off the expected path as well.

    This all started yesterday. But it had been a couple of weeks since we ran a job.

    Has anything changed with Chilipeppr? Is a new version of the firmware needed? Any other ideas as to what the problem might be.

    June 26, 2015 at 12:11 pm #7873
    Rural
    Member

    In case it helps, here is the output from a $sys:

    [fb] firmware build 440.14
    [fv] firmware version 0.97
    [hp] hardware platform 1.00
    [hv] hardware version 8.00
    [id] TinyG ID 3X3566-HDH
    [ja] junction acceleration 3937 in
    [ct] chordal tolerance 0.0004 in
    [sl] soft limit enable 0
    [st] switch type 0 [0=NO,1=NC]
    [mt] motor idle timeout 2.00 Sec
    [ej] enable json mode 0 [0=text,1=JSON]
    [jv] json verbosity 1 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
    [js] json serialize style 1 [0=relaxed,1=strict]
    [tv] text verbosity 0 [0=silent,1=verbose]
    [qv] queue report verbosity 1 [0=off,1=single,2=triple]
    [sv] status report verbosity 2 [0=off,1=filtered,2=verbose]
    [si] status interval 250 ms
    [ec] expand LF to CRLF on TX 0 [0=off,1=on]
    [ee] enable echo 0 [0=off,1=on]
    [ex] enable flow control 2 [0=off,1=XON/XOFF, 2=RTS/CTS]
    [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
    [net] network mode 0 [0=master]
    [gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
    [gun] default gcode units mode 0 [0=G20,1=G21]
    [gco] default gcode coord system 1 [1-6 (G54-G59)]
    [gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
    [gdi] default gcode distance mode 0 [0=G90,1=G91]

    June 26, 2015 at 12:31 pm #7874
    Rural
    Member

    Think I solved it. It’s embarrassing. I’ll update in a few minutes here.

    June 26, 2015 at 1:19 pm #7875
    Rural
    Member

    So Chilipeppr now supports multiple hardware options (tinyg, grbl, etc.) when communicating with the SPJS. We had it set to “default”. Apparently, the behavior of that option has changed, or maybe we had used “tinyg” in the past and somehow got set it to “default” recently. It turns out that won’t work.

    The best part is that Chilipeppr even has an attention getting blurb warning users of TinyG hardware to use the “tinyg” setting for the SPJS. I managed to avoid seeing while my panic built for about an hour. Did a head-slap when I actually read the warning. My face is red.

    In any case, when we changed the option to “tinyg” everything began to work as expected. The cutting has resumed!

    John also caught this right away on the Chilipeppr Google group. That fact really impressed the machine’s owner, and myself, given my panicked description of the symptoms. One more believer in open source.

    June 26, 2015 at 4:47 pm #7884
    cmcgrath5035
    Moderator

    Details, details, details, so many details. of CP is in the way it manages the flow if data to, and status back, from tinyG .

    Much of the power of CP is in the way it manages the flow of data to, and status back, from tinyG . All of that is enabled by the choice of SPJS engine handler, “tinyg”.

    If have not yet, upgrade to SPJS 1.82. Much faster/more efficient.

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