LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Sequence a good idea?

Solved!
Go to solution

After searching and reading a few forums posts I understand using sequence is probably not the best idea?

I wanted to get some advice on the best way to approach my problem.

 

What I want to do:

I plan to use the van der Pauw method and hall effect to experimentally determine various parameters for a small semiconductor sample.

At present, it is very time consuming to make all the required BNC connections by hand which in all totals to either 24 or 48 connections to be made.

 

To expedite the process I wanted to make use of Labview to control a micro-controller to control transistors which in turn controls relays that make the required connections. At the same time after each set of required connections are made, a current source controlled by Labview should supply the required current, a volt meter to read the voltage. A total of six different sets of four connections to be made and voltage read for each of the six sets. This needs to be done twice, but since the equipment creating the magnetic field is controlled manually, I can just run the program twice.

 

Recently, I've learned how to control an arduino using labview and also how to control both the current source and volt meter using labview as well.

 

So this is the sequence that labview should send out the commands:

 

Using six digital I/O pins on arduino

 

1. At start, all pins are set low.

2. First pin set high while rest remain low. This turns on a transistor which makes the first set of connections.

3. Current source is turned on and supplies a specified amount of current to the sample.

4. Volt meter measures the induced voltage and stores that measurement as a double or whatever in something like an array.

5. Current source turns off.

6. Second pin on arduino set high while rest set low and steps 3-5 are repeated until all 6 voltage measurements have been recorded.

7. The 6 measurements should be exported to excel file or notepad or whatever.

8. The same data could be passed to something like a different tab in the same program to perform the calculations to find the semiconductor sample parameters.

 

 

So now my question on the best way to go about doing these various things. I was looking through labview and found something called a flat sequence, but according to the forums this is supposedly frowned upon.

My other thoughts are using some sort of combination of loops/cases, but I'm unsure how to structure it and what should be included/excluded from the loop. Other thoughts are possibly a timed structure. Another possibility is creating 6 different vi and calling them one by one.

 

So basically the program runs and after it finishes, I need each of the 6 voltage measurements, preferably displayed in both a table and saved to excel/notepad.

 

0 Kudos
Message 1 of 12
(4,504 Views)
Solution
Accepted by topic author SaintsFan

@SaintsFan wrote:

So this is the sequence that labview should send out the commands:

 

Using six digital I/O pins on arduino

 

1. At start, all pins are set low.

2. First pin set high while rest remain low. This turns on a transistor which makes the first set of connections.

3. Current source is turned on and supplies a specified amount of current to the sample.

4. Volt meter measures the induced voltage and stores that measurement as a double or whatever in something like an array.

5. Current source turns off.

6. Second pin on arduino set high while rest set low and steps 3-5 are repeated until all 6 voltage measurements have been recorded.

7. The 6 measurements should be exported to excel file or notepad or whatever.

8. The same data could be passed to something like a different tab in the same program to perform the calculations to find the semiconductor sample parameters.


A state machine with these 8 states (and maybe some helper states: idle, shutdown, startup, error, etc.). 😄

 

Basically a while loop with a case structure (one case for each state) and a state variable (e.g. enum) in a shift regsiter. Look at the design templates that ship with LabVIEW.

 

(A flat sequence is too rigid for this. What if an error occurs in state #5? The is no way to go to an exception state. What if you want to abort in the middle? What if a state fails and should be repeated.)

Message 2 of 12
(4,502 Views)

Yes, I did read something about a state machine. Each state would need to happen automatically (with a short wait to allow for the relays to engage) one after another without user input. Previously, not in labview, I used a state machine to control an autonomous vehicle, but there were inputs from various sensors that set the various states.

 

"(A flat sequence is too rigid for this. What if an error occurs in state #5? The is no way to go to an exception state. What if you want to abort in the middle? What if a state fails and should be repeated.)"

 

Is there an error that can occur? It is just a matter of turning on a transistor and a short wait to ensure the connections are made. Then apply current and take the measurement. There is no sort of feedback coming from the equipment to report any errors. There should be no reason to abort the measurements in the middle and if by some chance there was a need, the stop program button should be enough. Also there would be no way to tell if the state failed until after the end of the six measurements and calculations done to compare with a known test sample.

0 Kudos
Message 3 of 12
(4,486 Views)

@SaintsFan wrote:

Yes, I did read something about a state machine. Each state would need to happen automatically (with a short wait to allow for the relays to engage) one after another without user input. Previously, not in labview, I used a state machine to control an autonomous vehicle, but there were inputs from various sensors that set the various states.


Yes, that would be the same in LabVIEW. Each state will set the next state via shift register, which then will execute at the next iteration without interaction, and so on.

Message 4 of 12
(4,484 Views)

In each of the states should only the arduino portion be included inside? Or should any of the source and measure portion be included in each state as well?

 

 

0 Kudos
Message 5 of 12
(4,471 Views)
There are numerous errors that can occur. Communication can be disrupted by any number of factors. If you are using an NI. Instrument driver, rhere is built in error reporting that you should use. Also, never, ever use the abort button as a normal way to stop your VI.
0 Kudos
Message 6 of 12
(4,469 Views)

This is what I came up with on my own before coming to the forums. This was for a proof of concept before placing any parts orders. I used LEDs to simulate switches and resistors to apply a current and measure the voltage. Instead of the 4 pins you see on the arduino part, there will eventually be 6. The reason all six were needed to be included is because some of the pins default to high, so each time I have to tell 5 pins to go low while 1 is set high.

 

After figuring out the sequencing part, I'll have to tackle storing the data and performing calculations.

 

So from what I uploaded, what should be "inside" each state, all of it? or just the arduino part?

0 Kudos
Message 7 of 12
(4,459 Views)

@SaintsFan wrote:

Yes, I did read something about a state machine. Each state would need to happen automatically (with a short wait to allow for the relays to engage) one after another without user input. Previously, not in labview, I used a state machine to control an autonomous vehicle, but there were inputs from various sensors that set the various states.

 

"(A flat sequence is too rigid for this. What if an error occurs in state #5? The is no way to go to an exception state. What if you want to abort in the middle? What if a state fails and should be repeated.)"

 

Is there an error that can occur? It is just a matter of turning on a transistor and a short wait to ensure the connections are made. Then apply current and take the measurement. There is no sort of feedback coming from the equipment to report any errors. There should be no reason to abort the measurements in the middle and if by some chance there was a need, the stop program button should be enough. Also there would be no way to tell if the state failed until after the end of the six measurements and calculations done to compare with a known test sample.


Well, this application as you describe it may be simple enough to just run things in a sequence, but LabVIEW has much more capability than this. Maybe in the future you would want to automate it further: take data and record it directly to a spreadsheet instead of manually recording your data. Semiconductors are funny things, perhaps you make one which doesn't behave ideally and you need to run a series of current inputs instead of two; or you need to take measurements at different temperatures, now you havetwo variables to vary and the number of experiments goes up; does anything different happen under reducing or oxidizing atmospheres; the currenet source goes awry and sends a current which will fry your sample unless it is stopped ASAP, etc., etc.

 

When you use a state structure, it becomes much easier to redesign your experiment when you want to, because you can always add in an additional state without having to stretch the VI so that it eventually becomes three screens long. If you have to fix a specific point, you can just go to that state and quickly see in which of the two or three subVIs you need to work on. If you are doing something which changes the characteristics of your sample, instead of putting the whole thing into a really long conditional loop, you can just have the stage it's happening in send you back to measurements, until things are stable again (or whatever).

 

In summary, this whole rambling says that a state machine makes it easier to adapt experiments to the task at hand than a long sequence structure. And learning it now will help you enormously in the future because, believe me, you will be writing more elaborate experiments later if you stay in science, if only to do the most tedious tasks.

 

Cameron

 

To err is human, but to really foul it up requires a computer.
The optimist believes we are in the best of all possible worlds - the pessimist fears this is true.
Profanity is the one language all programmers know best.
An expert is someone who has made all the possible mistakes.

To learn something about LabVIEW at no extra cost, work the online LabVIEW tutorial(s):

LabVIEW Unit 1 - Getting Started</ a>
Learn to Use LabVIEW with MyDAQ</ a>
Message 8 of 12
(4,449 Views)

Attached as rudimentary state machine.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 9 of 12
(4,448 Views)

@camerond wrote:

@SaintsFan wrote:

Yes, I did read something about a state machine. Each state would need to happen automatically (with a short wait to allow for the relays to engage) one after another without user input. Previously, not in labview, I used a state machine to control an autonomous vehicle, but there were inputs from various sensors that set the various states.

 

"(A flat sequence is too rigid for this. What if an error occurs in state #5? The is no way to go to an exception state. What if you want to abort in the middle? What if a state fails and should be repeated.)"

 

Is there an error that can occur? It is just a matter of turning on a transistor and a short wait to ensure the connections are made. Then apply current and take the measurement. There is no sort of feedback coming from the equipment to report any errors. There should be no reason to abort the measurements in the middle and if by some chance there was a need, the stop program button should be enough. Also there would be no way to tell if the state failed until after the end of the six measurements and calculations done to compare with a known test sample.


Well, this application as you describe it may be simple enough to just run things in a sequence, but LabVIEW has much more capability than this. Maybe in the future you would want to automate it further: take data and record it directly to a spreadsheet instead of manually recording your data. Semiconductors are funny things, perhaps you make one which doesn't behave ideally and you need to run a series of current inputs instead of two; or you need to take measurements at different temperatures, now you havetwo variables to vary and the number of experiments goes up; does anything different happen under reducing or oxidizing atmospheres; the currenet source goes awry and sends a current which will fry your sample unless it is stopped ASAP, etc., etc.

 

When you use a state structure, it becomes much easier to redesign your experiment when you want to, because you can always add in an additional state without having to stretch the VI so that it eventually becomes three screens long. If you have to fix a specific point, you can just go to that state and quickly see in which of the two or three subVIs you need to work on. If you are doing something which changes the characteristics of your sample, instead of putting the whole thing into a really long conditional loop, you can just have the stage it's happening in send you back to measurements, until things are stable again (or whatever).

 

In summary, this whole rambling says that a state machine makes it easier to adapt experiments to the task at hand than a long sequence structure. And learning it now will help you enormously in the future because, believe me, you will be writing more elaborate experiments later if you stay in science, if only to do the most tedious tasks.

 

Cameron

 


Thanks for that explanation. I eventually plan to do studies with varying temperature that will include a cryostat under vacuum, but this won't be in the near future. Also, formulating how this program could exist as a sequence I really do imagine it as being about three screens wide, lol.

0 Kudos
Message 10 of 12
(4,441 Views)