tinyg odd communication

Home › Forums › TinyG › TinyG Support › tinyg odd communication

Tagged: ,

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • January 1, 2020 at 5:43 pm #11736
    dswillows
    Member

    Greetings;
    I have a problem during setup that I can’t find info on- when I follow the full setup, (I’m in the section :Test Drive your TinyG) I encounter an error when trying to test the communications. If I try: $test=1 (or any test command)
    the terminal in coolterm returns:

    err: Invalid or malformed command: (MSG**** Smoke Test [v1] ****)
    **** Smoke Test [v1] ****
    tinyg [mm] err: Invalid or malformed command: G00 G17 G21 G40 G49 G80 G90
    **** Smoke Test [v1] ****
    tinyg [mm] err: Invalid or malformed command: m3g4p1
    **** Smoke Test [v1] ****
    tinyg [mm] err: Invalid or malformed command: m5g4p1
    (error repeats for multiple linest)

    $sys output:
    [fb] firmware build 440.20
    [fv] firmware version 0.97
    [hp] hardware platform 1.00
    [hv] hardware version 8.00
    [id] TinyG ID 3Y2462-PPX
    [ja] junction acceleration 100000 mm
    [ct] chordal tolerance 0.0100 mm
    [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 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
    [js] json serialize style 1 [0=relaxed,1=strict]
    [tv] text verbosity 1 [0=silent,1=verbose]
    [qv] queue report verbosity 1 [0=off,1=single,2=triple]
    [sv] status report verbosity 1 [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 1 [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 1 [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]
    tinyg [mm] ok>

    Any ideas in this instance?
    Thank you,
    Dave

    January 2, 2020 at 8:49 am #11737
    cmcgrath5035
    Moderator

    Hmmmm, interesting.
    I have never tried these Test commands and don’t have an active machine available at the moment.

    I don’t think it is an issue, but see you have $ex set to 1 (XonXoff)
    Is CoolTerm set for XonXoff?
    Or try RTS/CTS.

    January 2, 2020 at 10:02 am #11738
    dswillows
    Member

    Thanks for the inquiry- I did try setting/aligning both values, no dice. I thought maybe setting the json tag ($ej) to 1, however it seems the variable can’t be changed(?)

    Some background: This tinyg board was functioning in the past, I tried starting from the beginning to find out why I’ve lost control. The troubleshooting section doesn’t seem to have a similar experience to relate to 🙁

    January 3, 2020 at 6:55 am #11739
    cmcgrath5035
    Moderator

    Hmmm, please define “lost control”

    From your top post, issuing $sys creates a proper looking response, so I conclude basic command interface is sort of working.

    Are you sure CoolTerm and tinyG are running at same baud rate(115200)?

    Changing $ej can be tricky, because tinyG auto switches between Text and JSON based on the format of a command from Coolterm to tinyG.
    So send a text command, get text response; send JSON formatted command, get JSON formatted response

    January 3, 2020 at 11:07 am #11740
    dswillows
    Member

    Thanks for the knowledge on $ej.

    Defining lost control:
    Had a functioning machine using chilipeppr, cutting 3D paths with what seemed like random kills during larger gcode files.
    The suspects at that time were the limits with false triggers or maybe com errors due to using a piZeroW for JSON server. I left this unresolved for a time, and looking at resolving this recently I peeled everything back to the beginning (hence the $test) due to strange behaviour, such as:
    Strange things in chilipeppr, like energize motors cmd seems to work(motor LEDs emit green & test motor resists). However I have no manual jog or any gcode spits out a quick LED pulse of tx & rx without performing motion.
    And the strange thing in coolterm as mentioned is the $test cmd failing.

    So currently I’m back to the board’s setup instructions,start fresh… just coolterm and one small test motor driven with tinyg internal driver.

    January 3, 2020 at 8:53 pm #11741
    cmcgrath5035
    Moderator

    What you describe sounds like a noise issue with your limit switches, maybe.

    I have no experience with PiZero, but Pi3 works great so I do’t think it is Pi’s fault.
    Do you have shielded twisted pair to you limit SWs , shield grounded only at tinyG end?

    Since I have never run the tinyG tests, can’t vouch they actually work.

    January 4, 2020 at 11:29 am #11743
    dswillows
    Member

    Info was provided as I was asked to elaborate on the descriptor, “lost control”

    -no, the pi and the limits are not a concern, I have stripped back to starting from scratch, just coolterm (direct USB from win10). Limits are disabled.

    Back to the setup problem at hand,
    I’m trying to diagnose tinyg communications. So if test isn’t functioning, what process would one follow to test communication/operation of the board?

    January 10, 2020 at 1:10 pm #11749
    cmcgrath5035
    Moderator

    Re-read a few items.
    Other ideas.

    Jog: It is fairly easy to configure Chilipeppr jog to request jogs that are too small to actually generate motion.The minimum specified jog that will move the machine the distance of one microstep. If you request a jog of microstep/2, you will have to send 2 jog commands. TinyG accumulates requested motion that is less than a microstep, adds that to the next request.

    Motor LEDs. each motor has one LED connected to one of the two stepper windings. Run a continuous stream of G code and you see flashing lights, cool something is happening. But the LEDs toggle based on winding polarity and randomly when the specified motion calls for reverse polarity the LEDs do not flicker. So the LEDs are not a precise indicator of step by step motion.

    Most folks adopt one or more Gcode sequences that they run and look for
    1.expected results
    2. If codded to start from X1,Y1,Z1 and return to X1,Y1,Z1 an end of sequence, does that actually happen?

    As for the strange behavior you see with the TESTx commands, you might get some help from posting here https://github.com/synthetos/TinyG/issues

    January 11, 2020 at 5:13 pm #11754
    dswillows
    Member

    On an aside, sending any gcode returns an error- such as:

    tinyg [mm] err: Invalid or malformed command: G0X100

    January 11, 2020 at 9:08 pm #11755
    cmcgrath5035
    Moderator

    I am thinking perhaps something is corrupted in EEPROM.
    Send a $$ command, capture the resulting parameter list in printout or ascii file.

    Send a $defa=1 command to clear and reset EEPROM to a ‘factory default’

    There reset all parameters, one at a time ,., from a command line interface.

    Reboot tinyG (power cycle) and see if situation has improved.

    January 12, 2020 at 12:59 pm #11756
    dswillows
    Member

    I see you have previous posts that mentions this- unfortunately the same error/behaviour after the factory default 🙁
    You mention in forums about corrupted EEPROM, and the steps for FW re-install …I will try those instructions next

    January 12, 2020 at 3:26 pm #11757
    cmcgrath5035
    Moderator

    EEPROM can be corrupted if too many sequential parameter updates are sent too quickly. It often takes a lot of back and forth chat to find it, figured we would jump to it. Some of the parameters written to EEPROM are not viewable, so it can be hard to diagnose.

    Easier than doing a FW reload, and EEPROM more likely to get corrupted than flash.

    You will have to reload parameters after FW re-load as well.

    Make sure your Motors are enabled, by the way.
    $m1=2
    $m2=2
    etc.

    If still no work, copy your $$ parameter list to a cloud drive and post a URL here.
    I’m sort of running out of ideas.

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