Tinyg stopped working

Home Forums TinyG TinyG Support Tinyg stopped working

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #9508
    halfdane
    Member

    What do I have?
    – tinyg v8
    [fb] firmware build 440.20
    [fv] firmware version 0.97
    [hp] hardware platform 1.00
    [hv] hardware version 8.00
    [id] TinyG ID 3X3566-X3H

    What worked?
    Yesterday, I test drove my drawer-slides-cnc with 3 nema 17 steppers and all three axis moved fine. I could see the blue power and the red PWM constantly alight and the green motor LEDs flashing in time with motor movement.
    Since I’m on Linux, I use cutecom to communicate (chilipeppr worked as well: jogging, direct position, chilipeppr-logo example).

    What doesn’t work?
    Today, I can communicate with the tinyg-board (I see the tx flash), but the motors don’t move and the Mot*-LEDs don’t flash when I issue a G0 or G1 command (though the power and PWM LEDs are shining constantly).

    What have I tried?
    – $$ gives the above information and lots of other, too
    – $me lights the LEDs up and the motors stall (as I would’ve expected)
    – $md turns them off again (LEDs and motors)
    – $defa=1 did reset all the setting (despite printing lots of “File not open”-messages)
    – power off of both my laptop and the tinyg

    Between each of these, I issued G0 and G1 commands on all axis and with different values, but to no avail.

    Similar Topics that don’t seem to fit:
    https://www.synthetos.com/topics/synthetos-board-does-not-respond/ : I have no spindle-lights blinking and I can communicate with the board
    https://www.synthetos.com/topics/tinyg-stopped-responding/ : I can communicate with the board

    Since I got the board fairly new and am still tinkering around, I think I might have misconfigured something, but a $defa=1 should have saved me, shouldn’t it?

    #9509
    cmcgrath5035
    Moderator

    – $defa=1 did reset all the setting (despite printing lots of “File not open”-messages)

    the defa=1 command resets tinyG to a compiled-in set of default parameters which are not likely useful for your machine.

    After defa=1, you need to re-enter your parameters.

    Send a $ or ? command from cutecom – if tinyG responds, the USB link is working.

    If problems continue, copy your $$ dump to a text file and post it to a cloud drive, post URL here

    #9518
    halfdane
    Member

    Yes, the USB-Link is working, I just would’ve expected the motors to be energized, however wrong configured, so I could start over.

    Outputs from the mentioned commands:
    $: https://gist.github.com/halfdane/0951c7a064b08745c3a9a5d8c8c28912
    ?: https://gist.github.com/halfdane/5c28b55d385dbeb0dd589ca289f7affd
    $$: https://gist.github.com/halfdane/3409889dc58ffaf50f35eddbb86cd790

    Thanks for helping me out.

    #9521
    cmcgrath5035
    Moderator

    I would suggest you turn all limit switches off until you get basics going.

    I am not sure what the effect of $xjm=0 might be (and Y and z).
    Is there a particular reason you did that?
    A value of zero might cause the motion computation to blow up.

    Have you studied

    I am not really sure what your machine looks like, mechanically, so a bit difficult to comment on parameter specifics.

    You can turn off the PWM led by setting $p1pof=0.0.

    #9522
    halfdane
    Member

    My motors are not very good: they always stall when cruising. I fiddled with the jerk-setting and $xjm=0.1 worked on all axes.
    Apparently this value has silently changed to $xjm=0 since then. Could well be the cause of my trouble, couldn’t it? I’ll try setting the value to something higher.

    I have studied the configuration-docu, but that chunk was a bit too big for me to chew :/

    I am surprised that you found limit switches configured, since I don’t have any (and I think I didn’t configure them). I will try to turn them off – will be a good starting point into the configuration-docu 🙂

    #9523
    halfdane
    Member

    Thanks, I got it to work.
    Apparently it was the $xjm settings – seems like tinyg doesn’t like max-jerk values between 0 and 1 (and indeed does display them as 0).

    Setting $xjm=0.1 in cutecom doesn’t trigger the problem though: to reproduce it, I opened the “Configure TinyG”-Dialog in chilipeppr, changed p.e. the velocity max and saved it. Opening again and saving again would trigger the problem again.

    To get rid of it, it is not enough to open cutecom and set a proper xjm-value once for all axes: I have to hit tinyg’s reset button and set the values again until I don’t get the answer {“er”:{“fb”:440.20,”st”:9,”msg”:”File not open”}} . Mostly that means setting them twice, but I had three times as well.

    I can see that my setting the $xjm=0.1 is an uncommon one. Then combining chilipepprs’ configuration dialog with tinyg’s displaying ‘0’ when ‘0.1’ is configured, resulted in the problem. I still don’t get why I have to set the xjm twice (“File not open”), but knowing how to get back to safety allows me to keep exploring without fear of breaking the board.

    Thanks for helping a n00b 🙂

    #9524
    cmcgrath5035
    Moderator

    A Typical $xjm is =5000, why are you messing about around 1?

    I would suggest setting tinyG parameters from CuteCom or the CP Serial port console command line, one at a time. The configuretinyG widget seems to mess up some times, a bug ?

    #9525
    halfdane
    Member

    Thanks a lot, that showed me I had to do some more configuration and indeed I found that my motors don’t have a step angle of 1.8° (which I assumed to be some kind of default) but 3.75°, which changed about everything 😀

    With that in place, I was able to adjust my xjm to 5000 and xfr to 180 and today I managed to draw the chilipeppr-logo with a pen in the tool-holder \o/

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