Long running farmware


#1

Hi,

basically I want to control the FB with my own software. I will be well away from the internet and power and want to having to provide a web app and message broker host (other than perhaps for boot strapping) is cumbersome and adds little value (for my use case). The design I was thinking of was to have a long running farmware listening on the network for commands from another controller. Is that reasonable? Does each farmware run in its own thread or will this potentially block other things from running? Can I get a farmware to start when the OS boots?

Thanks,
Evan.


#2

You might want to review the documentation here:


In particular, the section titled “Farmware Trade-offs”.
One of the bullet items is: “FarmBot halts all other operations while a Farmware is running, which can lead to slowdowns in some cases”


#3

In addition, for this use case:

The message broker will facilitate this type of communication. For examples of using Python to communicate directly with FarmBot, see Python message broker examples.


#4

As I mentioned, I’m trying to avoid having to host the entire web app stack near the FB (there won’t be much power available). Can I just host a broker? How do I get the FB to connect to a custom broker? Will the web app stack run on an ARM system?


#5

Thanks that’s the answer - it’s a non-starter.


#6

Can I just host a broker?

I have never tested against this use case, but I doubt it would work as FBOS makes many assumptions about REST API availability. You would also need to write a stub server/script that creates JSON Web Token that points to your custom broker via the MQTT claim.

This would be more work than self-hosting a Web App instance within proximity of the device.

Will the web app stack run on an ARM system?

The Web App server does not run on ARM based systems. I have heard of some users purchasing small x86-based “fanless industrial PCs” for this purpose, however. A low-end Celeron box or a used desktop inside of a weather-proof enclosure might also work. A web search turns up quite a few options, but it’s important to make sure it has more than 2GB of RAM (4GB is ideal).


#7

Thanks Rick - very helpful. We may ultimately end up forking FB OS for our use case.


#8

Happy to help @evanthomas. If you are willing to write your own software for the use case and you are fine with writing Elixir, forking FBOS is a good way to go. Another option would be to start from scratch in the language of your choice with a custom GCode parser.

Although I don’t have the time resources to provide support for such an endeavour, the FBOS GCode Parser could serve as a good starting point. Some members of the forum have taken this route for special use cases like this.


#9

If I understand you correctly, you are suggesting skipping FBOS and talk to the farmduino directly. A colleague of mine suggested the same the same thing and I think that is the way to go for us.