TinyG Motor/LED Cutout

Home › Forums › TinyG › TinyG Support › TinyG Motor/LED Cutout

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • December 20, 2016 at 11:57 pm #10117
    tlprather
    Member

    Hello,
    I can’t seem to find any topic that relates to what I’m experiencing. I have been running very smooth, accurate, and reliable… until now. I’m running Chilipeppr – Tinyg V8 – Json. Chilipeppr has not been as responsive connecting TinyG through JSon. When I finally get it to connect, when I press z up or down (to jog test I’m connected) my Z goes up with up, then when I press up again, it goes down, down, down, then up, up, almost in this weird cycle, but never goes beyond this pattern, and repeats. Then I look on the TinyG board and the LED light for the Z axis (motor 4) is not illuminated (as it was before), or dimly lit. I’ve tried reset, the only way to get it lit back up is when I power cylce the unit and power supply. But when I get re connected it and I Jog the Z axis, again… repeats as before. I’ve had it go away, then re-appear, then move to a different motor on the board or multiple. Happens with Mac or PC. I’ve thought the firmware corrupted, but it won’t let me update, or reinstall, as it either has a verify failure through Tinyg Updater App, or onboard Chilipeppr bootloader won’t connect. Pardon me, but WTF? How does this just happen?

    Yes, everything is well connected, grounded, shielded. Out of process of elimination, its one of three – TinyG, Chilipeppr, or JSon. Like I said, has worked incredibly well and reliable… please read my description of the problem carefully before asking me the usual diagnosis questions. Not to be rude, but I have read almost every post on this forum, and others that could possibly relate.

    It seems as if it is being sent information to trigger these motor cutouts or failures.

    Any help/thoughts/insight very appreciated. Thanks.

    December 21, 2016 at 12:25 am #10118
    Zootalaws
    Member

    Can you use a different method than chilipeppr and get the same result?

    If you connect through a serial comma programme (coolterm, etc.) what response do you get when you jog?

    If you connect a different motor to axis 4, does it work ok?

    December 21, 2016 at 6:32 am #10119
    cmcgrath5035
    Moderator

    A couple more background questions to add to Zootalaws:
    note-> Assume my questions relate to your adventures on PC.
    I have no direct experience with MAC and we don’t see much MAC commentary on which to base suggestions.

    What version of SPJS are you running?
    Are you running SPJS on your PC or on a RasPi?
    Has the Synthetos tinyG-Updater (PC version) worked for you in the past?
    Has the SPJS FW updater worked for you in the past?

    Why do I ask?
    Some folks have had issues with one or both of these FW update methods, some often never resolved.

    The methodology used by tinyG-Updater and by the SPJS updater are virtually identical
    Step 1 – Connect to tinyG
    Step 2 – Send $boot=1 to enter bootloader mode
    Step 3 – Disconnect from tinyG
    Step 4 – spawn an avrdude session which connects to tinyG bootloader, manages the download and does the verification. When ‘verification’ fails, that message is from avrdude.
    Comment – You will see that Steps 1 – 4 are really the same as the manual procedures documented in the Wiki pages.

    In your initial information, you say ” Chilipeppr has not been as responsive connecting TinyG…” which might be a hint to FW load problems.
    My experience, chasing similar failures, has been that the updater and SPJS FW apps don’t handle failure to initially connect real well, frequently a download does not really happen and a verification failure gets reported, but nothing ever really happened but you are left thinking it was a verification failure.

    Also keep in mind that all this is VERY platform and version specific. SPJS uses avrdude binaries that are compiled for PC, MAC, Linux(x86), Linux(ARM)[RasPi], etc. Not all versions are well tested. tinyG-Updater and SPJS application were both released just before Win10 was released, so we could be chasing issues with on-going updates to Win10, if that is what “PC” means to you.

    Put aside FW update for the time being – that needs to be resolved for sure but core FW corruption is less likely than FW parameter corruption, those parameters are stored in EEPROM(on the controller). Parameters include those you normally tweak (the $$ list) as well as internals that are used by FW.

    What caught my eye reading your initial description is your “is not illuminated (as it was before), or dimly lit …..” comment.
    The motor LEDs are rather simplistic – one LED per motor is logically connected to one of the two motor winding drives. When motors are in motion, windings are always toggling and you see flashing bright leds.
    If motors are at rest but energized, sometimes only one winding is required to ‘hold’ current position. There is a 50/50 chance that the LED is connected to that winding, so sometimes the LED for a particular motor is not lit but the motor is still held, until motor timeout.
    Since the motor LEDs are really on/off, the explanation for a ‘dim’ LED could be too-narrow drive pulses to the LED.
    Also, since direction of rotation is controlled by the relative phases of the two windings, if (one or both) winding pulse trains were too narrow to be effective, direction control might be lost – a symptom you have.

    Narrow drive pulses could be caused by EEPROM corruption.
    Best way to fix that is to ‘factory reset’ tinyG to the initial parameter set installed with your last code download.

    Method:
    Step 1: Connect to tinyG
    Step 2: Create a $$ parameter dump and save it to a file on PC.
    Step 2.5: Post a copy of your $$ dump to a cloud drive and provide a URL if you want, it might show some corruption (unusual values) but might not if it is ‘internals’ corruption
    Step 3: From the Chilipeppr console window, send a $defa=1 command. This will reset you parameter set to something undoubtedly not correct for your machine.
    Step 3.5: I usually reboot (push the button) at this point, might not be necessary
    Step 4: From the SPJS console (or CoolTerm, etc), re-enter your machine parameters one at a time.

    This is a rather invasive procedure, but sometimes the only way to regain sanity. A FW download would have the same effect, but for the moment that is not working for you either.

    Feel free to ask further questions if I have made some incorrect assumptions.

    December 21, 2016 at 2:34 pm #10121
    tlprather
    Member

    Hello, Thanks for the quick response and feedback.

    I have used Coolterm in the past, but did not think to go back to basics to see if this problem follows. But I will, Thanks..

    I am using the most current SPJS for Mac I think its v1.92, and v1.86 and I have a Windows 7PC that I run the most current SPJS as well.

    I had previously reset to factory default, but I will again, but this time I will use Coolterm to input. Its so easy to do this with Chilipeppr, but maybe this is where error is?

    If its EEPROM courruption, what causes this, especially when everything was working great?

    I was using gcode produced by F-Engrave when this happened, but had no problem running the files. Can this have an affect? I have had this happen once before prior to running this gcode.

    December 21, 2016 at 9:36 pm #10122
    cmcgrath5035
    Moderator

    I don’t think there is a good diagnosis for the root cause of EEPROM corruption. There have been instances when it appears that the CP parameter wizard was causing some corruption, but for others it worked fine.
    When in doubt, use CoolTerm or the CP Serial console, one parameter at a time.

    It could be dependent on the ‘horsepower’ (cycle time) for the SPJS client, a cpu that runs faster throws tasks at tinyG faster, perhaps finding a hidden glitch.

    Some Gcode generators have spawned movement math errors(bugs) in tinyG, but your problem sounds different

    December 26, 2016 at 11:55 am #10135
    tlprather
    Member

    Solved –

    After using Coolterm to see if the problem persisted, did another factory reset, entered all parameters in one by one…. this did not resolved the issue. The Z axis still sporadic.

    So, working backwards, again I went through the whole wiring setup to see if something had came loose or was causing some sort of short, by gently tugging on all wires. Found it!

    This now makes sense, one of the 4 wires in the connector to the motor had worked it itself out, but stayed in contact while the machine was in motion, until it wasn’t. More often then not, it seems that this is the usual suspect.

    Thanks for the help, sometimes it seems that working on the CNC is more of a journey then a hobby!

    I still have not been able to solve the firmware verification failure.

    December 28, 2016 at 6:46 pm #10141
    cmcgrath5035
    Moderator

    Working with the super fine stepper motor wires can be a challenge.

    I really like ferrules when playing in this space.

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