LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

State machine timing

Solved!
Go to solution

Hi NI family. I have two questions. How can i make the transition in the sequence for the state machine attached faster. Also i would like to know how to adjust my timing. The time specified in my wait function is off when i actually run the VI.

0 Kudos
Message 1 of 8
(3,796 Views)
Solution
Accepted by Charles.m

Put your DAQ initialization in your initialize state.  Right now it initializes every loop iteration.  This is not necessary and wastes time.  Use a shift register to pass the DAQ task reference.  Do you need to write to the DAQ in every state?  Right now it writes no matter what the state is.  Move the DAQ write to the states where needed.  This will speed up your code also.

 

Why do you say that your wait function timing is off?  How far off?  You know that your actual time for the wait cycle is more than just the wait time.  It includes the other operations outside the case structure.  Moving the DAQ stuff will make the wait more accurate.

 

- tbob

Inventor of the WORM Global
Message 2 of 8
(3,787 Views)

Thanks tbob. Moving the DAQ stuff changed the timing. However  I couldn't fire my relays anymore. I suppose I did something wrong. Can you illustrate your solution in a vi. I do not need to write to the DAQ in two ( wait and start) states. 

0 Kudos
Message 3 of 8
(3,752 Views)

@Charles.m wrote:

Thanks tbob. Moving the DAQ stuff changed the timing. However  I couldn't fire my relays anymore. I suppose I did something wrong. Can you illustrate your solution in a vi. I do not need to write to the DAQ in two ( wait and start) states. 


Without looking let me guess...

 

The task is not wired thru all of the cases and "use defualt if Not wired" is letting you get away with it.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 8
(3,741 Views)

@Charles.m wrote:

Thanks tbob. Moving the DAQ stuff changed the timing. However  I couldn't fire my relays anymore. I suppose I did something wrong. Can you illustrate your solution in a vi. I do not need to write to the DAQ in two ( wait and start) states. 


Attach your vi so we can look at it.  I'm inclined to agree with Ben's diagnosis.

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 5 of 8
(3,731 Views)

4 milliseconds is pretty fast for software timing.  OS latencies may often be larger than that.  What happens if you put nothing but the DAQ stuff in one loop and everything else (controls and indicators) in another.  Also, rather than using Delete from Array which may cause memory re-allocations, just use Array Subset and calculate index from a counter in a shift register.

 

For testing just put the DAQ Write and a few distinct patterns into a For loop and see how consistent your timing is.  That should tell you how much of the problem is OS related and how much is due to your program structure.

 

Lynn

0 Kudos
Message 6 of 8
(3,724 Views)

Thank you all for your feedback. I will go through with your recommendations one at a time. Here is my VI.

0 Kudos
Message 7 of 8
(3,704 Views)

I am assuming that your DAQ initilaize (Create Channel, Configure Timing, etc) is in the Untitled VI that is missing.  You still have your DAQ initialize in every state.  You only need to initialize once.  I moved it to before the loop.  The shift registers are for passing the task session to every DAQ function after initialize.  You need to learn this concept.  I have attached the corrected copy.

 

- tbob

Inventor of the WORM Global
0 Kudos
Message 8 of 8
(3,688 Views)