false activation of homing switch

Home › Forums › TinyG › TinyG Support › false activation of homing switch

Tagged: 

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • January 29, 2014 at 1:42 pm #5307
    vicente95650
    Member

    I have TinyG version 7 driving a Shapeoko machine with Nema 17 motors.
    When homing an axis (e.g. X axis) the X axis homing switch (normally closed) appears open and TinyG thinks it has reached HOME and does its thing.

    To rule out my cabling as the culprit, I unplugged my switch cabling and shorted the Xmin pins right at the header on TinyG. The problem persists. This means the wiring on the board itself is picking up noise presumably from the motor drive signals.

    I am powering TinyG with a hefty 14 amp supply and driving a single motor when the false tripping happens; so I do not think the problem is dipping of the 3.3V supply. My suspicion is that there is a significant loop area at the switch inputs on the PCB e.g. if there is no ground plane underneath the input lines and that this loop area is picking up noise from the magnetic field created by the currents that drive the X axis motor (in spite of my having used twisted pairs to drive the motors to minimize the magnetic fields created by the wiring). If such is the case I don’t see how I can fix the problem form the outside other than (perhaps) by adding capacitors as you have done in version 8.

    Can you tell me if there is an uninterrupted ground plane under the input lines in version 7? This will at least tell me where to spend my energy next.

    Thanks!

    January 29, 2014 at 6:45 pm #5310
    alden
    Member

    Hard to know what is going on here. Do the other axes react the same way? Are the limit switches disabled? I have not seen this effect. Can you post your settings?

    January 29, 2014 at 9:49 pm #5312
    vicente95650
    Member

    yes, the other axes behave the same way. Sometimes the homing switches do not trip but at other times they do trip falsely.
    I am concentrating on troubleshooting the X axis just to simplify the situation.

    I am using the switches Xmin, Ymin and Zmax for homing only. I have disabled all other switches.

    Can you confirm that when homing the X axis TinyG will ONLY pay attention to th (enabled) e X axis switches (and similarly for the other axes)? I read somewhere that TinyG may be affected by a change in status of ANY switch when homing only the X axis.

    Thanks.
    Understanding this will help my troubleshooting.

    January 30, 2014 at 12:06 am #5313
    vicente95650
    Member

    Never mind! My problem was not noise on the homing switches after all, but rather that I did not have large enough maximum travels (after having changed my belt type) for my X and Y axes. It appears that TinyG behaves the same way if, during homing of an axis, either the home switch is activated OR the maximum travel is reached! The randomness of the behavior was simply due to the fact that I was moving the axis manually to some arbitrary initial position prior to invoking the homing sequence.

    After programming the maximum travels to a large value, everything works as expected!
    Thank you and sorry for the false alarm!

    January 30, 2014 at 7:19 am #5314
    alden
    Member

    Hey, no problem. To answer your earlier question, the switches are independent by axis. Only the switches in the tested axis are read – the others are ignored until it’s their turn.

    The behavior for homing an axis is that if either the limit or homing switch is active during the startup for that axis an additional move is made to back off that switch before performing the search to the homing switch. You figured this out, but I thought it was worth restating it.

    January 30, 2014 at 1:01 pm #5316
    vicente95650
    Member

    Thanks for the clarification.
    In my case what appeared to be happening is that the homing switch for the X axis was not active and therefore there was no need to move the X carriage away from the switch but rather towards the switch. When the maximum travel was reached the carriage came to a stop and then moved slightly away from the switch. This is exactly what happens if the homing switch gets activated before the maximum travel is reached and is the reason I though noise was causing the false switch activation. I had been expecting (not sure why) that exceeding the maximum axis travel would be interpreted the same as a limit switch activation (which would then require a reset) but instead it behaves as a homing switch activation (which does not require a reset). I had the limit switches for that axis disabled so I would only be susceptible to activations (false or otherwise) of the homing switch.

    January 30, 2014 at 1:38 pm #5317
    alden
    Member

    Interesting. It looks like TinyG should fail the homing operation if the max travel is reached. Better than accepting it an having the coordinates be off by some indeterminate amount.

    January 30, 2014 at 3:50 pm #5318
    vicente95650
    Member

    Yes, although it is usually clear, from the position of the carriage, that true home has not been found, when the max travel is reached and the carriage position happens to be “close” to home the operator can be fooled into thinking that true home has been found.

    In my case the consequence of such behavior was simply to confuse me into thinking that the only possible explanation was noise in the homing switch, especially since initially, when I was using unshielded cable to connect the homing and limit switches, I did have legitimate noise issues. I had fixed the noise issues by switching to coax to connect the limit and homing switches. I was therefore surprised to find what appeared to be noise issues re-appear when I changed my belting type such that my existing maximum travel settings were no longer sufficient.

    If you change the algorithm such that the max travel limit behaves the same as limit switches I will certainly update my tinyg firmware.

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