| Encapsulating listen sockets in Function Blocks [message #1801517] |
Mon, 21 January 2019 15:14  |
 Caspar Gries
Messages: 2
Registered: January 2019 |
Junior Member |
|
|
Hi there,
I'm implementing a very simple protocol which connects a FORTE instance to a server PC that controls a few sensors/actuators via its GPIO pins. The protocol itself defines a UDP command packet which is sent by FORTE to control the actuators, and a status broadcast message with the current sensor values, that is sent in regular intervals by the server.
I want to wrap the protocol details in FBs. This is very easy for commands, it's just a FB that accepts events, creates an UDP command packet from the related data and sends it out. The other direction is trickier, since I need to open an UDP port and wait for incoming messages from the server. The question is now, how should this be modelled in FORTE? I can think of the following approaches:
1. Open a listen socket and do a blocking read until data arrives --> probably not a good idea if there is only one execution thread, since FORTE will then effectively hang.
2. Do a non-blocking read. However, we then need a "poll" event input for the FB that needs to be triggerered constantly, otherwise we will never fetch arriving packets from the socket.
3. Spawn a dedicated thread that does a blocking read, generating an output event when new data arrives.
From these options, I would strongly opt for the third, since I think it's the cleanest. The question is, can this be implemented in the way I imagine? In particular, can FBs create events on their own, and is FORTE thread-safe so we can do it in a separate thread? Is there anything else I have to watch for? Maybe there is already some demo code that can serve as a template?
Best,
Caspar
|
|
|
| Re: Encapsulating listen sockets in Function Blocks [message #1801701 is a reply to message #1801517] |
Thu, 24 January 2019 20:56  |
|
Dear Caspar,
In general I would definitely opt for the non blocking non polling notification option. As you are working on IO I would prefer not to have new FBs but to reuse the existing IO FBs. We have done this quite successfully for different systems now.
Especially in your case where you have some dedicated functionality required this makes sense. Since 4diac 1.9.0 we are experimenting with a new IO concept in 4diac. We call it typically modular IO. In this concept we have dedicated FBs which are used to configure and manage the IO access (e.g., what IO modules in which order). In your case these would partly be in charge of setting up how the messages are going back and forth between 4diac FORTE and the IO system. And this FBS would then also be in charge of mapping symbolic names (i.e., the names used at the generic IO FBs in your application) to the dedicated IO ports. For these tasks 4diac FORTE already provides a rich set of helper classes. Especially most of the critical parts in thread handling and sending output events from other threads, which is not as easy, is done there. A good example can be found in the Wago module.
I'm not sure if this is the answer you expected but I hope it still helps.
Cheers,
Alois
|
|
|
|
Powered by
FUDForum. Page generated in 0.01684 seconds
Search
Help
Register
Login
Home
