I am having issues with my Z - axis and it has made me look at the whole thing.
When my Z-Axis is moving up or down, it makes a strong click sound roughly every 2 seconds.
Without power, it is super smooth and has no resistance or noises.
What is more interesting is the frequency of the sound is consistent regardless of the speed.
Original speed was 16 (3 Revs per click) and I dropped it to 6 (1 rev per click), The frequency of the click was the same.
This makes it less likely to be hardware and more likely to the software.
Does anyone else’s Z-axis have a rhythmic click? It is like a micro-pause.
After investigating this further, the click is noticeable on the X-axis as well. (I have not tested the Y)
To test this, get the X-axis to move a long distance and gently squeeze the cog that drives the belt so you can feel the motion (Not to stop the motion but to feel it). You will be able to feel a click about every two seconds. What is this? My expectation is there should not be a rhythmic click. This appears to be something in the common motor drivers. @jsimmonds Mr LUA code. Any thoughts on this one and do you have the issue on your system?
Er, not on my device . .it’s headless
i.e. (power supply + electronics box) - (motors,encoders,peripherals, . . .) which is fine for doing any FBOS development / testing.
Maybe one day I’ll build out a bot but not sure I can ever get interested in the snail-paced axis movements.
I noticed the same behavior years ago and tried to find the firmware version where it started. If I remember correctly, it came up around firmware version 4.0.0 but was not able to find the cause of it. To rule out mechanical issues, my testing system was only a mega2560+ramps with 1 single motor on it and there was a noticable click on the motor while it was moving.
No one else reported this issue, so I thought its caused by driver/mega compatibility …
Hi @Ascend
Well I think we have a common underlying issue. As the rig moves, users are ignoring the clicking issue. The fact it is at circa 2 seconds, regardless of speed, sort of rules out any hardware.
For background, I purchased FB in November 2022 and built it in Feb 2024.
Immediately I had reliability issues with the water head (which I have a design change that solves that) and recently a Z-axis motor dropping issue when it is permanently powered. The reason I lubed the Z-axis was to attempt to address the clicking, but all it did was cause the Z-axis to drop requiring the motor to be permanently powered. When permanently powered, it overheats (it appears) and then drops, even when not performing moves. As it did nothing to address the clicking, I investigated the issue further to find the same issue on the X and Y axis, proving it is not hardware-related. Therefore, it is either software or firmware.
How do I report faults to FB for fixing? (both hardware and software)
Wow. I have looked through the source code (well, some related to the movement for any timing reference). I have come up with nothing.
This makes me wonder if there is a regular check for missed steps or something like that. Does the FB check for a missed step every step that is made, or is it a periodic check? The weird thing is that regardless of the movement speed, each axis has the same issue. This indicates that it is well embedded in the core routines that are executed during the movement cycle.
I do not know this language so I will need to do a bit of reading to understand what I am seeing. The good thing is the language is almost readable, without knowing too much about it.
That’s good, because I don’t believe this issue arises in the FarmBot Inc. code (which cannot run alone on the Farmduino bare metal).
To me, most likely, it’s somewhere in the foundation framework provided by Arduino IDE.
If the Arduino IDE allows us to setup runtime execution profiling that would be our best chance to find the root of this long standing (thanks @Ascend) issue.
Agreed, though the root cause might still be in effect but not noticeable while the steppers are idle / on holding current.
I think no one noticed because it still moved - therefore still working. I am a new user and assumed it was just part of the way it worked. When I developed Z-axis issues, it was only then I started to investigate movement and noticed it was not hardware related as the click frequency was consistent on time, rather than speed of rotation.
This information is really helpful and I think I am going to go code diving in the next few evenings.
@mvillion I also noticed this. But it works so did not pay it any attention. Since the frequency is not related to the speed of the motor, and the frequency sounds like once a second, it might have to do with feeding back info over the uart and not controlling the motors when sending data back?
Stopwatch on my phone measured almost exactly 4/7 Hz.
I’ve installed Arduino IDE and will attempt to build bespoke firmware for my Farmduino (v1.5) to see what frequency the Arduino framework calls loop().
@voortwis this is the best theory that I’ve seen so far. In fact you can “prove” your basis if you have a v1.4 or newer Farmduino. These have a Green TX LED that indicates traffic from Farmduino up to Raspberry Pi. If you can setup a means of “hearing” or “feeling” your axis stepper while it’s in motion for a long movement, you can exactly correlate a burst of Green LED flashes with each “hiccup” in the stepper travel.
Great suggestion, and proven, here is a short UART and tick movie . It is not really visible but per tick it flashes really short and then a bit longer, during the tick. That might be the moment the entire state of the Farmdruino will be sent back?
I don’t know what the baudrate settings are, maybe these can be maximized. And the sending back of info is also done in all 3d printer firmwares. Maybe the solution might be found there.
oh this is interesting. I have my Z axis permanently powered and it also drops even when not in use.
at first i thought it was resistance while planting seeds causing it to lose a few steps and, over time, fail to return to true 0.
however, now i’ve noticed that even when watering and its resting at 0 the entire time, it returns everything to home at the end and the Z is sitting around -100
My poor expression I guess. Agree that while the axis motor is “cruising” at set top speed, the periodic stutter is synced to the Green LED flash on the Farmduino (at fixed 0.57 Hz).
I meant that the major movement stutter that we hear and feel is comprised of closely-spaced “micro-stutters” which become separately audible at various axis top-speeds.
but not sure I can ever get interested in the snail-paced axis movements.
