@Tanchris wrote:
But how can I fire events by TCP or how can I replace my events with TCP/VI-Server/...mh.
With MQTT or any other way to communicate between applications, or between separate execution spaces in the same application, the general process would be the same.
I'm going to assume you're using user events for everything here. If you're using either the built-in events like value changes on button presses, or events that fire callback VIs such as .NET events, then you must convert those to user events.
The user event in LabVIEW essentially has 3 subcomponents in it that you would need to ensure get copied over TCP.
1. The reference (data type + pointer to a memory address where events can be sent).
2. The registrations
3. The data sent with each event
For the reference, you'd need to essentially replace that with a predefined header of some kind instead of passing around an event wire or having a global VI where you store it. In MQTT this would probably be either an "Events" topic in general (with a header on the data afterwards to designate which event), or a specific topic per event. For any other TCP communications, whatever you set up to receive data would need to look at the header and redirect it to local code that processes incoming event data. In both cases, you'd need to predefine the event data on both ends, probably by having a type definition in a shared library that both applications have to sync up on and use.
For the registrations, with MQTT that would be setting up subscriptions to any Event channel. For both MQTT and any other custom TCP solution, that could be handled via internal registrations of user events that are broadcast whenever a data packet comes in to the subscription. It could also directly just call one VI if the application only has one place for event registration to be sent to.
For the data itself, there's two things to worry about.
One is the fact that events may not be handled immediately, so whatever you do for the registrations you need to make sure that the data is saved until it's ready to be pulled by whatever registrations you implemented. If you use local user event registrations per separate application, it's already handled. If not, I would recommend a queue or similar lossless FIFO architecture to be sure every event plus its data gets delivered.
The second thing is how to encode the data.
The easiest way is to just use "Flatten to string" before sending over TCP, and "Unflatten from string" on the other end. This does require absolute synchronization of your data type, though. You have to be very careful to be sure that every sender and every receiver understand everything you flatten the same way, so never getting out of sync on type definitions or library versions. If you try the unthinkable and send class data, good luck keeping that synced up if you use any sort of inheritance hierarchy. Flattening to a string also allows you very little debugging just by examining the messages. It can be fast, though (both to set up in code and the execution time of the flatten/unflatten methods).
An alternate way would be to encode everything in readable ASCII somehow, such as JSON or XML. This makes it a lot easier to have versioning mismatches not result in instant failure, and also a lot easier to add debugging if you snoop on the message traffic. However, you will have to create your own methods for packing and unpacking those ASCII structures, and the execution time for large messages can get prohibitively large if you need to pass around million-element numeric arrays or things like that.
