Passing data between two parallel while loops

[Barry675]

Hello,

I am struggling to implement a control system. The physical system consists of the following:

• A networked temperature datalogger (60 channels) sampling every 5 seconds (Agilent 34970)
• An networked datalogger with Analog output driving triac heater controllers (ICPDAS I-8KE8)

The objective is to maintain the temperature setpoint of a test cell using a PID control loop.

My attempted solution (screenshot). I can run the loops (bottom is temperature acquisition and top is analog output) and they behave as expected. Note that I have heavily scrubbed the vi to simplify what's going on - I know the PID is not connected...etc. Both structure are very closely based on the reference Vi's from the manufacturers. 

It is not possible to consolidate both loops as the Agilent datalogger cannot scan faster than every 5 seconds. Speeding it up will cause it to begin re scanning and won't complete the scan of the rest of the card. The analog output must be outputting at 1 Hz (it's controlling other devices from the same card). Therefore I want to be able to move the "SAMPLE DATA" temperature to the PID input.   

Questions:

1. How can I pass the temperature value between the two structures

2. Alternatively, how can I pass the PID output value from one loop to the other (assuming I put it in the 5 second loop).

3. Is this the best approach to achieve this? Would it be possible to eliminate the delay for the temperature datalogger, consolidate the loops and have the temperature scan driven by some sort of elapsed time conditional structure? Basically the loop is running much faster (1 Hz or 10 Hz) but only triggering the temperature scan once every 5 seconds. 

4. As the PID feedback is only 0.2 Hz, is there any advantage to running the output at 1 Hz?

I would appreciate any help.

Regards,

Barry

[crossrulz · Accepted solution]

---

@Barry675 wrote:

1. How can I pass the temperature value between the two structures

2. Alternatively, how can I pass the PID output value from one loop to the other (assuming I put it in the 5 second loop).

---

Use a Local Variable or a Global Variable.  You only care about the latest data, so either of those will work just fine.

---

@Barry675 wrote:
3. Is this the best approach to achieve this? Would it be possible to eliminate the delay for the temperature datalogger, consolidate the loops and have the temperature scan driven by some sort of elapsed time conditional structure? Basically the loop is running much faster (1 Hz or 10 Hz) but only triggering the temperature scan once every 5 seconds.

---

Keep them in separate loops.  It will make reading code a lot easier and you allow for more parallelism.

[Barry675]

crossrulz,

This has done the trick - I knew it would be something straightforward. Thanks for the tip, I didn't know about using local variables. This will help clean up a lot of other VIs too.

Regards,

Barry

[Kevin_Price]

My responses, in order.

1.  A simple local variable would be sufficient here.  Write updated values to it in your Temp query loop every 5 seconds, let your control loop read from it as it iterates at its own pace.  I'd add sequencing to make sure I didn't read the local variable value *before* the 1000 msec wait and then use it for PID and output *after*.  Be sure you read the local at the last moment before using it.

2. Same answer.  Local variable.  Both raw value and PID output only change once every 5 sec, you probably only need to send one of them from loop to loop.

3. I prefer the basic outline you already did.  The two processes are governed by different timing needs, it's cleaner to keep them in parallel loops.

4. You've already said the control needs to run every 1 second for the sake of other devices.   It won't hurt to output the same PID output (based on the same temperature sample value) 5 times during those 5 seconds.  Neither will it help.   You're free to choose whichever fits your software architecture better.    No need to change from what you're doing.

-Kevin P

P.S.  Oops, started a reply and didn't recheck to see if anyone had already replied before I came back and finished.  On the plus side, we agree so that should be good confirmation for the OP.

[wiebe@CARYA]

Just some friendly advice that was not asked for...

Please remove that stacked sequence structure! It's almost certainly completely redundant. We can't see what's in frame 0, but the frame 1 VI is synchronized by those inputs, no need to obfuscate things in a stacked frame. It's preventing overview, and forces redundant clicking to see what's happening.

The flat sequence structure is also redundant, or at least easy to avoid. That function global probably has errors in and out. Use those to synchronize VI execution. Better jet... You already are programming OO, only you're using a cluster as an object, not a class. Put each function in a method of a class, and see your code get clean. You can even convert that cluster to class, so it's data ends up in a class's private data. Bonuses: You get automatic execution synchronization through the class wire, you can have two serial devices (or an array of them), you can add a simulation child, you'll learn a bit about proper OO.

[Barry675]

 wiebe@CARYA,

Thanks for the advice but I'm not sure I'm capable of making many of the changes you suggest as we were simply relaying on a very old vi from the manufacturer (probably 10-15 years old). I'm definitely not a LabView expert and can just about cobble together enough to meet the needs of what we're trying to achieve. 

However, it would be tremendous to have an updated basic program. I attach the manufacturer's example VI (AO_4_ch) below if you're feeling generous and think it is quick to "modernize" it? 

[wiebe@CARYA]

The dll is missing, making it really annoying to do. Also, the init and close are missing.

[Barry675]

Please see the full folder attached

[wiebe@CARYA]

The DCON driver is finished, but that zip adds another API handling the UART. It'll have to wait to next week, off for the weekend.

Note that everything I'll make will be 100% untested. There will be mistakes.