LVOOP Member object parallel operation

[ben64]

I have a test class that contains a DAQ/Switch unit object. For a specific test the core structure is a state machine and I would like to have a parallel loop that scan a thermistor value from time to time. The DAQ/Switch unit is also used in the core state machine as it is used to flip some channels to change configurations. There is also a state in the state machine that loads parameters required for thermistor scanning (in fact the scan command string). Because of that I don't think a DVR would work since I would get a reference to some values before they are set.

I can use a queue and have all the DAQ/Switch Unit operation performed in the parallel loop but that would complicate the error handling (as an example if there was an error setting a particular configuration with the DAQ/Switch Unit I would like to report the error and instantiate a proper closing sequence depending on the state where the error occurred. I know I can use a second queue with error type data to report back the operation status to the main state machine loop but I'm starting to feel like there is a better way to accomplish this.

The thermistor scanning is used as a protection to monitor the temperature of a stepper motor while the UUT is being tested.

Any suggestion?

Ben64

[crossrulz]

You could just command the second loop to stop checking while the main state machine uses the instrument.

Or you could just have the second loop publish the value of the thermistor (global variable, local variable, Notifier) and just have the state machine use that instead of messing with the instrument.

[ben64]

---

@crossrulz wrote:

You could just command the second loop to stop checking while the main state machine uses the instrument.

Or you could just have the second loop publish the value of the thermistor (global variable, local variable, Notifier) and just have the state machine use that instead of messing with the instrument.

---

The second loop is already using a queue to publish the value of the thermistor and the data is being processed elsewhere in the main application. I thought about using semaphore  to avoid simultaneous use of the instrument. This test vi is being dynamically dispatched in a consumer loop of the main application. 

I can't immediately start monitoring in the second loop because the equipment is initialize in the state machine loop.

Ben64

[Tim_McClung]

Have you considered using some form of mutual exclusion (MutEx) to make this work.  I've implemented a similiar solution on a temperature controller that required the Hardware and UI controller to interact with the same hardware.  Basically you have DVR that maintains the state of the MutEx lock and your program requires a check there before they can access it.  I believe this would allow you to get to the data without worrying about if it was instantiated or not, if the data isn't ready your MutEx tells you before you get ahold of it and you can throw an error there.  This also allows you to call the MutEx from anywhere and if you get an error on the data you recieve the error handling happens at the loop that requested it.  This has worked well for me in the past and if I understand your problem correctly I think it would for you as well.

Cheers,

Tim

[ben64]

---

@Tim_McClung wrote:

Have you considered using some form of mutual exclusion (MutEx) to make this work.  I've implemented a similiar solution on a temperature controller that required the Hardware and UI controller to interact with the same hardware.  Basically you have DVR that maintains the state of the MutEx lock and your program requires a check there before they can access it.  I believe this would allow you to get to the data without worrying about if it was instantiated or not, if the data isn't ready your MutEx tells you before you get ahold of it and you can throw an error there.  This also allows you to call the MutEx from anywhere and if you get an error on the data you recieve the error handling happens at the loop that requested it.  This has worked well for me in the past and if I understand your problem correctly I think it would for you as well.

Cheers,

Tim

---

Do you have a simple example of this?

Thanks,

Ben64

[Tim_McClung]

I can show you a code snippet of my implementation but you have to take it with a grain of salt. I used a while loop block shortcut that I wouldn't recommend anyone else using but it worked for what I needed at the time... I'll have it in a minute.

[Tim_McClung]

Have mercy on my bad habits...

[Tim_McClung]

That worked poorly,  Lets try this...

[ben64]

OK thanks, so basically your idea is to put the DVR in a functional global.

Ben64

[Tim_McClung]

A DVR in front of it.  The DVR holds the 'key' to block the FG but you could block anything with it, that's just what made sense for me.  Whatever your sensitive data is you require your code to ask for the key from the DVR before accessing it.  The proper way to do this (read: not the way I did it) would be to return an error on the MutEx block instead of requiring a wait but I didn't have good error handling design implemented at the time so I made a work around.  

LabVIEW provides a lot of good tools for accessing data (FG's are awesome because they are single access, but access) but when you need to make sure it's valid before pulling it a 'data bouncer' of sorts helps manage this.  That's basically what the DVR is doing, making sure everyone waits their turn for data access.

Cheers, 

Tim