It’s great to hear you’re looking at accuracy Is the co-processor aimed at providing repeatable accuracy so we don’t have to re home after each movement? Also are you shipping with end stops for v1.4 kits?
Could you give us a short wrap up of the major pros and cons about the legacy Arduino / Raspi Version, Farmduino 1 and the upcoming upgrade of Farmduino? I mean you will not aim for a 0.01 mm accuracy improvement and invest that big amount of effort and time if there is not a big flaw…?!
Thanks Best Klim
The current board general comparison has already been addressed in Farmduino vs. RAMPS. What we’re working on with the next version of Farmduino will allow encoder readings at higher speeds. A comparison of encoder functionality: Arduino/RAMPS reads the encoders directly, which limits the speed at which position can be updated, and therefore also speed of motor movements. The current Farmduino version still has the same speed limitation, but uses chips to reduce the differential signal. The goal of the co-processor dedicated to monitoring the rotary encoders is to reduce the speed limitation by reading the encoders indirectly, allowing for position-based movements at higher speeds.
So up to which speed do you consider the current system with Arduino / Raspi to still work flawlessly?
What do you exactly mean with that?
How can your read decoders indirectly?
Thanks for all the answers, but I am still trying to get the main difference and the background of the currently seen issues with the legacy version (Arduino)…
@whitecaps we are not planning to ship endstops with the v1.4 kits, though people are welcome to add them to their device if they wish (the software and board pinout still support them). Instead, we will continue to use the encoders to detect the end points of each axis.
Something that we’re also looking at for the future is using Trinamic stepper drivers which can detect missed steps through the reading of back EMF current, in addition to a bunch of other awesome features. The new Prusa i3 MK3 3D printers incorporate these drivers onto their new controller board which has allowed them to eliminate the need for endstops on their device as well.
@Klimbim The co-processor would be dedicated to reading and reporting position feedback from the encoders, which it can do much faster (at a higher sampling rate, some discussion on sampling rate can be found here) than the Arduino itself. This means fewer missed encoder readings, which translates to increased accuracy. The goal is to get reliable, accurate encoder feedback at higher speeds to use for movements, instead of only using encoders for stall detection. Regarding differential signals, you are welcome to research how differential quadrature encoders work, but the basic idea is reducing signal noise.
Are there any improvements to cater for belt stretch, such as moving the X axis motors down off the top of the gantry?
I still think you’re missing a trick here, why can’t you decode the encoder in hardware, pretty much all modern micros support encoders directly with their timers. Also, why stick with an almost obsolete 8 bit micro when all of your code is 32 bit or floating point? If you moved to a 32 bit ARM you’d get >10x performance, hardware floating point, hardware encoder support, Ethernet/USB. You’d likely be able to do away with the RPi too if you wanted.
It didn’t take me very long to replicate your Gxx/Fxx protocol in an ARM chip which I temporarily used with my Modbus stepper drivers, although I’ve since moved away from your software and just drive the steppers directly from the RPi. But I’d be willing to help port the Arduino software onto an ARM if you were interested in going that route.
I totally understand the reason you used the Arduino, but going forward I really do think you should consider ditching it in favour of something more suitable for your needs (and more modern too), and doing it sooner rather than later when it gets even more difficult (due to legacy support and a larger code base).
Can someone offer this guy a job at FarmBot, please?
@ Gabriel once again, up to which speeds to you consider the current Arduino system to work flawlessly?
What is the difference between using the encoder at higher speeds than to detect stall? The system behind those two topics is the same, if the encoder detects a stall this must not be connected to the speed?! Of course at higher speeds the current system is lacking samples and therefore can create errors. But higher speed still needs to be defined, see above.
Sorry guys @roryaronson @Gabriel but please, please, please be honest with us and do not try to fool your current very active and motivated community. At the moment I am feeling to be fooled as I think you are trying to argue that the current Arduino system does not work only at higher speeds, but it does not work at lower speeds properly as well!
So you are referring to differential signals instead of single ended ones? Or is this something specific to encoders?
The main idea here is that, as you’ve said, the current system does not have an adequate sampling rate to use the encoders to calculate motor movements at reasonable speeds, which is why the encoders are currently only used to detect stalls. At speeds around 100 steps/sec, enough encoder feedback is read to use the response for positioning. All of this has previously been discussed in the sampling rate discussion linked to above.
We’re not trying to fool anyone, it’s just that I do not find language such as “flawlessly” to be helpful when discussing developing and describing new cutting-edge technologies.
There are different types of encoders that send either differential (A, A’, B, B’) or single-ended (A, B) signals.
I’ll just add some clarification on differential signals.
Some (probably most) encoders have differential signal outputs, for electrical reasons and has nothing whatsoever to do with software. Encoder signals likely have to be wired in parallel with the motor drive wires (as they do with Farmbot along the conduits). The motor drive wires are switching high currents, which induce small electrical signals onto all adjacent wires. The whole point of a differential signal is that this interfering signal is common to both of the signal pairs, and at the receiver the common interference is subtracted (literally), leaving just the desired signal. Whether the encoder output is single ended or differential is only an electrical property, and if differential then the signal should be received by a differential receiver.
Those people with V1.2 kits have hardware which simply does not support the differential encoders. The newer Farmduino correctly interfaces to the encoders, so V1.3 kits and above will have less problems with using the encoder positioning (although this doesn’t address the sampling rate problem).
There is one thing people with V1.2 kits can do to help the encoder signal problem, and that is to connect the screen of the encoder cable to 0V on the RAMPS board. It won’t fix the noise problems, but it might help.
Hopefully @roryaronson will include enough ‘store credit’ for those people with V1.2 kits to at least upgrade to a Farmduino.
Amen to that!
Thanks @Gabriel that was the number I was looking for. Please do not get me wrong, I do not want to offend or accuse you but I am a friend of clear and transparent communication. This is needed when developing such a community project which shall get successful!
If one reads your words about why you jumped to the Farmduino, he/she could understand that you get the last 2% of performance out of that thing. That is wrong and I just wanted you to point that out. With the current Arduino setup the bot can only travel veeeeeery slow which might be not sufficient for some of the farmbotters (for whatever reason…)
I wonder how a noisy signal could be detected in the software? Of course differential signals are less prone to pickup interferences / noise as single ended ones. But is there a way to detect in the software wether the signal line was disturbed? Otherwise this statement to me is not verified…?!
I wonder how a noisy signal could be detected in the software?
It can’t which is the whole problem. The reason differential signals are widely used is because they offer protection against interference. Noise on the encoder signals presents as missed or additional ‘counts’, effectively rendering the position useless. The software currently attempts to make some sanity checks and performs some noise filtering, but in the end there is simply no way for the software to know whether a count is genuine or in error. Much better to have the signal intact in the first place.
The sampling rate (speed) issue is separate, which hasn’t been addressed with the Farmduino. The sampling rate effects both the ability to read the encoders reliably, and also to generate the correct step frequency. There is no reason for the sampling rate to be an issue with modern microcontrollers, so it’s disappointing to see it unresolved in the Farmduino(other than just wanting to stay in the ‘Arduino’ family).
It would be really interesting to get a counter or something when the sanity check fails which could mean noisy signal. I am just searching for evidence which justifies the jump to differential signals - which of course if you can prevent it, do it…
Why was that not addressed with Farmduino? Maybe you don´t know but Gabriel does? It thought this was the major problem with the Arduino layout?! Sad to see as well…
This is exactly the solution we’re implementing in the next Farmduino:
The coprocessor will live alongside the Arduino MCU and communicate with it over SPI. It is an STM32 processor with timers, which, as you mentioned, should make the sampling rate a non-issue. In the future, it is possible we might eliminate the Arduino MCU and shove the whole firmware into the STM32 for simplicity and cost reasons. Though we’ll need to determine if it is worth doing that and sacrificing being in the Arduino family.
The first (current) Farmduino was primarily designed to have a better board layout and connectors that are more optimized for FarmBot rather than 3D printers. This makes setup of the v1.3 electronics much easier, which was a pain point for v1.2 people who had RAMPS. The first Farmduino didn’t significantly improve performance over RAMPS, only the ease of use.
The next Farmduino aims to increase performance through the features mentioned above.
As with the development of any project, we must tackle issues in stages. Even with the next Farmduino, and the ones after that, there will be things to improve. Each iteration will get better (more performant, more reliable, lower cost, smaller size, easier to work with, etc), but we can only improve so much with each version because we have to continue shipping products and releasing new designs frequently.
Thanks for the good response @roryaronson, great to see the future plans for Farmduino. As a user I have different requirements from a supplier/developer, so thanks also for putting things in perspective from your side!
It will also eliminate needs for encoders (and encoder cables, board connectors, less computational power needed, etc…). Trinamic looks like responsive and cooperative company in regards of opensource projects.
I am trying to decide to buy the existing v1.3 kit or wait for the v1.4. Is it known yet what improvements will make it into the 1.4 kit. Seeing that there is only 2/3 months till the 1.4 ships I feel that there should be a good estimation of what upgrades discussed in this thread will make it in the kit. Also is it going to be possible to easily upgraded the 1.3 once these parts are available?