LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

best approach to implement Abort

Highlighted

I have a burn-in program which has nested WHILE loops. Four power levels and six impedance settings. Dwell several minutes monitoring RF power at each impedance. Management wants a way to abort if the power goes out of range during the dwell.

 

Right now I have an Abort button on the front panel and OR it with DwellTimeExceeded to stop the inner WHILE loop.

 

Is this the correct way to do this?

 

 

 

0 Kudos
Message 1 of 11
(999 Views)
Highlighted

Well, if it works, then it is correct! Is it the best way? Probably not.

 

I would consider a state machine rather than the nested loops. Do not stay in any state more than the maximum time you are allowed to respond to a user input (Boss says Stop!) or a measurement out of range (more reliable than user input). Repeat the state as many times as required to achieve the dwell time.

 

Lynn

0 Kudos
Message 2 of 11
(984 Views)
Highlighted

If there are 4 possible values for the Set RF Power state and at each RF power settings there are 6 possible impedance settings for the Set Impedance state, how does that get implemented when using a state machine design?

 

0 Kudos
Message 3 of 11
(972 Views)
Highlighted

@nyc_(is_out_of_here) wrote:

I have a burn-in program which has nested WHILE loops. Four power levels and six impedance settings. Dwell several minutes monitoring RF power at each impedance. Management wants a way to abort if the power goes out of range during the dwell.

 

Right now I have an Abort button on the front panel and OR it with DwellTimeExceeded to stop the inner WHILE loop.

 

Is this the correct way to do this?

 

 

 


stopping the loop process does not control the out of range power, maybe you should look into feedback control...otherwise you loose control when you exit the loop. do you have a way of resetting the power once you exit?

0 Kudos
Message 4 of 11
(966 Views)
Highlighted

Those are data. If the values are fixed, create an array constant and index out the ones you need for a particular test. For more versatility, read the data from a file. You would have one state to set Power and another state to set Impedance. The Set Power state reads the value from the array. It could be indexed based on a model number or user selection, or it could cycle through all possible values, depending on your test needs. You should also include states to shut off the power and set the impedance to a default or safe condition in the event of an error, user Abort request, or the end of the test.

 

Lynn

 

 

0 Kudos
Message 5 of 11
(964 Views)
Highlighted

I second the method of feedback control.

 

I had a similar situation where I was sweeping the frequency and inputting it to a power amplifier. The power amplifier output was not constant with frequency. I measured the voltage output from the power amplifier and adjusted its input accordingly. I made the program stop if I had to adjust the input more than 10%, (for me this indicated something wrong), or if after three adjustments I could not achieve the dersired voltage level. This allowed unattended operation.

 

Cheers,

mcduff

0 Kudos
Message 6 of 11
(944 Views)
Highlighted

Lynn is right.  A state machine where you read a bunch of the settings as an array is the way to go.  I highly recommend you draw out your states and the transitions so that you can see how it should work (Visio is really good for this).  And I have found that using a queue to hold your states works very well in situtions like this.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
0 Kudos
Message 7 of 11
(932 Views)
Highlighted

@johnsold wrote:

Those are data. If the values are fixed, create an array constant and index out the ones you need for a particular test. For more versatility, read the data from a file. You would have one state to set Power and another state to set Impedance. The Set Power state reads the value from the array. It could be indexed based on a model number or user selection, or it could cycle through all possible values, depending on your test needs. You should also include states to shut off the power and set the impedance to a default or safe condition in the event of an error, user Abort request, or the end of the test.

 

Lynn

 

 


http://www.ni.com/white-paper/7595/en/  is NI's tutorial on how to set up a state machine.

 

I am unclear where to place these array constants.

 

 

0 Kudos
Message 8 of 11
(918 Views)
Highlighted

Where the array constants would go depends on how you set up the state machine and where they will be used.  If you will never change them (remember, never is a long time) and they will only be used in one state, they can be placed inside that state. If you might read values from a file, the data would go in a shift register and the constants could be outside the loop to initialize the shift register or could be in an initialize from file state.

 

Lynn

0 Kudos
Message 9 of 11
(911 Views)
Highlighted

@johnsold wrote:

Where the array constants would go depends on how you set up the state machine and where they will be used.  If you will never change them (remember, never is a long time) and they will only be used in one state, they can be placed inside that state. If you might read values from a file, the data would go in a shift register and the constants could be outside the loop to initialize the shift register or could be in an initialize from file state.

 

Lynn


The problem is that each state can take a long time to complete.

 

Apparently, the key is to break the every state further down into tiny baby states.

0 Kudos
Message 10 of 11
(883 Views)