Today we released FarmBot OS v14.0.0 - a major stability upgrade for the FarmBot platform as well as several updates to the web app. Here’s what’s new:
New firmware handler
FBOS v14 contains a complete overhaul of the firmware handler, improving the reliability of the communication between the Arduino and the Raspberry Pi, the handling of edge cases, and the overall maintainability of the code. Many rare and hard-to-recreate bugs have been fixed with this overhaul, and we want to thank @jsimmonds and others who have helped us test this major new release.
New firmware
FBOS v14 includes new firmware for both the Express and Genesis platforms: v6.5.34:
The new firmware fixes several outstanding issues that were holding back the Genesis version at 6.5.11, so now both platforms are at version parity.
FIND AXIS LENGTH has been improved so that the FarmBot will now verify the max and home positions with a user-defined number of retries, allowing the bot to overcome false max and home positions. Two new sets of parameters, CALIBRATION RETRIES and CALIBRATION RETRY RESET DISTANCE (MM) are used to fine tune the performance of this functionality.
Fixed a bug where the firmware would not respect SPEED values when moving in the negative direction.
Note: Some FarmBots, after the upgrade to v14, may show a Code 30 connectivity condition. If so, simply press the flash firmware button to resolve the issue.
Improved firmware sync indicators
The web app now features an improved UI to indicate when firmware settings are syncing with from the web app all the way down to the firmware.
Miscellaneous
Verbose firmware send and receive logs have been removed from the stack, though they are still available to developers over SSH.
Developers and users with special hardware add-ons can now change the firmware’s path from the frontend.
Added setup wizard steps to facilitate users installing their bots with an ethernet connection.
Added support for UART communication with external hardware from within Lua sequences (documentation comings soon). Thanks @pinae for the inspiration and assistance - we look forward to seeing what you and others do with this new feature!
Added support for custom.hex firmwares (documentation coming soon).
Laid the groundwork for StealthChop mode for the Trinamic TMC2130 stepper drivers included with Genesis v1.5 and Express v1.0 kits. Stay tuned!
Hi @roryaronson,
can you tell me exactly when you pushed this update to the servers? My bot was unresponsive from 23th of may at around 6 pm central europe time.
I needed to flash the bot again to get it back online into the webapp. I saw that it was online in my network but not connecting to the webapp before. I only did a restart so far.
Moreover I noticed, that when I woke up my bot from the winter deep sleep, I needed to manually flash from OS V12. This was not a problem but it didn’t take over the webapp / database values smoothly. I had to manually click into every field in the settings and I think thus it only stored it properly in the database. I did this because I was really disappointed after searching for the errors why the bot did not move properly. On the x-axis for instance one motor was moving in one direction and the other one in the other direction although the values displayed in the webapp were as they should have been. Depending on the devices that still run V12 you might want to look into this transition error as well.
Thanks for letting us know about your experience upgrading from v12. We’ve been monitoring the upgrades and seen a few weird cases, but overall 95%+ of users seem to have had no issues.
@roryaronson Hi Rory, Thanks for all the regular updates. It’s really appreciated.
I have just upgraded to v14 on my Genesis 1.5 XL and am now unable to “Find Home” anymore. Find Home Z works fine but Find Home X and Find Home Y result in the bot entering into an endless loop of reaching the end of the rail, going back a few mm and trying again.
I may have done something dumb but I don’t think so. Could you please help?
Hi, i upgraded to v14 and am having the same issue with x axis, have tried go home and set home, which work fine when done manually, its always in any sequence that the find home goes into a continued loop to get to X axis 0. Worked fine before the update. Appreciate any other ideas.
@Jack I took a look at your device and the X axis stalls appear to be regular old motor stalls (eg: I do not see any runtime errors or unexpected behavior).
To account for this, I’ve raised your X motor current to 960 and it appears to be working again. Please email contact@farmbot.io if you need more help with motor calibration or if you have other information that would lead us to believe this is a bug in the software.
For reference, I keep the X motor on my XL at 1,100.
@ClosedCircuit I forgot to mention in the announcement that the homing functions have been changed such that it should exit the homing procedure after the first home position verification (back up 10mm and then forward to re-touch the home position) rather than always doing three verifications. If the bot does not detect the home position during verification within 2cm of where it thinks the home position should be, it will think that the first home position identified was erroneous and it will reset the verification counter. If your bot isn’t ever verifying the home position within 2cm, then it could go into a loop.
Are you using the stock hardstops? Do you have ALWAYS POWER MOTORS enabled? Have you tried adjusting motor and encoder settings slightly, such as MAX MISSED STEPS, and/or MOTOR CURRENT which seems to have solved Jack’s issue.
Rick, hi, am still seeing the same issue, if you run the unmount tool (or any sequence where the first command is - ensure accuracy) the farmbot goes into a continuous loop trying to find X home, it doesnt do this for manual find home and i have resent home manually etc. FYI this issue only arose after v14 was installed last week it worked like a charm thanks for looking into this Jack
Thanks for letting us know @Jack. It seems that there are still some issues to be worked out and it will take me some time to find a root cause, but we definitely need to get this worked out.
First possible fix: Temporarily disable HOME ON BOOT. If you do not have it enabled, then toggle it from OFF => ON => OFF again. This is just a hunch (the firmware may be bootlooping and attempting to find home on boot).
If that does not help If your device is unusable or you are at risk of crop damage, you can temporarily turn off auto-update and then downgrade to 13.2.0 until we figure out what is going on:
Make sure you re-flash the firmware after downgrading! The v14 Farmduino firmware is not compatible with v13. When you downgrade, the Farmduino will still have the newer (incompatible) firmware installed. For this reason, I would recommend against downgrading if possible.
If you’re not in a hurry (and it’s OK if you are!) I can take one more look right now assuming the device is online.
hi, i just tried running the unmount water tool sequence and still the same issue, it tries to continually find x home in a loop. I will play around with the other parameters and let you know if works
@roryaronson Thanks for having taken the time to reply. I am also very grateful to @RickCarlino for the outstanding support he provides.
A new issue created by exiting after the first home position verification arises when the two 2 sides on the X rails become slightly misaligned. This happens quite often on long sequences (at least on my bot). As a result, there can be a 5 or even 10cm difference between the left and the right side when the bot comes back to 0, 0, 0 at the end of a long sequence.
Before V14, the 3 verifications were enough to realign the two sides but 1 is not enough and one side is now left several centimeters away from the hardstop.
A quick fix is to run FIND HOME X several times but it’s not elegant. It would be really useful if we could please reinstate the 3 verifications (at least for X) or give users the choice of how many verifications should take place. Alternatively (and perhaps even better), am I right in thinking that the test is for only one of the two motors to stall? If so, could the verifictions keep on going until both left and right motors stall instead of just one?
Hi, This version works great. Especially the find home process .
But I have a problem, as far as I know the E-STOP light is connected to the GPIO BCM pin 17 on the Raspberry Pi.
When I upgraded to version 14.0.0 I noticed that the connection status LED on GPIO 17 is no longer on and does not blinking when the unlock button is pressed, is this the expected behavior? Or is it replaced with another GPIO pin?
@JoeHou v14 is a complete rewrite of the firmware handler code in FBOS. It is possible that the code was not transferred to v14. I will take a look. Thanks for letting us know.