Proper way to stop a measurement mid-run, also looking for feedback

[etvg]

Hello all,

Here is some code I wrote up to run an analog Resonant Ultrasound Spectroscopy setup. The code works properly; however, I would like a way to stop a measurement mid-run without having to abort execution. I thought  I could put a while loop around the for loop where the measurement code currently resides; however, clearly this does not do anything as it just waits until the for loop is done (not helpful). Also I would like general feedback. Additionally, I would like to mention I have another version of this code with all the GPIB commands in a subVI, but I figured adding a new feature to this code and re-integrating the subVI later would be the best course of action.

Secondary Questions:

• Any suggestions on how to incorporate the "Set LIA to Fast mode" to the error? This has not been an issue yet, as if a GPIB communication errors occur LabVIEW throws an error anyways
• What is the benefit of changing these 488.2 commands to VISA? As I know someone will suggest it 🙂

Edit: Attached the Save File subVI

[Kyle97330 · Accepted solution]

You can right-click the FOR loop and choose the option "Conditional terminal" and that allows you to stop it on Boolean True/False just like a while loop, or it will stop anyway when its allocated number of loops have resolved.

In regards to your comment about VISA vs GPIB:

VISA addressed can be aliased in MAX, allowing you to redefine what address, bus, and communications type you're using without redoing your code.  That's a more "official" reason.

Unofficially, the VISA nodes have their error in and out in the correct locations (required for my sanity) and the VISA resource wire is "required" so you can't drop down an unaddressed node by accident.

[billko]

Ewww, this is an "icky" part of automated control.  Sure, you can stop the software controlling it, but can you stop the actual measurement in progress?  In my experience, the answer is usually "no" - at least not gracefully.  Stopping the software but leaving the measurement running usually gets the two out of sync, and the software becomes very grumpy.

Probably your cleanest bet is to stop it from the physical front panel of the equipment and deal with any errors in the software.

EDIT: I couldn't look at the code so I assumed you had one long measurement.  If you are looping through a bunch of quick measurements and not one long one, simply aborting the loop will work.  It will complete the current mini-measurement and exit.

[cstorey]

>> Any suggestions on how to incorporate the "Set LIA to Fast mode" to the error? This has not been an issue yet, as if a GPIB communication errors occur LabVIEW throws an error anyways

- Yes, make a subvis that has Error as Input and Output.  Then put that VI in before the While Loop.

>> VISA vs. GPIB

- In your case you won't benefit that much.  VISA would be a bit cleaner and offer flexibility in changing GPIB addresses but that's about it.

Other suggestions.

- Avoid using property nodes like you are doing.  Just move your Shift Registers to the top of the FOR loop.  You can get rid of the other 3 as well with a little diagram re-arranging.  As it is its a race condition, and unnecessary.

- Make a subvi of the SEND and RECEIVE GPIB commands since you have that code repeated 5x.

Craig

[etvg]

---

@billko wrote:

Ewww, this is an "icky" part of automated control.  Sure, you can stop the software controlling it, but can you stop the actual measurement in progress?  In my experience, the answer is usually "no" - at least not gracefully.  Stopping the software but leaving the measurement running usually gets the two out of sync, and the software becomes very grumpy.

Probably your cleanest bet is to stop it from the physical front panel of the equipment and deal with any errors in the software.

EDIT: I couldn't look at the code so I assumed you had one long measurement.  If you are looping through a bunch of quick measurements and not one long one, simply aborting the loop will work.  It will complete the current mini-measurement and exit.

---

Okay, that makes sense. The way my code is written each datum is taken per iteration of the for loop. So it takes a long measurement, but measures it one step at a time. I added some snips to save you the downloads if you'd like to look 🙂

Analog RUS InputsAnalog RUS loop

[etvg]

---

@cstorey wrote:

>> Any suggestions on how to incorporate the "Set LIA to Fast mode" to the error? This has not been an issue yet, as if a GPIB communication errors occur LabVIEW throws an error anyways

- Yes, make a subvis that has Error as Input and Output.  Then put that VI in before the While Loop.

>> VISA vs. GPIB

- In your case you won't benefit that much.  VISA would be a bit cleaner and offer flexibility in changing GPIB addresses but that's about it.

Other suggestions.

- Avoid using property nodes like you are doing.  Just move your Shift Registers to the top of the FOR loop.  You can get rid of the other 3 as well with a little diagram re-arranging.  As it is its a race condition, and unnecessary.

- Make a subvi of the SEND and RECEIVE GPIB commands since you have that code repeated 5x.

Craig

---

Craig,

Thanks for the advice! I will change over the property nodes and implement the Fast LIA subVI you mentioned. I already have a subVI for the GPIB commands, but figured it would be easier for people to took at the code with one less subVI 🙂

[mcduff]

Not sure if it applies here but something to think of.

The fastest FAST1 can update is 512 Hz. The SR844 has an internal buffer that you can write and read to that may be more efficient than what you are doing now.

The SNAP? command returns the values of up to six parameters at a single
instant. For example, SNAP? is a way to query values of X and Y (or R and θ)
recorded at the same instant. This is important when the time constant is very
short. Using the OUTP? or OUTR? command will result in time delays between
reading X and Y (or R and θ) which may be greater than the time constant,.

The way you are reading X, Y, R, and Theta the points are not in phase.

A long time ago I wrote something that would control the SR844 , see this  link, it was my best work at the time, but now I would rewrite it completely different as I am a much better programmer now, it does not use good LabVIEW skills. But you may find some useful pieces in it.

mcduff

[etvg]

Thanks for the help! I'll give it a read tomorrow morning!

[etvg]

---

@mcduff wrote:

Not sure if it applies here but something to think of.

The fastest FAST1 can update is 512 Hz. The SR844 has an internal buffer that you can write and read to that may be more efficient than what you are doing now.

The SNAP? command returns the values of up to six parameters at a single
instant. For example, SNAP? is a way to query values of X and Y (or R and θ)
recorded at the same instant. This is important when the time constant is very
short. Using the OUTP? or OUTR? command will result in time delays between
reading X and Y (or R and θ) which may be greater than the time constant,.

The way you are reading X, Y, R, and Theta the points are not in phase.

A long time ago I wrote something that would control the SR844 , see this  link, it was my best work at the time, but now I would rewrite it completely different as I am a much better programmer now, it does not use good LabVIEW skills. But you may find some useful pieces in it.

mcduff

---

Hey McDuff,

I see the output for SNAP? is in the form: x,y,z,...

I have another code for a digital setup, and it uses the same output file format that I use in the code I posted here. I was wondering, do you have a recommendation on how to separate each one of these values to put into an array to spreadsheet string like I am doing currently? I'll attach a snip of a sample output file so you can see how it currently looks.

Sample Output File

Best,

Erich

[mcduff]

I believe the SNAP values are separated by a comma, look in the manual. I would then use spreadsheet string to array function, make 1d array, and insert it into my 2d array for the file.

Also if you are concerned about speed, only acquire X & Y, and then convert that to R & Theta, querying and waiting for a response is slow, much faster to do it on the computer.

mcduff