Hi there
I have been performing deep soak test in an attempt to address the unreliable head change connection issue. I think I have solved with a small hardware and software change but I am not going to release the detail until I have had 100 clean mount then dismount cycles. So far, I have had 70 then a failure.
I have finally tracked down what has been causing the soak test failure and it is not the head loading process. (I think I have that solved.)
One of my X-Axis motors is failing or the code is failing.
The X-Axis has two motors. I set a small loop that moved from 2300 to 2700 then back again. Over and over again. After about 20 moves, there was a nasty clack sound. Diving into decoding that, I found the remote X axis motor was either dropping out early or not engaging when required. I know this my applying finger pressure on the X-Axis motor near the controller box and the resistance was strong and it never faltered. When I applied the same pressure on the remote motor, sometimes it stopped early and some time it started late. I expect the driving software is the same so I am expecting that the motor is faulty.
I have had random X movement retries in scripts but never understood why. I always assumed it was dirt on the track or plant material etc. It turns out that is not always the case but sometimes. it is the motor failing to drive. @roryaronson A quick question. Is my motor under warranty? If you have not sent my most recent order yet, can you just hold it a day or two whilst I get a replacement motor please?
As suggested a year ago I would like to see the use of both rotary encoders on the x-axis implemented instead of only one. This way (as long as the belt does not slip) the X1 and also X2 motors are able to autocorrect their position, preventing skewing the gantry. This is something deep inside the arduino-gcode processing what I am not comfortable changing.
@mvillion Do the moutning/unmounting isues have their origin maybe in this? I made it more reliable by just homing Y once and X 3 times to make sure i un-skew the gantry.
@roryaronson Do you see any chance in updating this to make things more reliable instead of 3d fancy looks in the browser?
The issue I was attempting to solve was poor connection between BC and the pogo pins so a mount would don’t verify via the verify_tool() code. I think I have solved that with a rearrangement of screws and magnets. It was when investigation that and creating a mount / dismount 100 times soak test script that the other issue of X drift on the remote X motor came up. What I do not understand is why the motor sometimes (1 in 8) stops driving with any force early, or fails to start driving in the next cycle. I think it is a failed motor. The finger pressure test on the close motor shows strong drive at all times where on the remote X motor it is only about 85 % of the time and the other times, I can stop the motor with finger pressure indicating a drive failure. I suspect motor issues over software but I cannot be sure without change the motor first.
With regards to the code that drive the remote motor but does not use the encoder, do you know where that code is located within the repository. I would love to look at the code as a self correcting error is better than not. I still need to replace the motor and see if that fixes the issue but my focus is reliability is my focus.
In this post here
You will see my software wrapper around head mounting. It has a built in routine that physically puts the head back and attempts to reload it 5 times before calling failure. In my soak test I got up to 70 first attempt successes until the X drift issue came into the equation. Ironically the retry part of my code was not needed, once I addressed the magnet arrangement within the UTM with 70 first time detections. Still. I like ‘safe’ code so you can trust a result.
From my superficial scan of the Farmduino MCU code, I believe commands to the X2 motor are fire-and-forget , so robustness and repeatability of X-axis movements depends on user/owner track/belt/device maintenance
edit
I think you’ll find that both X1 and X2 motor movements are commanded almost simultaneously (i.e. adjacent lines in the source code)
I agree to a point. When it can be demonstrated that the motor is cutting in and out, then it is out of the owners hands and a new motor is required - which appears to be the case with mine. I had to replace the Z-motor within a few months of new as it was loosing grip when powered and it appears that one X motor is doing the same.
@mvillion it is possible you are having an issue with your X2 motor, and I can send you a replacement under warranty. Though because the problem is intermittent and brief, my first suspicion is that the X2 stepper driver might be kicking on over-temperature protection. Potential fixes include decreasing MOTOR CURRENT slightly, adding a small heatsink to the driver, turning off ALWAYS POWER MOTORS for the X-axis (if enabled). But if those simple fixes don’t do the trick please email contact@farm.bot and we’ll get you a replacement motor shipped out.
@voortwis regarding the X2 encoder - this has unfortunately been on the back burner for a long time, but thanks for bumping the issue. For the next few months we’re still focused on reaching feature parity in 3D, but I think after that we can look into some long standing issues like this one.
Thanks for the reply. I do not run ALWAYS POWER MOTORS on the X or Y axis.
I have a script that turns it on for Z at the beginning of a sequence which keeps it nicely snug during execution then I depower the Z at the end of run.
You may not remember, but last year I had the same problem with the Z-axis as it would randomly drop when powered, then catch itself. A new motor fixed that issue nicely. This appears to be the same kind of event.
I was looking at the X2 encoder code but as there is no hardware connection, it is a bit of a significant project to make that work so I have parked that for future Matt to look at. LOL.
I am very focussed on the resilience and reliability of the Farmbot. I think I have a solution for the unreliable connections of BC to the pogo. With the combination of a script upgrade to reseat the head if not detected and a tweak to the UTM magnet arrangement, I have had 70 consecutive head changes without issue. My goal is to get up to 100 and then it is a success. I will then send photos, recommendations and the final version of the safe_load script.
