I ‘m looking into how to structure a library in RF, that communicates with a daemon, that runs as a separate process… I’m looking for examples, hints, stuff, that already exists (and my search has not found anything useful..)
Idea / Problem:
I have a devcice, that has a CAN bus interface….
And it needs constant communication (like a heartbeat and RPDOs to keep it operating nominally..)
Idea:
Have that run as a separate thread, and have an “interface” of some sort to interact with that daemon…
Important to note:
The daemon must operate continuously, without any specific commands from RF, different than the Remote Library (as far as I understand)…. but I am looking for something like the Remote Library, where there was already a well-established approach for that specific “problem”….
Is the “daemon“ existing or something you can write yourself?
If you can write it, perhaps have it open a simple http server and listen on a known port number, and react to rest commands, then you can use requests library to communicate with it, nice and simple PUT to send commands with data to get it to do something GET to read values from the CAN bus.
I know there are others who’ve use RF with CAN bus for various things, I haven’t so am no expert on this, but a quick search for “Robot Framework CAN bus” finds [this](GitHub - Openwide-Ingenierie/robotframework-can-uds-library) that may help?
If the issue is partly “constant communication (like a heartbeat and RPDOs to keep it operating nominally..” I’d write a separate test client which can (pun intended! ;)) communicate with the actual server and then expose what ever features the test itself needs .. Essentially this approach would eliminate the need for having threading with RF itself.
thanks for your response…
I think I need to write that daemon myself, but I will rely heavily on existing libraries (python-can, etc)…
The focus here was more the interface to RF and HTTP server with GET und PUT etc. seems good..
I was merely looking for some kind of recommended architecture for this type of situation (begin CAN or not…)
I need to look more into the UDS library, but so far it seems promising…
I was so far under the impression, that UDS is mainly a request / replay-scheme, where there is really no daemion involved.. A quick look at it so far seems to indicate otherwise…
I don’t see why you can’t interface to remote library spec. The spec is just how RF would talk to a remote library. What the remote library does under the hood is entirely up to you. The remote library interface part of it simply needs to follow the protocol and upon receiving the keywords to run, invokes whatever the underlying logic is to be done for the given keyword data. That underlying logic can be forwarding the request to the daemon in whatever other interface you want to use.
And with the remote library interface, you have choice of whatever (RF supported) language platform that is suitable, there are existing remote library servers that offer the interface for you, so you just have to define the library of keywords to handle. You’re not restricted to python or jython/IronPython.
I thought you had the daemon part already and your part would be integration to it. As mentioned in previous reply, using rf’s remote library ain’t a bad choice per se but I would also consider a just a basic http server and then use request library to interface with it from RF if you need to transfer anything in binary from/ to the daemon side - just for convenience.
depending on your can usage, if by happenstance you already have access to EcuTest, it does provide Python bindings and validations via Simulator might be good approach in some cases.. I have some example RF code in my github based on dude called Ran’s code (you can see where it was forked)
I’d go with read and reply as pure and realtime communications with RF could be hard to implement. Most likely not impossible thought. That’s why my original suggestion was to have separate test client where the client acts as a sort of message broker between daemon and RF but providing setup, verification and teardown to RF side.
But that said, at least from my pov, I’d need to know what kind of messaging is happening before diving in into implementation details..
@daluu I think I need to look a little bit more into the Remote Library example server implementation.. so far I was under the assumption that those are blokcing during “processing” a keyword… Might be worth trying to have that server share the data with the actual daemon process and, while the server processes requests in a “after-each-other” fashion, the daemon continues working…
@damies13 Thanks for pointing towards the UDS lib… the more I looked into it, the more I think I can “offload” a lot of CAN-specific work in a similar fashion in my daemon…
Not sure yet, if that library actually runs in a “daemon”-like fashion and processes all received CAN messages on its own, while I only interact with the processed signals, but that should be easy to figure out…
@rasjani I do not have access to ecu.test (I am guessing you are refering to this: tracetronic GmbH)…
What would be the benefit of having a gateway-like setup? Is that client, to which RF interfaces, which then in turn interfaces to the daemon, doing real-time communications? My idea was more along the lines of the daemon having:
a “processing” thread (which receives and processes the CAN messages)
a “sender” thread, which can send specific messages at specific intervals (maybe even incorporating data from the received frames / signal (some devices need this kind of loopback as part of a communication check)
an “interface” thread which provides the interface to RF and thereby access to the signals and some “housekeeping” for setting up sender messages, etc.
I tried to convey that realtime communication directly from RF is harder approach and testclient == your about to be written daemon. So we are talking about same thing.
As old unix beard, “daemon” to me is a process that forks itself to a background and closes its stdin/stdout/stderr file handles, thus i was talking about “testclient” instead of daemon but essentially, your approach looks what i’d do too - besides the process being a background process
EDIT: About blocking ..
Thats why i would offload all the actual interaction to the “daemon” or “testclient” in my words …
then you may need workaround that. Nothing in the spec defines how keywords should entirely be implemented. So you could define keywords that for operations that are long running and that do not return nearly immediately, can return some session or process identifier. The test can then issue a follow up keyword call (same keyword or different one) to get the response/output of the earlier keyword call based on the session/process ID. The back end daemon doing the processing can derive an ID on initial keyword call (A) and track that internally for followup keyword call (B) to get an update of the result at later time.
I’m not aware whether RF has any callback notification mechanisms for keywords or other parts of framework. That would be suitable for this.
I recall there is some listener interface for RF but unaware if that works with keywords or for other uses. Something you could look into as well.
