fluke 2638a How to Stop Scanning for Fluke 2638A

[jcesar1029]

Hello everybody,

 

I am trying to create a DAQ VI for Fluke 2638A that measures temperature every 15 minutes. I created a producer/consumer architecture for this VI. 

 

During the 15 minute interval (900s), how can I have the Stop button end the program? I need interrupt the Wait for Scan Complete subVI since this is where it stays during the interval of 15 minutes.

 

I am thinking of adding a shared variable node where the subVI  is able to read the value but I am unsure of this approach.

 

Please let me know if there are better ways to do this VI or any comments that I can learn from.

 

 

 

 

Thank you.

Fluke_VI_Rev2.vi

[Jordan Kuehn]

In your top loop you can place an event structure with a timeout value of the 15 minutes and place the scan code in the timeout event case with a reasonable (short) timeout input.  Then in your other event cases you can process things like your stop button.

[hooovahh]

Yeah use the Elapsed Timer express VI and set it to the time you want.  The output is "Time Has Elapsed" Then you can use that in a case structure and only do the work when that time is up.

[jcesar1029]

In your top loop you can place an event structure with a timeout value of the 15 minutes and place the scan code in the timeout event case with a reasonable (short) timeout input.  Then in your other event cases you can process things like your stop button.

 

Thank you for your response.

 

I am confused on the logic. 

 

The event structure will have a timeout value of 15 minutes which will operate the case Timeout. In this Timeout case, the scan code will run once the 15 minutes of no events have occurred. It doesn't seem ideal because I need the scan to start as soon as the user starts the program.

 

Also, what do you mean by connecting a short timeout input aside from the 15 minute timeout? Isn't there only one timeout input for the event structure which it would be 15 minutes?

 

Please let me know if I am thinking it wrong.

Edited June 3, 2015 by jcesar1029

[Jordan Kuehn]

 

In your top loop you can place an event structure with a timeout value of the 15 minutes and place the scan code in the timeout event case with a reasonable (short) timeout input.  Then in your other event cases you can process things like your stop button.

 

Thank you for your response.

 

I am confused on the logic. 

 

The event structure will have a timeout value of 15 minutes which will operate the case Timeout. In this Timeout case, the scan code will run once the 15 minutes of no events have occurred. It doesn't seem ideal because I need the scan to start as soon as the user starts the program.

 

Also, what do you mean by connecting a short timeout input aside from the 15 minute timeout? Isn't there only one timeout input for the event structure which it would be 15 minutes?

 

Please let me know if I am thinking it wrong.

 

 

Sorry for the confusing wording with all the "timeouts".  If you need the scan to start immediately, you could run the scan once before entering into the while loop with the event structure.

The short timeout input is in reference to the timeout input you have in your scan subVI.  Currently it appears that you are feeding it a very large timeout.  Can you share the values that you are using to configure the scan?  If you have configured the scan to take that long it may require a different approach.

 

 

Yeah use the Elapsed Timer express VI and set it to the time you want.  The output is "Time Has Elapsed" Then you can use that in a case structure and only do the work when that time is up.

 

This approach works just as well, and you could OR the output of that with a First Call? primative to get it to run immediately.

[jcesar1029]

Yeah use the Elapsed Timer express VI and set it to the time you want.  The output is "Time Has Elapsed" Then you can use that in a case structure and only do the work when that time is up.

 

Sorry I wasn't clear on my question. I would like the Stop button to stop at anytime the Wait for Scan Complete subVI which has a timeout value of 16.67 minutes. The timeout value allows the program to return an error if there was no hardware scan after 16.67 minutes (interrupts the VI).

 

The Fluke 2638A hardware is set by the VI to an interval of 15 minutes to take a reading. Every 15 minutes there is a temperature scan. The subVI Wait for Scan Complete has a while loop where it keeps running until a hardware scan happens or the timeout is exceeded as shown below.

 

 

When I press the Stop value, I cannot stop the program (obviously) because the data-flow is currently in the while loop. I am unsure as to how to stop this while loop which is inside a subVI. 

 

Sorry for the confusing wording with all the "timeouts".  If you need the scan to start immediately, you could run the scan once before entering into the while loop with the event structure.

The short timeout input is in reference to the timeout input you have in your scan subVI.  Currently it appears that you are feeding it a very large timeout.  Can you share the values that you are using to configure the scan?  If you have configured the scan to take that long it may require a different approach.

 

 

 

This approach works just as well, and you could OR the output of that with a First Call? primative to get it to run immediately.

 

 

Hey Jordan,

 

The large timeout value of 16.67 minutes (1000000 ms) is to allow the hardware to have an interval of 15 minutes. This means that the Fluke hardware counts down 15 minutes and takes a reading. Once the reading is taken, the scan subVI will return the value and move the data-flow to the next step. If the timeout value of 16.67 minutes was reduced to 1 second, we will not be able to take a reading every 15 minutes because in 1 second there will be no scan value detected.

 

I think you are right, I need to approach this VI in a different way.

 

The Front Panel of the VI with the input parameters are shown below. Please ignore the x-axis of the graph, I am still trying to get the timing correct.

 

 

Edited June 4, 2015 by jcesar1029

[Jordan Kuehn]

The large timeout value of 16.67 minutes (1000000 ms) is to allow the hardware to have an interval of 15 minutes. This means that the Fluke hardware counts down 15 minutes and takes a reading. Once the reading is taken, the scan subVI will return the value and move the data-flow to the next step. If the timeout value of 16.67 minutes was reduced to 1 second, we will not be able to take a reading every 15 minutes because in 1 second there will be no scan value detected.

 

I think you are right, I need to approach this VI in a different way.

 

The Front Panel of the VI with the input parameters are shown below. Please ignore the x-axis of the graph, I am still trying to get the timing correct.

 

 

Thank you for showing the settings; they didn't transfer well with the initial snippet.  It appears the simplest approach would be to essentially take the measurement "on-demand" and use the VI to drive the timing as we have described, rather than having the instrument take 900s.  How precise and consistent of timing do you need between measurements?  At a 15 minute interval I would assume a few ms either way isn't a big issue.

[ensegre]

If you are allowed to change the code of the subVI, you have options. The quickest and dirtiest would be to insert a global Stop variable, set to true by the gui, and to have the subVI poll it. More elaborate options including establishing other communication channels, like a message queue, between main and subVI, or options of calling the subVI dynamically and aborting it by reference come to mind. But basically, all boils down to give the subVI a chance of exiting before the full interval of 15min has passed. What nature is the 15min scan of, can it be split into shorter scans? What is the hardware doing at all during the 15min, and can it be aborted? If the goal was be just to take one datapoint every 15min, and communication with the instrument itself would take no time, the periodicity should by all means be handled in the main and not as a timeout.

[jcesar1029]

Thank you for showing the settings; they didn't transfer well with the initial snippet.  It appears the simplest approach would be to essentially take the measurement "on-demand" and use the VI to drive the timing as we have described, rather than having the instrument take 900s.  How precise and consistent of timing do you need between measurements?  At a 15 minute interval I would assume a few ms either way isn't a big issue.

 

Jordan, I understand your idea and it is a good solution. The interval time with a few ms is not a big issue.

 

The only concern I have, which is a personal preference, is I want to have the Fluke hardware to do the timing. 

 

If you are allowed to change the code of the subVI, you have options. The quickest and dirtiest would be to insert a global Stop variable, set to true by the gui, and to have the subVI poll it. More elaborate options including establishing other communication channels, like a message queue, between main and subVI, or options of calling the subVI dynamically and aborting it by reference come to mind. But basically, all boils down to give the subVI a chance of exiting before the full interval of 15min has passed. What nature is the 15min scan of, can it be split into shorter scans? What is the hardware doing at all during the 15min, and can it be aborted? If the goal was be just to take one datapoint every 15min, and communication with the instrument itself would take no time, the periodicity should by all means be handled in the main and not as a timeout.

 

Based on your experience, why would I not be able to change the subVI or make a copy of it? I am curious.

 

The 15 minute scan cannot be split into shorter scans. The nature of the 15 min scan is to take thermocouple readings (15 minute is a standard time).

 

During the interval, the hardware is counting time and once it reaches the 15 min, it will read the thermocouple(s) and update the scan count. The hardware is a Fluke 2638A Hydra Series III. The hardware has a Cancel Scan option that allows the user to manually abort the scan at any instance.

 

I will try the global shared variable and also look into the message queue.

 

What do you mean it should be handle by the main and not as a timeout? You are right, the goal is to take a datapoint every 15 min.

Edited June 4, 2015 by jcesar1029

[ensegre]

Based on your experience, why would I not be able to change the subVI or make a copy of it? I am curious.

 

oh, I was just saying. Maybe the subVI is part of a library you don't want or you're not authorized to change. If it is yours, you can.

 

The 15 minute scan cannot be split into shorter scans. The nature of the 15 min scan is to take thermocouple readings (15 minute is a standard time).

 

During the interval, the hardware is counting time and once it reaches the 15 min, it will read the thermocouple(s) and update the scan count. The hardware is a Fluke 2638A Hydra Series III. The hardware has a Cancel Scan option that allows the user to manually abort the scan at any instance.

so is the instrument really reading for 15 minutes? integrating the thermocouple voltage? Does it need a labview program locked on its shoulder just to integrate with time constant tau?

If the goal is to talk once in 15 min with the instrument to get its last readout, let the main do that, say with an event structure that fires the read in the timeout case, which times out every 15min, but quits the while loop if the stop button is pressed, as was suggested above. Why do you need to lock a subVI waiting, and then pretend that its caller can abort it?

[jcesar1029]

oh, I was just saying. Maybe the subVI is part of a library you don't want or you're not authorized to change. If it is yours, you can.

 

so is the instrument really reading for 15 minutes? integrating the thermocouple voltage? Does it need a labview program locked on its shoulder just to integrate with time constant tau?

If the goal is to talk once in 15 min with the instrument to get its last readout, let the main do that, say with an event structure that fires the read in the timeout case, which times out every 15min, but quits the while loop if the stop button is pressed, as was suggested above. Why do you need to lock a subVI waiting, and then pretend that its caller can abort it?

 

The instrument will read the card where the thermocouple are connected to. Yes, hardware converts the voltage value to a temperature value not LabVIEW. The LabVIEW program sends the initialization values to the hardware and sends the signal to start the scan. Then the VI will read the program through VISA read. The hardware is connected through Ethernet.

 

Let me show you in depth of each subVI. Keep in mind these subVIs are part of the Fluke 2638 that NI offers.

 

Here we start with the main VI.

 

Inside Wait for Scan Complete subVI

 

Now, inside Operation Status subVI; which consists of a CMD and Read subVI

 

The CMD subVI is shown below; it has a Execute Single Command subVI

 

Finally, the Execute Single Command subVi

 

 

Let us go back to the Operation Status subVi, which has the Read subVI as shown below

 

 

In terms of your idea with the timeout, I would like the hardware to do the counting of 15 minutes not the software.

 

I am leaning towards modifying the subVI and constructing my own algorithm to read the buffer of the hardware.

[bbean]

Not sure this will work, but try using the attached VI in a parallel while loop with an event structure and event case for stop button value change.  Its just a wrapper around the viTerminate function in VISA.

 

Also put a sequence structure around the current stop indicator and wire the error wire from just above to the new sequence structure to enforce dataflow to the stop button.  This way it will read the correct value after the event structure fires.

 

 

In terms of your idea with the timeout, I would like the hardware to do the counting of 15 minutes not the software.

 

Not sure why you would do this but if its your preference then go ahead.  As you can see its causing you problems

 

 

I am leaning towards modifying the subVI and constructing my own algorithm to read the buffer of the hardware.

 

Don't waste your time.

VISA Abort Pending Calls.vi

[Jordan Kuehn]

It appears the Wait for Scan Complete VI is simply polling the hardware.  Can you see how many times the loop iterates in a typical scan?  If it is indeed polling at any sort of decent rate you can just pull out that logic and place it in your main diagram and add your stop button to the loop condition.  This should let you keep the timing in the hardware.

I do agree to be confused as to your insistance on using the device to time something as long as 15 minutes as that is what is creating the lack of responsiveness in LabVIEW.

Edited June 4, 2015 by Jordan Kuehn

[jcesar1029]

Not sure this will work, but try using the attached VI in a parallel while loop with an event structure and event case for stop button value change.  Its just a wrapper around the viTerminate function in VISA.

 

Also put a sequence structure around the current stop indicator and wire the error wire from just above to the new sequence structure to enforce dataflow to the stop button.  This way it will read the correct value after the event structure fires.

 

 

Not sure why you would do this but if its your preference then go ahead.  As you can see its causing you problems

 

 

Don't waste your time.

 

Hi bbean,

 

Thank you for your reply. Quick question before I try this, wouldn't this not work since the data flow will be in the Wait to Scan Complete while loop? If I press the Stop button, the event structure will not operate because I am stuck in the while loop.

 

I would need to stop the while loop, prior to moving on to the event structure. Please correct me if I am wrong.

 

It appears the Wait for Scan Complete VI is simply polling the hardware.  Can you see how many times the loop iterates in a typical scan?  If it is indeed polling at any sort of decent rate you can just pull out that logic and place it in your main diagram and add your stop button to the loop condition.  This should let you keep the timing in the hardware.

I do agree to be confused as to your insistance on using the device to time something as long as 15 minutes as that is what is creating the lack of responsiveness in LabVIEW.

 

The loop inside the Wait for Scan Complete iterates at different values: 232, 231, 234, 244 for an interval of 10 seconds. So for a 15 minute interval it would be around 21,960 iterations.

 

I will try that again. I will reconstruct the subVI in the main VI and connect the stop button to it. I tried this yesterday, but I was getting an error (VI broken arrow) where it said it cannot run because the subVI Operation Status cannot run without being inside another VI. That is what I understood.

 

I will upload the error shortly if it happens again. I will keep you posted.

[jcesar1029]

It appears the Wait for Scan Complete VI is simply polling the hardware.  Can you see how many times the loop iterates in a typical scan?  If it is indeed polling at any sort of decent rate you can just pull out that logic and place it in your main diagram and add your stop button to the loop condition.  This should let you keep the timing in the hardware.

I do agree to be confused as to your insistance on using the device to time something as long as 15 minutes as that is what is creating the lack of responsiveness in LabVIEW.

 

Hey Jordan,

 

Here is the error I was talking about. 

 

 

Here is what I did, I took out the elements outside the subVI and tried to run it.

 

[ensegre]

jcesar1029, on 04 Jun 2015 - 7:04 PM, said:

I am leaning towards modifying the subVI and constructing my own algorithm to read the buffer of the hardware.

 

Don't waste your time.

 

If, after all, all boils down to a couple of lousy SCPI commands sent serially, that is really the way I'd pursue, and get rid of the Fluke library and all of its use assumptions. From the snippets you show this one doesn't look that terribly written, but from what I have seen with some other 'official' drivers....

Edited June 4, 2015 by ensegre

[bbean]

Hi bbean,

 

Thank you for your reply. Quick question before I try this, wouldn't this not work since the data flow will be in the Wait to Scan Complete while loop? If I press the Stop button, the event structure will not operate because I am stuck in the while loop.

 

I would need to stop the while loop, prior to moving on to the event structure. Please correct me if I am wrong.

 

 

The event structure is in a parallel loop (just like your consumer loops) with a branch of the VISA session going to it after your initialize.  The event loop will be waiting for an event (in this case the stop button press).  

When you press the stop button it will fire an event , in that event you would execute the VI I attached which should kill the VISA session, which will cause an error in the Read VI (unlocking it) in your loop where you currently have the stop button control wired up.

[Jordan Kuehn]

Hey Jordan,

 

Here is the error I was talking about. 

 

 

 

 

You can navigate to instr.lib in your LabVIEW exe folder, find the drivers and edit the lvlib so that the VI in question is publically scoped.  Will this break anything? I don't think so, but I didn't take the time to find out.

[jcesar1029]

Update:

 

So I eliminated the subVIs that were being used for Wait for Scan Complete and unnecessary code that were added to them. After doing this VI runs as before with the inability of interrupting the 15 minute interval.

 

I placed the Stop button inside the while loop as someone suggested. It does stop the interval but returns an error as that shown below and an incorrect reading value of 9.91E+37 for a thermocouple. I feel that I am close to the solution (thanks to this thread) and will keep working on it. 

 

 

 

 

 

Edit: Here is a close up of the Producer loop.

 

 

The event structure is in a parallel loop (just like your consumer loops) with a branch of the VISA session going to it after your initialize.  The event loop will be waiting for an event (in this case the stop button press).  

When you press the stop button it will fire an event , in that event you would execute the VI I attached which should kill the VISA session, which will cause an error in the Read VI (unlocking it) in your loop where you currently have the stop button control wired up.

 

Hey bbean,

 

I am going to try out this idea now. I will update you on the outcome.

 

Thanks!

Fluke_VI_Rev6.vi

Edited June 5, 2015 by jcesar1029

[jcesar1029]

Hello everybody,

 

I was able to stop the VI during the interval scanning by creating an Event structure inside the producer loop with a time out of 500ms. Every 500ms it is checking if a scan happened. If a scan did happened, then it would go through a case structure where the data would get queue. 

 

So far the VI has been good. I will now implement an excel report in the consumer loop where the temperature values will be recorded with a timestamp.

 

Thank you very much for this idea.

 

Any suggestions on what I did are welcome.