we are using cRIO-9057 with RT Linux in a network where devices use EPICS server to publish data. Details of EPICS server are not important to this question, except the initial step of communication when any program interested in data will send UDP broadcast with the variable name. In our current setup this results to cca 2500 UDP broadcasts per minute.
We discovered that our cRIO is not able to handle so many broadcasts. We verified that broadcasts arrive to network adapter, but many don't make it to LabVIEW UDP Read output. Testing of UDP Read with attached vi revealed that average time per read is cca 80 ms, so we get 750 reads per minute. The average time is almost the same regardless of vi priority or if it's run from LabVIEW or as rtexe. Do you have any idea why we can't retrieve the values from UDP Read faster?
There is also a second question: UDP Read performs even worse in actual EPICS server which is launched using Start By Asynchronous Call, it takes then several hundred ms to return data. Is there an explanation to this? Is it possible that vi launched asychronously would get low priority on cRIO?
So, after more testing we discovered that UDP read and EPICS server works just fine on cRIO if placed directly onto block diagram. However when called by Start By Asynchronous Call or by Run Method performance decreases - UDP reads only 2 or 3 messages per second and CPU load rises to 50%. We deduced that one core is fully occupied.
Do you have any experience with this behavior? Can some settings on cRIO be adjusted to avoid it? Or is it just bad optimization on NI side?
do you really need to open and close the UDP port each time (as in your example VI)? This will also need its time!
Do you really need to call VIs asynchronously as written in your message? This also needs time!
(Additionally it will hurt the "Realtime" behaviour of your realtime target…)
thanks for the reply.
The example VI was intended for a single run, so the port is opened only at the start and closed at the end - I don't see how it would be opened and closed each time.
The asynchronous call also happens only once, when the application starts. Then the UDP read loop keeps running until the whole application is stopped. So to be more precise, the Start By Asynchronous Call VI does not seem to have performance problems, but the code that is called asychronously does - and only if called asynchronously.
Whether we need the asynchronous call is a different topic - I would be glad to get rid of it, but it means reworking a big library provided by external supplier.