Whoops- forgot to add this one to the reply above. From the Farmware documentation:
“FarmBot halts all other operations while a Farmware is running, which can lead to slowdowns in some cases”
A 30 second timeout was added to later versions of v8+, since we would occasionally receive bug reports due to Farmwares that did not exit cleanly. I am unsure if this would be the cause of the issue, but it is worth mentioning, especially for users that are finding this thread via forum search.
I will install the Farmware in question on my local device now. Thanks for all the details, folks!
I now see what happened after installing the farmware (SEE: previously mentioned “sleepy mistakes”). It looks like this one is simply a formatting issue rather than a system error. @whitecaps Please let me know if there are any issues that require further investigation.
It is. Please note this code was very simple test sample to try and get move_absolute working, it is working now so I don’t think you need to reproduce the problem. Yes sleepy mistake I have been burning the candle.
I started using it when it was first introduced, before the Grid functionality was added to the Web App. Back then there were better examples for Farmware on GitHub + doco than those for the REST API. So there is a historical reason, things have moved on since then re the REST API. However I do have low latency and run local requirements as some of my sequences run 1000+ movements. As I’m prototyping both hardware and software (I’m time poor) it’s an easy way to get from A - B as it’s just a script no host needed. It’s clear I need to invest more time in setting up a good IDE + debugging procedures!
@RickCarlino, @Ascend, @jsimmonds the Farmware issues still persist :(. I have created a better Farmware test to demonstrate them, keen to know if this is only happening on my machine?
The code tries to log 5 messages after the Hello Farmware message. It then tries to make 5 simple x & y movements.
On my Farmbot I only get 3 messages logged (big pauses between each message) before the Farmware stops i.e.
Hello Farmware
Message 1 Test
Message 2 Test
I also removed all the log writes, to test if just the 5 move_absolutes work. Only 3 moves work.
So it seems like Farmware on my Farmbot is prevented from running more than 3 commands.
I have ordered the TTL-232R-RPi Debug Cable and will start to debug this once it arrives
BTW I also noticed that the manifest entry “farmware_tools_version_requirement”: “>= 3.3.0”, prevents the manifest from being installed.
I’ve got the exact same output, stopping at “Message 2 Test”. Each command takes almost 10 seconds to execute, so its most likely the 30s timeout that makes the farmware stop. It generally feels like the farmwares are executed much slower than in the past.
@whitecaps@Ascend@RickCarlino this new Farmware behavior was introduced by @connor on Dec-14 2019 . . allows any Farmware to run for only 30s max.
The code needs a re-work ( and a unit test ).
I would attempt a fix but without having seen any User Stories for the design in this area, it could be Xmas 2020
Kinda been stuck for 3 weeks now without being able to run farmware. Appreciate you guys are working flat out however! I will take a look at the code and suggest some changes.
You seem happy to get your “coding hands dirty” . . until this 30s silliness is sorted, can you simply split your Farmwares into shorter “sonnets” ? . . or
Use “live” RPC programs ? ( Sequences, etc. ) . . instead of Farmware ?
I can’t unfortunately they make a lot of movements over a long period of time. But I guess I’m going to have to try and move off Farmware so I can keep growing. I will take a look at the other methods this week.
Thanks for your patience @whitecaps and sorry for the delays on this one. As some of you may have heard, we are moving a bit slower than usual after Connor transitioned out of his role at FarmBot. He left on good terms and we wish him the best of luck at his next role. It does reduce the size of our dev team by a third, which translates to slower-than-usual responses on bug reports, so I apologize for the inconvenience this causes. We are also gearing up for the incoming wave of new Express users that will be bringing their bots online in a few weeks, so no updates on the Farmware situation quite yet.
In the interim, the best solution I can offer is to attempt to move the Farmware off of the device and on to a dedicated machine with a reliable internet connection and perform relevant device actions via RPC. This will introduce some network latency, but could offer a long term solution for many use cases and removes all of the restrictions associated with Farmwares.
@whitecaps@Ascend and @RickCarlino, I hope to have a solution for the “slow” Farmware step execution issue ( that 10s pause ) ready tomorrow . . it seems to be a “chicken-egg” situation between the Farmware plugin supporting Python code ( farmware_tools ) and FBOS.
While on the Farmware subject, . . is 3rd-party Farmware useful anymore ? How does one call non-RPC functions from Python, e.g. ?
Thanks @jsimmonds and @RickCarlino if you want me to test or help let me know. I have managed to modify my original python code to run in under 30sec. I just run it one time per move from a recursive sequence and effect a loop that way.
Good question on whether Farmware is useful. I believe it is because other RPC solutions must be hosted and are higher latency. Farmware was (until it was limited by the FBOS v8 update) the easiest way to program and control complicated movements and periferals. These are still impossible to effect in the farm designer, regimens, events and sequences as looping and grid functionality are limited and restrictive.
I am now self hosting the FB Web App and in a month or two will set up a dev environment and start to create some new sequence blocks etc to improve the looping and grid functionality etc but until then I need to rely on Farmware.
I think in the future you could move away from Farmware but it’s not a good idea to remove it without providing an easy to use viable alternative that allows for (near) unlimited control over the Farmbot. It is also important to warn folks of any changes to Farmware ahead of time.
I’m going a bit off topic at this point but I think the following is important. The changes to Farmware cost me a fair amount of time. Also I understand it’s been a hectic start to the year for you guys, but please consider the below in your future planning.
Farmbot is starting to progress towards bigger Farmbots for small commercial farms which is awesome. However as commercial farms begin to use Farmbot IMO there may need to be more of an emphasis put on software stability rather than innovation. If you are running a business and you loose your crop because of a software update that’s a big deal, money and time down the drain.
As always really enjoy Farmbot and appreciate all your massively hard work!!!
I am glad that you were able to get your code running again and thanks for your patience during this transitional period (and special thanks to @jsimmonds for investigating the matter). Our big focus for this quarter (and 2020) continues to be stability, starting with increasing the amount of unit test coverage for FarmBot OS, which has historically been lower than other parts of the application. We are putting a pause on major feature development to give us more time to increase test coverage and investigation of bugs, such as the one mentioned in this thread. There will still be a few new features expected during the first half of the year, but nearly all of our resources will be spent on testing, bug fixes and documentation.
Thanks again for your understanding. Your concerns are valid and reasonable. I am personally committed to fixing them moving forward I will keep you and the rest of the community updated on our progress.
More intricate than I assumed . . the StepRunner or a subordinate task seems to be changing the originating RPC label value ( the UUID for the Request ) when it returns the rpc_ok
That’s why the farmware_tools can’t locate timely responses ! Will dig deeper . . .
I have tested my Farmware on FBOS 9.1.0 it works fine and runs a bit faster. Thank you both for helping me out!!! I am growing again :). @RickCarlino I can live with the 30sec timeout.
I’m glad that you are operational again @whitecaps.
For anyone that does have a problem with the 30 second timeout and is finding this thread via search, I’ve created an example library of how to solve the problem with an off-device software package.
all good!
For IDEs, my current favorite is VSCode. It has pretty good Python support and works great on most platforms.
