I’m testing out a modification to the vanilla Farmbot setup but need to increase the encoder scaling factor past it’s existing limit. Right now the device tab of the farmware web app limits the values sent to the arduino to 32,000.
Is there a way to remove or increase this limit? I’m trying to reduce the noise on the Z-axis by using micro-stepping (RAMPS 1.4 board with DRV8825 stepper drivers).
My hardware uses independent 400 pulse/rev encoders, 200 step/rev steppers and I wanted to get 1/32 micro-stepping. With the encoder factor equation this works out to be: 10000 * (200 * 32) / 400 = 160,000. Way smaller than the 32,000 hard limit.
So a lot more hacking of the firmware and I got around the farmware encoder scaling 32,000 limitation, but motor speed is still a serious issue. I keep hitting some sort of upper limit, where any further increase in the max or min speed value seems to make no difference.
Digging deeper I found the interrupt code for the motor ticks, and I’ve tried modifying the MOVEMENT_INTERRUPT_SPEED value down from 64 to 16 (as the DRV8825 can handle a theoretical lower step cycle of 4us).
Now I expect the ticks to increase more rapidly, but next I am stuck at the setTicks() function in StepperControlAxis. It uses the equation: stepOnTick = moveTicks + (1000.0 * 1000.0 / motorInterruptSpeed / axisSpeed / 2);. As the motorInterruptSpeed decreases, the stepOnTicks appears to increase, limiting the speed again.
What am I missing? How can I drive this farmbot faster without reverting back to full step mode?
It’s been a while since I looked at the Arduino code, but as you’ve found out there are some limitations with the way the steps are being generated. I’d suggest changing the method to a DDS algorithm which is much more efficient, but in the end you’re really up against the limitation of an 8 bit micro running at 16MHz.
Yeah I was worried about the arduino not being up to the task from the beginning, which is why I opted to build independent encoder micros to reduce the load on the master. I guess I was expecting the firmware to look more like that of the 3D printer scene, and thought to myself “I can work with this”. Oh well.
I know we are hitting the limits of 8 bit, but I was sure it could handle a slightly faster step tick rate than what we’ve got right now.
You’ve moved away from the arduino completely for your build haven’t you? What did you use for your set up?
I used a STM32f334 micro, using the onboard timer support for the encoder; one per motor (with an upgraded stepper driver chip). Each motor has one of the boards next to it, so the motor/encoder cables are very short, and
I then linked the boards together using RS485 to reduce the cabling, so I just distribute power and a twisted pair for the RS485.
I design electronic motor controls for a living, so I’ve spent plenty of time developing algorithms for stepper motors; hence I can suggest using DDS for the step waveform. This allows you to define a very simple and predictable interrupt routine, and do the actual frequency calculation at your leisure in the idle loop.
Oh that’s a pretty cool job, it gives credence to your helpful presence here on the forums too. I’ve read a bit about the STM32 chips, but I was weary of the steep learning curve. I’m only a hobbyist after all. Plus I had to google DDS to know what you meant…
My setup isn’t too far from yours I guess, although I’m not controlling the motors directly (at least not yet). I’ve got independent encoders which are each looked after by their own arduino nano locally, but I’ve used CAN bus to link them with the original farmbot arduino mega.
I’ve worked a lot with RS485 networks for my job too, but I’ve found them to be unreliable at times. Not just because of the protocol itself, but sometimes because of the packet management code the engineers put in place (or don’t put in place). It’s easy to miss the fringe cases when developing code, and that’s mostly what I deal with on site.
So what do you think of the overall approach from farmbot on detecting home plus detecting slipping motors with the encoders and how they are currently implemented?
Detecting home by running into the frame is fine for a 3D printer (no mass to speak of), and also a 3D printer doesn’t need absolute accuracy. The FB has the UTM and tools so it needs absolute accuracy, so needs an accurate reference point. One of the first things I added to my FB was end stops
The encoders have been a problem until the latest version of Farmduino, because I don’t think FB initially understood the electrical properties, or the impact on the Arduino software. I’m sure in hindsight they would have skipped the Arduino and gone for something more suitable… but that’s what development is all about. I’m not sure about the merits of encoders, generally we use encoders with servo motors, the whole point of stepper motors is not needing positional feedback. IMO the stepper motors are marginally under powered and the driver is certainly incapable of driving the existing motors to full power.
The next version of the Farmduino will have Trinamic motor drivers, which can detect missed steps, so would presumeably make the encoders pretty much redundant. I’d like to see a bit more power in the motor drivers though, the motors are capable of something around 1.6A rms, so the driver needs to be up around 2.5A peak.
It’s very difficult to give a definitive response to that, different sensors have different trade-offs. The magnet/reed switch sensors that I’ve recommended in the past are on the CNC machine I use, which I can power off, re-home and carry on machining with (to me) absolute accuracy within 0.1mm. There are many variables to the accuracy, so all you can really do is try it yourself, but I’d expect at least 0.2mm repeatable absolute accuracy. At any rate, much much better accuracy than running into the frame and looking for missed pulses.
Yeah at first I thought the encoder homing trick was a good idea, but then when I tried to get it working the encoder values were jumping all over the place before it decided it was home. I’m going to put in some hall effect end stops myself to improve the homing sequence, I’ve just got to design some water proof bracket enclosures first. I’ve gotten very accurate and repeatable results from the same kind of sensor on my 3D printer.
