LabVIEW
Modbus TCP master (cRIO-9068) reading slave loops in parallel causing noncontinuable exception (0xc0000025)??
I've been developing an RT/FPGA application for a cRIO-9068 that needs to talk to 4 or 5 different Modbus devices. I've got a couple loops to read my Modbus RTU devices via the 9068's onboard RS232/485 ports, and then 3 more independent loops to read the Modbus TCP devices on the network. This particular development setup uses LabVIEW 2015 SP1 on a Win7 Professional SP1 laptop. I have accumulated a few different Modbus libraries over the years testing the pros and cons of each.
The other day, I was modifying and testing some of those Modbus TCP loops and encountered a noncontinuable exception (0xc0000025) that crashed LV. I restarted/recovered and was greeted with a slew of dependency errors:
I figured since this class name turned up in multiple libraries, I probably have a duplicate, older library of some sort. The dependencies were very time-consuming to resolve, so I ended up just deleting one of the libraries in the file system window. After a lot of attempts, I finally got back into my RT_Target VI that runs the application, which in my experience is pure luck. I don't remember changing any VIs/subVIs to use new references from different libraries, and honestly didn't check. Long story short, I don't really know what just happened and can't discern it between a simple dependency mixup versus a major shortcoming in my code.
At the time, I was working on the parallel loops that query the slave devices (TCP):
I may be overthinking it, but is there anything wrong with communicating with these devices like this? Both loops use the same libraries/functions in this case, but the Modbus VIs are of course non-reentrant nor store data on shift registers to my knowledge, so anything I pass in comes from my own loops/shift registers. Should I still be managing multiple TCP slave device connections within the same loop? I feel like the application took a dump and started all this when I began testing the data these functions are returning.
Right now I'm reevaluating the use of this library above anyway because it has a lot of locked VIs that I would like to modify MBAP headers for. One of my TCP slaves is a Modbus TCP/RTU gateway and I may need Unit ID to access/switch between its RTU devices if it doesn't systematically address them somehow in the MB range.
You obviously had installed two different versions of the NI Modbus Library, that installed into two separate paths. As they are basically the same library with some changes, the VIs are mostly having the same names. And somehow during your edits you started to reference VIs from the other library, possibly by selecting a VI from the "wrong" place. That starts to pull in the dependencies of that VI and since they are class based pretty much pulls in the whole class, clashing with the other class being already used.
While properly configured VIPM packages could prevent that from happening, by specifying that they are not compatible to an older version of that package, so that the user is forced to remove the old package first, NI was not entirely familiar with all the features of VIPM at the time they created this package and most likely overlooked that possibility or the need for using it when they changed the target location in the LabVIEW directory.
The conclusion is: Make sure you always only have one version installed of any particular library. And be aware that some libraries may choose to use a different library name rather arbitrarily, making it impossible for VIPM to detect that it should remove a previous installation before installing the new one, without the package specifying that it is incompatible with the earlier package installation.
