I have been spending a lot of time sitting with the FB to make sure I can trust it. It is through this that I have seen lots of the issues I have reported.
I have noticed that sometimes when the X-Axis is moving, the far end of the gantry (away from the control box) stops and is dragged by the closer end (at the control box).
UPDATE: I have worked out what this is. It is not a motor drive mismatch at all. The left-hand side is catching as it crosses the joint between the two rails. This is new behaviour. When installing I made sure the top was perfect but did not considered underneath
This would be lovely. Your reply indicates that the second X motor is not currently monitored in a feedback loop. Is that true? I would be keen to get that addressed and I certainly did not like the way the frame twisted as it got caught.
2 weeks ago I searched the code where the second x encoder is used, could not find any location. Best update for the firmware now would implement some monitoring and correction logic on the second x axis stepper. Maybe also on the first and detect a stall when correcting of any fails.
I have been thinking about closed loop nema17 motors (MKS SERVO42C PCBA). And then there is even an option of controlling the motor over i2c connection. Removes a whole lot of wiring from the FB. Just add all motors on a ‘power bus’ and add the closed loop drivers on the i2c connection with different addresses and all is set. Question remains, how will the i2c work on the a bit longer distances.
Hi @mvillion . . I was aware (has been discussed in here somewhere) that X-axis positioning is only coded for the X1 motor. The X2 motor is purely blind best-effort motion (as you’ve found).
IIRC (a big ‘If’) the forum reply talked about an MCU/software bottle neck causing lost steps when 4 encoders were tested and doing a simultaneous 3-axis movement.
Good project for some owner keen on getting dirty hands in the Farmduino hardware and firmware
I can confirm that the firmware currently (and never has ) supported the X2 encoder. Initially this was for performance reasons because Genesis v1.2 and v1.3 only had the Atmega 2560 to do everything and we were really pushing its limits even tracking three encoders.
Since Genesis v1.4, we added a much more performant STM32 co-processor just for tracking the encoders, which it has no problem doing for all four. However, we never actually got around to implementing the stall checks for the X2 encoder.
Absolutely! If someone is willing to help out with this firmware addition, we can certainly offer QA support and ship the new firmware with a future FarmBot OS release! Note: such additions would need to only apply to Genesis v1.4+ kits (no Genesis v1.2, v1.3, or Express v1.0 or v1.1).
) supported the X2 encoder. Initially this was for performance reasons because Genesis v1.2 and v1.3 only had the Atmega 2560 to do everything and we were really pushing its limits even tracking three encoders.