LabVIEW
Warning 215501 when attempting to read some Shared Variables
I recently inherited a new project. The system uses the DSC module in LabVIEW 2020 SP1 for the data acquisition from a PXI system to read 10 banks of 24 thermocouples via NI MAX. This should be straightforward, right?
The issue surfaced when they added two more cards into the PXI chassis. The behavior resulted in a much slower response when initializing the Shared Variables, but the annoying behavior is the fact that some channels are not being read at all. The behavior shifts from one set of sequential channels to another set of sequential channels (image way below). The behavior in one instance (original behavior) is spread across two PXI cards.
I am able to reproduce the issue on my development PC using simulated PXI card by monitoring the values within the troublesome VI where the Warning 215501 appears. It only appears when the zero value is displayed (default, since it could not read the Shared Variable value). Here is what the Warning says:
Warning 215501 occurred at Read Variable in TemperatureCluster.lvclass:onReadVariables.vi->TemperatureCluster.lvclass:ReadVariables.vi:1040001->TemperatureDisplay.lvclass:TemperatureDisplay.RefreshValues.vi:1320004->TemperatureDisplay.lvclass:Process.vi:5310006->SMO.lvclass:LaunchProcess.vi:3770004->SMO.lvclass:LaunchProcess.vi.ACBRProxyCaller.728000E8
Possible reason(s):
Internal Software Warning occurred in MIG software. Please contact National Instruments Support.
The closest similar issue that I found was with: "Error -229771: Internal Software Error occurred in MIG software. Please contact National Instruments Support."
I examined the suggestions listed in this link, but none of them were useful.
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P7a7SAC
The issue affect 23 out of 240 thermocouple readings. The NI MAX version is the one that came with the LabvIEW 2020 SP1 installation. It is a fresh installation of LabVIEW 2020 SP1 with no other version of LabVIEW installed. There is no other potentially conflicting software installed, only LabVIEW 2020 SP1.
My development PC initializes a group of 24 Shared Variables in approx 3.6 seconds whereas it takes the client's PC approx. 30 seconds per group of 24.
Another unusual behavior is the fact that my development PC using simulated values from NI MAX populates the 240 measurements quite instantaneously; whereas on the client's PC which communicates with the PXI chassis, it can take several seconds per thermocouple reading, which is painfully slow.
To recap:
The software uses DSC
Measurements carried out by NI MAX
Using Shared Variables
Some thermocouple channels are not being read from the Shared Variable Engine and result in a warning.
Uses Citadel database
Below are screen captures showing the behavior with the zeros in the data fields. The two screen captures are the two scenarios that were witnessed so far. All remaining readings appear to function correctly.
Some executions result in this:
Other executions result in this:
Has anyone seen such behavior? If so, is there a solution?
The "bug" is not in the software itself, but it could be in the Shared Variables within the LV Project. Maybe...
Here is more info.
A small VI was created to read the values from the Shared Variables using two methods:
1) databinding an indicator to the SV (with datasocket and PSP)
2) using a datasocket read function
In NI MAX, it is possible to read all Shared Variables. But not in the code see snippet.
The SV which works in the code also worked in all above cases. The SVs that are not read in the code were not read in the small standalone application. The same warning shows up. All Shared Variables in the library were triple checked (once by the original author CLA, and by two LV Champs). They are all implemented exactly the same way and they are using unique identifiers.
Here is a screenshot. Variations produce similar results so it is not necessary to upload all screenshots.
The databinding for the indicator on the FP:
More information...
One of the Shared Variable that was not able to read the values was removed from the library and a new one was created to replace it. It was configured the exact same way as a functional Shared Variable. The library was deployed; however, the problem still persists. The SV library was successfully deployed manually.
Hi Ray,
I am sure you must have already tried or know what I am writing but I have had similar issue once. I do not remember the exact error codes but some of my shared variable would not work when application is initiated on a non development PC.
Below are the steps I implemented and it helped me resolve my issue:
1) Hosted all the shared variables on RT side.
2) Added a starting sequence to the application on PC side where I programmatically acquired IP address and Alias of the target and then used that IP to programmatically open shared variable connection.
(Initially had about 6 shared variables)
3) Stored network stream endpoint reference in a FGV. Used this reference to programmatically read the variables.
4) I did not allow my application to start until all connections were opened.
My shared variables stopped working when I turned them into bulky cluster bearers and when I worked with several different targets (same model number but different alias names).
Also, I did not have aliasing enabled in the properties. Did not fully understand that part.
Hope this helps in some way. 😬
