More that one UDP Broadcast?

[toddho]

Can an engine have more than one UDP Broadcast module?  If so, then how do I edit the configuration?  All settings are grayed out.  I would like to do many Standard engines to one engine.  Is this best done with UDP Broadcast?  Additionally where is the documentation for the various modules (UDP Broadcast, CVT, Modbus etc.)

Thanks

Todd

[Burt_S]

Great questions Todd. Yes an Engine can have more than one UDP Broadcast module. The broadcast name is a bit misleading (and will hopefully be changed before long). Currently the UDP Modules require being paired together in a 1 to 1 fashion. If you have multiple UDP modules, you should be able to pair them using the 'Module Paring' tab. Below is a really quick example I created to demonstrate this.

This example takes a value from a CVT tag in the top engine and sends it to the middle engine over UDP. The middle engine then receives that value, does a polynomial scale on it, and then sends it to the bottom engine over UDP. The bottom engine then reads that value from UDP and puts it in a CVT tag. Obviously this is fairly contrived, but the example does run and shows 4 modules on one target, and 2 under one engine. It also only took me 5 minutes to put together. Private message me if you'd like me to send the source code.

One caveat is that the UDP module wasn't originally designed to send data to another engine on the same target. As a result the pairing won't allow this. There is a simple workaround though which I used to get this working. More information is documented here.

https://github.com/LabVIEW-DCAF/TECModule/issues/15

All of that said, it'd be good to learn more about your use case before recommending an approach to take. Why do you need a 1 to N architecture? Do you ever need more than one engine on a specific target? Do you need lossless transfer, retries, or other features on the communication channel? Does everything need to start at the same time?

We are making slow and steady progress on documentation. Our main priority is currently on finishing the documentation for the core framework instead of on the various plugins. The core framework touches a bigger audience, and functionality in the various plugins is more likely to change more quickly over time, causing us to revisit that documentation. Unfortunately the best way to learn about the functionality in these modules for now is to experiment with the plugin in the editor, to look at the open source code, to look at the issues in Github, and to ask any questions that you have on these forums. We know this is a gap, and are happy to answer questions in the meantime.