Jump to content

How to Stop Scanning for Fluke 2638A


Go to solution Solved by Jordan Kuehn,

Recommended Posts

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.

 

 

IwgNF5t.png

 

7kaVTEh.png

 

Thank you.

Fluke_VI_Rev2.vi

Link to post
  • Solution

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.

  • Like 1
Link to post

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.

Link to post

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 by jcesar1029
Link to post

 

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.

Link to post

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.

 

zsVta4I.png

 

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.

 

q5OomiE.jpg

 

DwtLeKc.jpg

Edited by jcesar1029
Link to post

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.

Link to post

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.

Link to post

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 by jcesar1029
Link to post

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?

Link to post

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.

rjGrTni.png

 

Inside Wait for Scan Complete subVI

TLLSFJQ.png

 

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

TgbrexL.png

 

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

a7i1w7l.png

 

Finally, the Execute Single Command subVi

iBeD3y1.png

 

 

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

OwWNICR.png

 

 

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.

Link to post

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

Link to post

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 by Jordan Kuehn
Link to post

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.

Link to post

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. 

 

7MAfX0i.png

 

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

 

P2ZJTG5.png

Link to post

jcesar1029, on 04 Jun 2015 - 7:04 PM, said:snapback.png

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 by ensegre
Link to post

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.

Link to post

Hey Jordan,

 

Here is the error I was talking about. 

 

7MAfX0i.png

 

 

 

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.

Link to post

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. 

 

jNzWv3d.jpg

 

Y9rvfVE.jpg

 

 

QN5aDX0.png

 

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

 

izm24bx.png

 


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 by jcesar1029
Link to post

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.

 

O2YZ1vg.jpg

 

UPRz5Wa.jpg

 

3ivLGmk.jpg

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Zyga
      LAVA users,
      We are looking for alternatives for NI DAQ devices for industrial automation. Since NI has its devices mostly focused on advanced/high speed/high precison data acquisition/processing its prices are inadequate to simple automation tasks. 
      I would also say that NI PC based daq systems are expensive if need to be distributed systems (found this but still relatively expensive cRIO required).
      Just now we need to extend our compactDAQ based system with two DIO modules. We even have free chassis slots for this, but station that needs this IOs is few meters away from PC. How easier would it be if we could use single ethernet cable..  Ofcourse we can add another small cDAQ (what we probably going to do) but this is slightly expensive solution for our customer.
      Does anyone have some experience with 3rd party solutions? Any known daq devices vendors? Standalone ethernet daq modules?

      Regards,
      Zyga
    • By Gab
      Hello Everyone,
      Need some verification with daq program.
      I have one force sensor that connectd with my usb daq device. with this force sensor, unknown object is connected(hanging) and i want to find the mass of this object (F=ma) so i am taking continous sample and generate waveform graph. After the scaling, my waveform will be in Newton unit.
      my question is: if i take RMS of this waveform(1d Array data point) and divide by g (9.8 m/s2) then whatever value come is my correct mass? (F=ma).
      Thank you in advance
    • By Atron100
      hi
      i have a question in basic understanding of update rate sample rate samples per buffer and cycles per buffer.
      i have DAQ 6343 and electronic circuit. 
      i'm using AO0 for generation sine wave at these frequencies 10Hz, 100Hz, 500Hz, 1kHz, 3kHz this signal enters to electronic circuit.
      and after conversion i must to measure two outputs of this circuit by AI2 and AI3.
      from my understanding of tech spec of the daq analog output update rate is 900kS/s and analog input update rate is 500kS/s
      as i understand if i have freq = 3kHz the maximum sample rate per buffer is 300 samples
      and if i have freq = 10Hz i can generate this signal with 90000 samples per buffer?
      for analog input the formula is the same?
      that meaning of cycles per buffer?
      which sample rate of AI i need to setup to measure data fast and accurately? 
       
      thanks for answers
    • By _Y_
      I am trying to implement a simple DAQ Watchdog with single digital output but cannot find any logical way to reset the Watchdog timeout signal. One of obvious solutions is invoking DAQmx Reset Device.vi. Unfortunately, it does not work. The Watchdog goes to timeout state but the physical output signal does not turn to High.
       
      For some obscure reason (typical non-qualified guess:) I added bottom part of the code that is red-framed in the BD. The only difference between functional and non-functional code is using DAQmx Start Task.vi, that is located in “Solutionâ€-driven case structure. If Boolean control “Solution†is True, the code works; if False, it doesn’t.
       
      Please help to understand why launching conventional Digital Output task is necessary for normal functioning of the Watchdog?
       
      PS: Attempts to use clear expiration command instead of DAQmx Reset Device.vi were not successful.
       
      PSS: HW is PXIe-6358
       
      PSSS: Unfortunately, I cannot post any image here. Any image format results in "You are not allowed to use that image extension on this community" . The VI is attached.
      watchdogTest150817.vi
    • By pkeny
      Hello,
       
      I have created a vi that controls multiple writes (individually) by a switch. I have it so one individual switch controls one individual write (And is linked to individual clear, stop, error daqmx blocks). I do not think this is efficient as it takes about 4-6 seconds for the switch to actually write (True or False). 
       
      So, I was wondering if someone could help me make my code more efficient so it would run a bit faster.
       
      Thank you
      Digital Outs fine.vi
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.