We have a cRIO fully loaded and had to branch out to an expansion module. The documentation says that the only way to access the expansion chassis is to use the EtherCat stack built into LabVIEW (which is then built into an ELF executable on the cRIO's filesystem as lvrt). Our business logic is run through a Linux application. To access the data from the expansion chassis, we have set up lvrt to provide a shared memory interface. When we were using 18.5, this seemed to be working. Through a series of discussions with NI, we were advised to update to 21.5, which we have done. There were hurdles with the lvrt application to get it even working with 21.5. At the moment, we seem to be having a sequencing issue with the reads and writes to the EtherCat module. It appears that the way we have designed the lvrt application is to trigger the write event based upon updates provided to the shared memory. The code (which I did not write) seems to be waiting on an epoll (select) for any updates to the shared memory which triggers a write to the output modules. The reads from the input devices in the chassis seems to be running in parallel with the writer function. It also seems like the read and write cannot occur at the same time, but it appears that we are doing that.
With a shared memory interface, there is no way to synchronize events between the two applications. Is there a better way than using the shm interface? Can I build the lvrt as a SO in place of an application and call directly into the SO the functions to read and write the modules?
If that is not possible, is there a locking mechanism in LabVIEW to allow me to control access to EtherCat?
Thanks in advance for any advice you can provide.
Andy
