I have hat a lot of trouble getting the FarmBot to move with its small Nema17 steppers. The encoders are essential for a reliable operation because the motors are loosing steps from time to time and these stalls need to be detected.
Why does the FarmBot use very small Nema17 steppers? CNC mills usually use Nema23 motors which are not really pricey. The TMC2209 in the Farmduino 1.5 are already sufficient to drive these bigger motors. A nice Alternative are the MKS Servo57A which include a driver and encoder in the board on their back. These motors would be much stronger and could easily run over small mechanical blocks like leaves growing over the tracks.
I am interested in the design considerations which lead to the small steppers.
FarmBot was very much born out of the open-source 3D printer movement. In the early days, a lot of the prototypes I built were inspired by some printer designs and thus made use of their widely available components and their familiarity to makers/hackers, and general interoperability. For example, our original electronics were an Arduino MEGA and a RAMPS shield. So that’s really where the NEMA 17 choice came from - it was and still is the defacto standard for machines of that class.
Fast forward 7 years and the availability and selection of hobby level control electronics for these types of machines has greatly improved and come down in cost. Bumping up to NEMA 23s is definitely possible, and something I’ve considered. Perhaps in a Genesis v2.0 you will see something
That’s interesting. I considered designing parts to enable me to test Nema23 motors on the X axis.
The thing is: If I start developing in a direction where the official FarmBot will never go to I would have to solve all the problems on my own. I have no interest in forking the project. However I would not mind to be the first one with an early prototype.
I think one of the fundamental mechanical design challenges of the FarmBot is the high and heavy portal which can swing a little during acceleration and deceleration of the X-axis. This swinging introduces a lot of friction and it is a challenge for the whole system to handle the forces involved. The mass of the portal could be much lower if the X-motors and the electronics would be stationary. This would increase the length of a lot of cables but the X-motors could be really heavy.
In a similar fashion could the Y-motor be attached to the portal and the Z-motor to the Y-carriage.
Were there reasons against such a design apart from cable and belt lengths?
I also have some Ideas for a Z-axis driven by two moving Y-carriages. The principle would be somewhat similar to delta printers. If you are interested I could make some drawings.
Some of the ideas you presented have been considered in the past. If you look back at some very early prototypes you can see the X1 and X2 motors mounted stationary on the tracks. Another idea is to mount the X1 and X2 motors at the bottom of the gantry (for example, on the gantry wheel plates) to lower the center of mass. I believe a user here on the forum did that a few years ago, but I cannot find their post.
I’ve also considered a raised track design where the gantry is a simple beam spanning the tracks. This design would probably be great inside of a rigid greenhouse with walls that can be used as supporting infrastructure, but not as ideal in my opinion for a standard raised bed.
The delta design is interesting and definitely do-able, but would probably have it’s own set of drawbacks, for example, the ability to position the end effector in the top left and top right corners of the gantry span. On a related note, we’ve thought about and talked with folks developing bots that hang from three cables and can move like the cameras in sports stadiums. All of these are interesting and potentially viable alternatives to our gantry design, but would take significant development effort.
At the moment, most of our hardware efforts are focused on improving part reliability and quality, and incrementally adding features and optimizations, rather than doing major overhauls.
Focusing on reliability is understandable. My ideas were not meant as hidden critique. I was just considering different designs in my head and was interested what you already tried.
Why did you move the X-motors to the portal? What problems occured?
So I hope you don’t mind another question: Have you considered using a standard CNC firmware like GRBL or Marlin? Path planning is much more sophisticated with these firmwares and they could be extended to drive the additional switches of a FarmBot.
I think the F commands would be a problem because F is already used by standard G-code for adjusting the feedrate. But a bunch of M commands could be used instead because these change from machine to machine anyways.
Yes! And it’s always fun talking shop with someone so familiar with hobby level CNC equipment
Let’s see if I can remember back that far… That early design had the x-axis belt connected to one side of the gantry, then the belt was run on top of the tracks, around the GT2 pulley on the motor, through the extrusions, around an idler pulley at the other end of the tracks, and then back along the top of the tracks to connect to the other end of the gantry. The main problem was feeding the belt through the extrusions. It was very difficult to feed through even a single 1.5m extrusion, and it would be near impossible to feed through multiple extrusions already assembled end-to-end.
The design of course could be modified to not have the belt run through the extrusion. For example it could be run underneath the tracks. But then it would probably sag onto the raised bed or dirt unless it was supported some other way. Different extrusions with a larger internal cavity could be used to make feeding easier, but no matter what you’re gonna have a really hard time feeding 6m of belt for a Genesis XL bot.
Another consideration was safety. I didn’t want large lengths of belt exposed and moving whenever the gantry was moving. It could easily catch on vegetation, clothing, fingers, etc if exposed.
Shortly after that early prototype, I helped assemble a CNC router that had a metal chain fixed at both ends and snaked around the drive gear on the gantry. I thought that system was so much better for the longer length of the axis than a full loop of belt/chain that is more common on small machines like 3D printers and laser cutters. So that’s when I changed and I kind of never looked back
We did in the early days. However, there was licensing conflicts with GRBL, although I think that project has since changed to a compatible more permissive license. And Marlin at the time did not support Rotary Encoders, and after toying with Marlin for a bit, it was determined by our firmware developer it would be easier to build something more or less from scratch than to try to integrate encoder tracking into a fork of Marlin. If we were starting over today, we would possibly (probably?) use one of those firmwares.
For what it’s worth, I would definitely look at upgrading from 1.5 if I could use NEMA 23s. Hopefully, there will be an upgrade path from 1.5 (or 1.6) to 2.0? Cheers!
I looked into MKS Servo57B. They look very promising because they are cheap and drive their motor with up to 3.2A. However the encoder works differently to the ones in the FarmBot because it sends absolute angles over a serial connection instead of pulses which needs to be counted. Is there a way to bypass the STM32 which counts the encoder pulses and send the absolute encoder value into the Farmduino?
Do you only want to replace the X-axis motors, or also those of the Y-axis? The serial interface of each servo must then be evaluated (and the wires must be connected somewhere), which the existing STM32 could take over. (After adjustments in the hardware and software.)
I wanted to start with the X-axis motors because they are the most problematic with my bot. If the X-axis runs without stalls with the bigger motors I might consider to also change the Y axis motor. But I would certainly prefer to start with one axis.
The Servo57B send their absolute encoder positions via USB if a connected terminal sends the right characters. That’s not ideal as the character based serial communication is a bit laggy. But it might be sufficient for a working stall detection and the servo motors are nearly perfect for the FarmBot in all other aspects - especially the price.
The STM32 would not really be needed in a setup with integrated servo motors. However it might be useful to act as a relay to the Farmduino.
That early design had the x-axis belt connected to one side of the gantry, then the belt was run on top of the tracks, around the GT2 pulley on the motor, through the extrusions, around an idler pulley at the other end of the tracks, and then back along the top of the tracks to connect to the other end of the gantry. The main problem was feeding the belt through the extrusions. It was very difficult to feed through even a single 1.5m extrusion, and it would be near impossible to feed through multiple extrusions already assembled end-to-end.