reading problem

[Mark1349]

I have inherited a test program that uses VISA to read values.  This program has a engineering screen that uses a producer / consumer architecture, with buttons which trigger reading and writing of the VISA values.  The program is very slow to read and write values (I wonder if this is because the lack of waits in the while loops). 

Ideally all of the values would read and write continuously, but I am not going to change the program that much. 

The issue is the program will allow the switch tank value (see snippet below) to be switched when it is not safe.  This value should only be switched when two other values are at or close to zero.  

I want to disable and grey out the control for this value, but the values need to read numerous times until they are stable to determine if it is safe to enable the control.

This is only active when relay 1-5 or switch tank is pressed:

I am offsite right now, but I am going to insert this while loop with both read values, as shown below.  Will this work? Any comments are welcome.

[altenbach]

---

@Mark1349 wrote:

---

It is impossible to debug truncated code pictures.

Some questions:

• Are the shift registers initialized? 
• Why use a value property instead of a local variable? Where is the terminal?
• You have two identical "code trains", differing only in ai_0 vs ai_1 Why not use an inner FOR loop, autoindexing on an array of two enums. (I assume the subVIs are not reentrant and will not run in parallel anyway).
• with a loop rate of 10ms and a 10 point history, you are only looking at 100ms worth of data. Is this sufficient?
• How does this loop fit into the rest of the architecture? When is it called and what happens when it stops?

[Mark1349]

Altenbach,

Thank you for your response. Those are good questions.

#1 The shift registers will read the starting value of the analog inputs.  I could start them at some value, but since I am looking for zero, I would need to start them higher than zero, but would not want to delay the slow VI any more than it already is. 

#2 The local variable is located inside the consumer loop with the Ai_0 button.  As I said, I don’t like the fact none of these indicator values are actually updated until their button is pressed.

#3. The subVIs are not reentrant. The intent is to prevent the operation of the Switch Tank control if either the Ai_0 r Ai_1 value is above 0.2.  Once below 0.2, the loop would exit and allow the   switch tank control to be enabled.  Not sure how this could be done with a For loop.

#4. You are likely correct, probably need 100ms or more, won’t know until I actually put it in the code.

#5.  The intent is to disable and grey out the Switch Tank control shown above, whenever either value is above 0.2.   I think this can be accomplished by inserting this into part of the existing block diagram that is always running when this screen is active, then adding write commands to drop Ai_1 to  zero (Ai_0 will follow as it discharges) if any of the switch controls are activated.  

[altenbach]

---

@Mark1349 wrote:

#5.  The intent is to disable and grey out the Switch Tank control shown above, whenever either value is above 0.2. 

---

Your code is not doing that at all! What you are checking is if the difference of the current value compare to the 10 previous values is less than 0.2. So if your reading is 1000 and stays there, the condition is already met.

We really have no idea how your various code fragments are assembled. 

[Bob_Schor]

I understand that you don't want to share your (actual, mal-functioning) LabVIEW code as it might have proprietary information (possibly based on the names you chose for the variables or the values you placed in the Front Panel entries), but it is extremely difficult to understand what you are trying to do based on the limited information we can glean from the "pictures" of some fraction of your LabVIEW code that you choose to share with us (with Front Panel indicators heavily redacted).

There are several "curiosities" in the latest set of "pictures" of your LabVIEW code. 

• I didn't realize there were multiple images "stacked" on top of each other (not that seeing the other images were that helpful).  I didn't understand (for example) why you show us a Front Panel with redacted inputs (as opposed to "made-up names" that avoid "scribble marks").
• Once I accidentally clicked on the (almost-invisible) ">" symbol and saw selected "Block Diagram" images, I was still puzzled by not understanding why you "did what you did".
  • One of the important elements of LabVIEW is the Event Loop, an Event Structure inside a "Do Almost Forever While Loop" (by that I mean an Event monitoring the "Stop" button and stopping the Event Loop and sending a signal to the Main loop to go into its "Clean up and Exit" code.
  • Most Event Loops that are managing Front Panel Controls don't wire anything to the Timer entry, which means they take 0 CPU time until an Event triggers the loop.
  • Event Loops typically run in parallel with the "Main" loop of a State Machine that handles "most" of your code.  
• My (strong) recommendation is for you to make a copy of your "Main" VI (maybe call it "Simple Demo") that handles a single channel (which you could name, or not name, as you wish).  This would be a separate VI with no "list of things to do", but only one Channel.  What do you want to?
  
  1. Init Channels:  Initialize the Channel (set up A/D, D/A, etc.)  You don't need to actually show code to do this, but this can be the name of an initial State of your State Machine).
  2. Init Threshold:  Initialize the "Threshold" variable(s).  
  3. Check Threshold:  take a reading and see if next State is "Check Threshold" (not ready) or "Do Something".
  4. Do Something:  whatever you want.  If your data rate is fairly slow, you can take 1 sample, have a free-standing "Wait" (say, 1 sec if you are sampling at 1 Hz), then return to "Check Threshold".
  5. Handle Close Program:  State that gets called when you want to exit the program.  It needs to shut down all the loops, including the Event Loop.
• The "Do Something" loop acquires data for you, one point (or one "array of points", for example, sampling 1000 points at 1 kHz which takes 1 second) and you may want to do something with these points, such as plot them or save them to disk.  This is a perfect place for the Producer/Consumer design pattern, where you use a Queue or a Stream Messenger Channel to send the data "instantaneously" to a parallel "Write Data to Disk" loop.  One nice thing about the Stream Channel is it has a Boolean control that says "This is the last time I'll call you, so you can shut down when you get this".

Note that the above (over-simplified) model has three parallel loops:  an Event Loop that is largely monitoring changes to Front Panel controls, the Main Loop which gets inputs from the Event Loop to change the parameters of what it is the Main Loop does, and a "Data-Consumer" loop that handles the data that is generated by the code in the Main loop.  All three loops will have a coordinated "Stop" routine -- pressing the Stop button fires off the Event Loop which switches the Main Loop to "Handle Close Program", which in turn sends a message fo the Data-Saving Loop to exit.

     I know this may be a lot of "new stuff" that you might not be ready to tackle at this point.  But if you can create a simple "one-channel" version of your actual LabVIEW Project, with "made-up names" where you have redacted information, bundle it in its own Project (in its own Project Folder), and pass us a compressed version of this Folder, we'll be much more able to provide more specific help.  Right now, I'd say cleaning up your Event Structure may take top priority.

     Please help us to help you.

Bob Schor