Change a VI to a more sophisticated pattern (e.g. consumer/producer)

[Konrado]

Hi everybody!

I have written a VI taking spectra from a triggered flash lamp and spectrometer. The whole systems works in a rotating device. So the triggering and exact timing is quite important. I finally got my Vi to work  but there are still some problems with the spectrometer. I think this is due to the fact that the spectrometer runs into a internal timeout but I don't know why. Furthermore there is still a lot of false triggering when changing to the next sample with a different delay.

So it's really time to take a deep and think about my program. At the moment I have a flat sequence with some for loops defining the number of measurings as well as the while loops for the triggering...

Well that's I want to do:

1. All the necessary data comes in a cluster from a different vi

2. Initialize: Create folders, calculate positions for the step motor and move it to the initial position, open spectrometer and so on

3. Start the speed measuring and calculation of delays

4. Measure the spectrometer dark current

5. Move step motor to the first position

6. Start retriggerable task for lamp and spectrometer (the triggering occurs in a subvi, whereas the delays are updated continuously by a reference) 

7. Measure at step motor position first sample, second sample and so on

8. Move stepmotor -> 7

9. Stop retriggerable task for lamp and spectrometer

10. Save data and wait for a specified time

11. Back to step 5

12. In the end: Close the spectrometer, stop the speed measurement and so on

Furthermore the data has to be displayed:

1. The actual scan

2. Step motor position dependent absorption for the actual scan as well as the former scans (by option)

So much for the theory. I thougt that maybe a produce/consumer patttern would fit but I have no idea how to realize this. Of course I have read a lot but I don't know how to do the triggering stuff and so on.

I have attached my main vi that you can see how I deal with this at the moment. Of course all the subvis are missing but the working principle should be clear. Please let me know if If you need any more information!

I want to do two things. First I want to separate the data aquisition from the display and file I/O, second the data aquisition has to be seperated from the lamp and spec triggering.

Especially the second point seems to be very important because my spectrometer runs into some internal timeout (not because there is no trigger) after some minutes or hours (the exact time is not reproducible, but it does happen) and crashes my whole system  as I mentioned before.

I don't know why but I hope so much that a more sophisticated vi pattern will solve this problem.

May you help me with this?

Thanks!

[Frabto]

If the vi runs without user intervention, then simple Enum based state machine architecture can be used.

---------------------:
1. All the necessary data comes in a cluster from a different vi
State -1

2. Initialize: Create folders, calculate positions for the step motor and move it to the initial position, open spectrometer and so on

State -2 Initialise state

3. Start the speed measuring and calculation of delays

This can be a Dynamically launched vi ( and can be launched in State-2) where it waits for the notification from State -2 to start Acquisision.
This vi will also stop acquisiion based on another notification from the main vi states
State-3 -> Set start notification for this cont. running sub vi


4. Measure the spectrometer dark current

State -4

5. Move step motor to the first position

State -5

6. Start retriggerable task for lamp and spectrometer (the triggering occurs in a subvi, whereas the delays are updated continuously by a reference)
This can also be another dynamically launched subvi, that is launched in State -2 itself.

State-6 -> Send Notification to start the Retriggerable task

7. Measure at step motor position first sample, second sample and so on
State -7.Measurement

8. Move stepmotor -> 7
9. Stop retriggerable task for lamp and spectrometer

State -8 Send stop notification to stop the Retriggerable task.

10. Save data and wait for a specified time

State -9 - Log the Data

11. Back to step 5

State 10 .. Check for completion.if required again redirect to state -5

12. In the end: Close the spectrometer, stop the speed measurement and so on

State -11 Send stop ACQ notification for all the dynamically launched vis, stop those vis..close  all instrument refs .. stop main vi

If the states are dependent on user intervention then Event based producer consumer can be used where, the producer will control when to start the whole process and when to stop the process( Using queues).The consumer can be Queue driven Enum based state machine

[Konrado]

Hi nijams,

thanks for your fast answer!

The user has the be able to:

- Stop the experiment bevore the number of measurements is reached

- Change the speed for the next measurement

- Select which plots he wants to see (sample and wavelength)

Everything else will proceed automatically.

Is an event based producer consumer scheme necessary to do this or can I use the Enum based state machine?

Some more questions

- How will the data display be accomplished? Will this be in the consumer part whereas everything else is in the producer part

- To the dynamically launched vis: This is not completly clear to me. How can I launche a vi, go to the next state and start this vi. Do you have an example for me how to do this. It's the same thing with reading the speed values at some positions in my vi, access the delays, changing the retriggerable task and so on.

Thank you!

[Frabto]

You may need event based producer consumer architecture as you need to control the acquisition.

For Dynamic Launching pls se the snippet

   

Yes, References are required to Update FP from  the Dyamically launched vis.

Alternatively you can have the parallel loops in Main vi and control the Acquisition from main Loop.

More info here.

Also look good basic info here and here.

If you still need more clarifications in implementation pls post

[Konrado]

Hi, the "Queued State Machine Architecture" should fit quite well but it seems to be tricky, too. But I will give it a try!

Just to make sure that I got everything right.

I have three different parts:

1. Event structure

Cases: Change Speed, Stop after Scan Finished, Stop Immediately

2. State machine

Cases: GetData from Main VI, Initialize, Measure Dark Current, Start Retriggerable Task, Measure Spectrum, Plot Spectra, Move Step Motor, Plot Motor Position Graph, Stop Retriggerable Task, Log Data, Check for Completion, Write Setting File and Close VIs, Stop

3. SubVIs

3.1 Speed Measurement

3.2 Triggering of Lamp and Spectrometer

Is this okay, or would you suggest another pattern? And another question: Is it better to do the Measure Spectrum in an own VI (3.3) or should it be done in the consumer state machine?

Thanks!

[Konrado]

Hi everybody,

I used the last weeks to do some work on the transition of my software.

Of course some problems came up and I would be very grateful if sb could help me with this.

Here is my first question (some will follow in the next days...):

I use now the Queued State Machine Architecture with 8 parallel producer processes.

The first process is my DAQ-Task for the speed measurement with the following states:

- INITIALIZE

- READ

- SEND SPEED TO MAIN

- SEND DATA TO MAIN

- SEND TO DAQ (this is another parallel process)

- CLOSE

- IDLE

- ERROR

- EXIT

The SM is intialized by means of my main vi, then the reading is perfomed and the data is send to DAQ (after each reading).

I use the IDLE-state to keep on running the vi continuously.

How can I do the following: Send the speed to Main each second (not after every reading to lower the computing load) and send DATA to main after a specified time?

Thanks!

[johnsold]

Create a shift register with Time to Send Speed and Time to Send Data values (cluster or array in one shift register or two separate shift registers). After each Read compare the current time to the Time to Send values to determine which state should follow.  In the Send states, update the Time to Send values.

This is one of the beauties of the state machine - it allows such customization with minimal effort.

Lynn