Most frustrating is the fact that you can sit and precisely drive the UTM to pick up a tool, for example, note the coordinates, and plug it all into the app. Then tell the unit to go to its pre-determined zero location, then execute the sequence, and it will be slightly off because where it thought zero was, isnt quite the zero spot that it started at.
Im beginning to understand that having the encoder functions added will improve this situation, but in the meantime this going to be VERY frustrating.
I have made a physical hatch mark on the tracks for all three axes to note where that arbitrary zero point is, and it clearly doesnt return to that spot exactly. It may be off by +/-4-5mm, but thats usually enough to mess it all up.
Has anyone got one of these up and actually running? Whats the trick here? I don’t see myself getting to do any planting this season at this rate…
The problem is that there is some slop in the system so that what is home/0 at the start of a sequence isnt the EXACT home/0 that it returns to. It is generally off by about 4-5mm, which is enough to throw it off for the next maneuver. You can tell this if you make a physical mark on the structure and compare before/after a sequence.
Can you give me an outline of how you recommend calibrating the zeroing the device? Im using a system that I purchased through farmbot, so assume that its the same as right out of the box (ie, no jumpers or alterations anywhere).
Also, I have been fiddling with the new software update (which is much better and responsive, btw), and found that the calibration sequence (with encoders enabled) works on the Y and Z axis but not on the X axis. Pressing ‘Calibrate X Axis’ results in no movement or activity, no matter where the unit starts from along the axis.
Now just noticed that its getting the Y and Z axis confused at times. After calibrating both, I went to HOME the Y axis and the Z axis is moving (very very slowly for some reason) instead.
The update is more responsive, but still some significant bugs to work out…
The other axis want to go to 0 when you home another axis. I have a fix for that but not in this version.
Calibration doesn’t really do anything for the 0 issue. You have to use Home function to get at zero. It’s more a matter of getting encoder missed steps/decay and max/min speed tuned right but I haven’t gotten enough time to play with that.
Also I’m working on getting sensitivity of encoders much better so it sees the difference between a rough patch and hitting home much better.
Ok, so what do recommend as a procedure to get everything calibrated and running properly with a good, reliable, robust zero reference point so that time spent on generating sequences will not be wasted?
Automatic calibration: With encoders enabled, press the HOME X, HOME Y, and HOME Z buttons in the advanced section of the Hardware widget on the Device page.
Manual calibration: Move each axis to the end (zero) and press the ZERO X, ZERO Y, and ZERO Z buttons in the Hardware widget on the Device page.
home Z works erratically (see above thread for all three).
It does NOT (I repeat in the boldest of bold, NOT) return to the same spot after this procedure when you park it at 0,0,0. The same is true for manual homing. It is generally off by a 4-5mm or more. This makes sequencing impossible and a waste of time.
Can you provide a log from the bot when trying those functions. This you should be able to get from <your_farmbot_ip_address>/firmware/shell. In there should be why the home fails. If that doesn’t work at least a lot of the stuff when you click the top bar where it says that it’s busy.
Also make a clip when you move. The sound and movement can provide indications of what goes wrong sometimes. Home movement for X fails only when there are many missed steps, so encoder gives no results or track is not great.
What is exactly the repeatability of your bot? If you move X 1000 and back again (or for Y and Z) it will also probably fail although it’s guaranteed that the bot will send the exact amount of steps to the motor. That would indicate the motor is missing steps, meaning the track is not smooth enough, belt tightness not perfect or wheels to tight. It helps to lower the speed to very low. 100 or 200 steps per sec in some cases or use always-on for the motors.
If the hardware can not be corrected then you have to wait until I can upgrade the software to compensate for that . That takes time.
Tim - just getting to this now. Can you tell me how to access the log file specifically? Also, is there an address where I can send you some video of what Im talking about?
The gantry usually moves smoothly along all rails with no binding in any axis. I thought I had dealt with the ‘stuttering’ problem before, but apparently not. I have increased the Vref to 1V on both sides of the X-axis and am still having this problem where the motor will rapidly change direction back and forth while it should be accelerating on the X side which results in that side lagging a bit. Ultimately, this leads to problems with returning to zero. But, in addition, when it doesnt stutter, it still does NOT return to the exact zero point. It is usually off by about 4-5mm which makes any future operation pointless.
You should be able to upload a clip to this forum. Or you can use tim farmbot io.
I find it weird that a motor would change direction rapidly. The direction signal is set at the beginning of the movement and not changed afterwards. In my setup with the current released version I get an exact return to the belt clip, not using any encoders. I do keep the speed limited to 400 at the moment.
The motors have two coils, right? If one coil isn’t working, only half the pulses move the motor. But because it depends on both coils, only using one coil each pulse could pull the motor one step forward or one step backward.
If the coils are fine, it can be the stepper driver which doesn’t send the pulses to the motor correctly.
