LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange Phenomenon using Case structure with Shared Variables

Background

2017sp1 LabVIEW 32bit,DSC, Windows 10

LabVIEW VI (Master)

2 Acromag ES2153 I/O units (Slave)

16 sensors.

 

Good Morning NI Forum Boards, 

 

 I am writing a VI which acts as the Master and queries information from two slave devices (Acromag ES2153 I/O unit) over modbus TCP in the field.

 

The VI is pretty straightforward it reads 8 holding register values for two slave devices using shared variable library and displays the values on an indicator on the front panel. Strangely, channels 2 thru 8 (Anode 2 to Anode 8 seen on front panel) work perfectly fine. However channel one(Anode 1)  displays 0 during execution as oppose to other channels which update with various values. This is the same for the second slave device (Cathode 1) as well. It seems that the 8 case structure I have for 8 registers skips over the first case sequence. Oddly, when the program is executed and running I notice that if I hoover over dialog header and left click and hold........... I see that the value for channel 1 display and fluctuate intermittently. 

0 Kudos
Message 1 of 3
(2,386 Views)

You have cases for 8 iterations of the for loops, but the array has 16 elements. So iterations 8-15 are using case 0 (the default) case. I'm guessing there is no data, or the wrong data being used.

 

Annotation 2019-12-06 193348.png

0 Kudos
Message 2 of 3
(2,296 Views)

Similar to what was already mentioned by StevenD, you don't have quite the same arrangements for your reads - numbers 2-8 (array elements 1-7) have specific cases.

 

The case for the first element (array element 0, Anode/Cathode 1) is shared with the later values, which are read after. So if something like "ni.var.psp://my computer/IHF_CMS_Modbus/430083" reads 0, you'll get zero overwriting the value from ni.var.psp://localhost/Anode_Shared_Variables/300068.

 

If you don't want to remove those (my computer/IHF_CMS_Modbus) values, you could add a separate default case, and make the first case 0 only (not default).

 

I'd also suggest a couple of other changes:

  • You populate two indicators for each case - you could instead right click on your tanks and chose Visible Items > Digital Display to get a numeric value, removing half of the writes
  • Each of your cases is identical except for the specific indicator being wired. You could instead:
    • Do the division and in range -> colour conversion outside the case structure, then pass two values in. You still need a bunch of cases, but this is a simple change
    • Alternatively, use a cluster of tanks (you can't directly use an array because you might want different colours per element) and then use an array of references (from Property Node (Cluster) -> Controls[]) to set colours. See image

Use clusters for display and array to maniuplate numbers. FP truncated but has 8 elements.Use clusters for display and array to maniuplate numbers. FP truncated but has 8 elements.

You can also add labels/captions to the elements in the cluster to label them Cathode 1, Cathode 2 etc. I didn't do a very careful job arranging the position and size of the digital displays but you should of course make them look nicer (same size, same height etc).

 

Note if you keep the other values (not anode/cathode) in the array, you'll probably want to use Array Subset to limit the inputs to the division and in range/coerce function (although I think there wouldn't be a problem here, since Array to Cluster will force the set number (8) and the For loop will index only the shortest input array (which will be Controls[] rather than colours if you have a longer input to the In Range function)).


GCentral
0 Kudos
Message 3 of 3
(2,286 Views)