How to run two parallel loops with motor control and daqmx data acquisition

[odessy27]

Hello Everyone, 

I am using two of these linear stages from thorlabs as an xy scanner. I built the VI for the scanner and it works fine. I, now want to control the acquisition from the photodiode when the stage is moving. Meaning, I want to save the  save the data only when x stage moves from initial to final position. I implemented this using notifier to connect two paralle loops. I noticed that the data acquisition part was only recording 1 minute worth of data, even though the total time to move was more than few seconds. Upon further investigation, I found out that while the motor was moving the acquisition while loop just freezes. If I understand correctly, the parallel loops should run independent of each other on two different cores (it was running on duel core processor), then what is the cause of this issue? Any inputs? Anyone?... anyone? Bueller...?? 

-N

[Gregory]

That's odd, since you are using "get notifier status" instead of "wait on notifier" I don't see any reason why the bottom loop should lock up. How did you verify it was locking up? By putting an indicator on the "iteration" terminal?

I believe there is some simple reason for your problem, but on a side note: when I have two asynchronous processes (as you do here), I often have a third loop that kind of ties them together. Now this requires a bit more sophisticated architecture with some messaging queues so that your third loop can ask the other ones to do actions or send it data. Just something to keep in mind for the future 🙂

[Bob_Schor]

The Picture is pretty useless -- it look like a LabVIEW Snippet, but I couldn't get it to "expand".  Fortunately, you attached Main.vi so I could see the code.  [Attaching the Project File by itself, as opposed to compressing the folder containing the Project and attaching the resulting Zip file, which gives us everything, is pretty useless -- it just tells us the names you chose for the missing VIs].

LabVIEW Gurus more knowledgable than I say "Don't have more than one Event Loop in a program".  You don't need the bottom Event Structure, as your Notifier tells you when you need to save TDMS data.  Consider the following:

1. Make a Case Statement surrounding the TDMS code.  Wire the Notifier to the Selector, so that the Case only runs when you are moving the Stage.
2. The True Case saves your data to the TDMS file.  Begin with another Case Statement, with a Boolean from a Shift Register wired to the Selector.  We will manipulate this so that we only execute the code in the Case when we start a Stage movement.
3. Inside the True Case, put the code that creates the TDMS file.  Output the File Reference (which will go to a Shift Register, as you have already done).  
4. Follow this with the code to write data to the TDMS file.  Also (from within the outer Case Statement) wire a False to the "Create TDMS" Shift Register you created for Step 2.
5. Finally, wire an initial True to the Create TDMS Shift Register from outside the While Loop.

Do you see what happens?  As long as you are not moving the Stage, the "Save Data" Case Statement doesn't execute, and the Shift Registers don't change.  When the Notifier first goes True, you start the Save Data Case, which looks at the Create TDMS Shift Register (= True) that creates the TDMS file, then writes data, then sets "Create TDMS" to False.

Oops, I forgot to set Create TDMS Shift Register back to True -- you do this in the False case (which I forgot to mention), because when you stop the Stage, then the next time you turn it on, you want to create a new TDMS file.

Bob Schor

[odessy27]

---

@Gregory wrote:

That's odd, since you are using "get notifier status" instead of "wait on notifier" I don't see any reason why the bottom loop should lock up. How did you verify it was locking up? By putting an indicator on the "iteration" terminal?

I believe there is some simple reason for your problem, but on a side note: when I have two asynchronous processes (as you do here), I often have a third loop that kind of ties them together. Now this requires a bit more sophisticated architecture with some messaging queues so that your third loop can ask the other ones to do actions or send it data. Just something to keep in mind for the future 🙂

---

Yup, I did verify it using indicator on loop terminal.  And I am not sure why it freezes. Is there anything about activeX controls that hogs all the resource and pauses the execution of other processes or this is specific to this perticular control and set of drivers provided by Thorlabs?

Also, what is the rationale behind using 3rd loop? I often see it in the examples, but never understood the reason behind it.

[Gregory]

---

@odessy27 wrote:

Also, what is the rationale behind using 3rd loop? I often see it in the examples, but never understood the reason behind it.

---

Everything will be easier to debug the less that one loop depends upon another. This way, all the instruments will be held in "dumb" loops that just take orders, and you only have to have one "smart" loop that knows when stuff is moving and when measurements should be taken. With 2 instruments it may, in fact, seem overkill. But the problem gets worse very quickly when you add more instruments.

[odessy27]

---

@Bob_Schor wrote:

The Picture is pretty useless -- it look like a LabVIEW Snippet, but I couldn't get it to "expand".  Fortunately, you attached Main.vi so I could see the code.  [Attaching the Project File by itself, as opposed to compressing the folder containing the Project and attaching the resulting Zip file, which gives us everything, is pretty useless -- it just tells us the names you chose for the missing VIs].

Bob Schor

---

Bob, I did make zipped folder of all my files but chose to upload single file, because it's been a while I posted on these forums, and I wasn't sure how NI treated zipped files (my email server flags it most of the time) . Snippet was my bad (somehow I thought it would expand in the new window).

Thanks for the nice tip for creating new filename without use of event structure, and I agree, having two event structures in the program is not optimal and I'll fix it. Although, it still doesn't explain why loop two freezes while motors in motion.

-N

[QFang]

First thing to do when you have un-expected behavior is to monitor all the error out clusters, you never know when you have a (sporadic) error occuring..

Second thing is to always close your (file) references.  After the DAQ, and when creating a new TDMS file, you need to close the previous (if any) file-reference.

* I quickly added some 'latching error' monitoring and loop exit code plus code to properly close your tdms files.. you will probably need to adapt it to the changes you did already to get rid of the event structure in the DAQ loop.

* I also noticed you have a lot of various things to make the file-name, and just wanted to show you can build strings more efficiently (at least in terms of Block Diagram space) by using the the code I put in as an example. 🙂

* I left brief comments on the BD of my changes.

My hunch is that the missing data is due to either the notifier erroring for some reason OR data is not flushing to disk since the TDMS is not properly closed (or the DAQ is erroring for some reason)..  I would start with this and see if this yields any new information that can help us!

As far as snippets, someone posted about how certain browsers will strip the LabVIEW meta-data from the png files during the upload, but I never use snippets because they seem to never work for me either so I don't know. 🙂