Forum Replies Created
-
AuthorPosts
-
vicente95650
MemberYes, 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.
MemberThanks 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.MemberNever 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!Memberyes, 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.MemberIt seems like I fixed my problem.
The only real problem I had was with my (poor) wiring of the homing switch.
It turned out I had broken my wiring once I connected my 2nd Y axis motor.The conceptual problem I had with the documentation was simply that I was remembering incorrectly what I had read! I can in fact set the “travel per rev” parameter for motor 4 in mm as I need to.
All is well with homing my Shapeoko using dual Y axes!
-
AuthorPosts
