What is now in version 1.4 compared to v1.3.
I can’t seem to find any docs .
What is now in version 1.4 compared to v1.3.
I can’t seem to find any docs .
We haven’t yet posted documentation for v1.4 - that will not be available until the products begin shipping to customers in May.
Generally speaking, v1.4 will be a more minor improvement to the design because we’re focusing most of our resources on the changes needed for the XL device, software development, and ramping up our supply chain and warehouse capabilities. Something we are hoping to include in v1.4 is the next iteration of Farmduino as well as a revision to our custom electronics box.
Does that mean that any orders placed from today for a farmbot genesis (regular size) will be delivered in May as part of the 1.4 batch?
Any indication on what we may look forward to in farmduino v1.4? and the custom electronics box.
I’m keen to know the technical details before placing an order
Correct, orders placed today for v1.4 (standard or XL size) will ship in May. We do have some v1.3 kits remaining that you can purchase and we’ll ship within 2 weeks, in case you want a device sooner.
What we’re working on with Farmduino is adding a coprocessor dedicated to monitoring the rotary encoders, which should allow more reliable movements at higher speeds. We’re also switching to 24v, which will require sourcing and testing 24v versions of the vacuum pump, solenoid valve, LED strip, and PSU. This is a long term work-in-progress though. Once we nail down the Farmduino design, we’ll need to get regulatory certifications for the new board, which may take a while, and we may need to go back to the drawing board in case we fail some of the certification tests at first (it is common to fail some tests and need to tweak the design multiple times to get everything to pass). In the name of not delaying the entire v1.4 shipment (like with v1.3) and missing the Spring growing season, the new Farmduino design and electronics might not make it into the v1.4 kits, which is why I said it is hopefully something we will include, but we really will not know for a few months.
For the electronics box revision, we’re looking at adding a through-panel on/off switch as well as an e-stop button, and changing the size slightly to best fit the new electronics. This is also a work-in-progress though and highly dependent on when the final certified Farmduino design is completed. Making the molds for the electronics box will take about 6 to 8 weeks, and so it is possible this might not make it in to v1.4 either.
We’re of course doing our best to add as many improvements as we can with each version, while making sure that we continue to ship in a timely manner. The main improvement you’re seeing with v1.4 is that it is available in the XL size. Any other improvements are going to be minor, with the exception of maybe the electronics stuff discussed above.
When evaluating the products to place an order, you can assume that the next generation kits will be better than the last/current generation. However, because of the nature and difficulty of hardware (and software) development, as well as the need to meet shipping timelines, it is pretty much impossible to predict exactly what will be better in the new kits. This is why we do not publish the documentation until the product ships, because things are subject to change.
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…