Breakpoint Trigger Start/Stop Data Acquisition

[Rob M.]

I developed a small application to acquire data from a photodiode during a short motion event (1 mm travel). This is for a simple interferometer. I have created a start trigger for data acquisition using a motion breakpoint at the inital encoder value, which gets routed over the RTSI line. I have created a software stop trigger by ending the DAQmx read loop on the conditionial output of the check move complete VI, which is also in the loop. This application works o.k. and gets the job done. But, I think that motion VI has some overhead that lets some extra unwanted data points to be taken in the loop.

I am using this method as a result of not being able to correctly configure a hardware based stop trigger (due to my inexperience). That is, I wanted to use a second motion breakpoint (final resting point) to reference trigger as a stop trigger for data acquisition instead of the check move complete VI as a loop control.

What is the best way to accomplish this? Should I lliterally put in a second seperate breakpoint? Should I use a buffered breakpoint function that preloads the start and stop positions in one control? In what mode and what action should the breakpoints be configured? Why?

Any advice on this matter would be appreciated. Example attached. I use PXI-7344 for motion and PXI-4462 for DAQmx and LabVIEW.

Thanks,

ROB M.

[Lorne H.]

Rob,

Buffered breakpoints would be a great solution to your problem, but buffered breakpoints and periodic breakpoints are not supported on the 733x and 734x series motion boards.  Having said that, you can still achieve the behavior you want.

You said...

"Should I lliterally put in a second seperate breakpoint?"

Yes.  What you will want to do is change your code so that do the following steps...

1.  Load an initial breakpoint which will trigger the start of your acquisition.
2.  Poll the status of your Axis for the "Position Brkpt" boolean to become true, indicating that the breakpoint has occured.
3.  Once "Position Brkpt" is true (use "Read per Axis Status.flx" to obtain "Position Brkpt") load a the new breakpoint position.
4.  Reenable the breakpoint.

The only problem with this setup is that there is going to be a small delay between when the first breakpoint occurs and the when the 2nd breakpoint is enabled.  If your desired position is reached before the 2nd breakpoint is enabled your program will not work.  There really isn't anyway around this issue unless you upgrade to a 735x series board.  You can reduce the delay mentioned above by using modulus breakpoints.  Modulus breakpoints would allow you to skip having to load a new breakpoint position.  Below is some information about breakpoints...

Using Breakpoints in the Motion Control Module

I hope I answered your question.

Lorne Hengst
Application Engineer
National Instruments

[Rob M.]

Hello Lorne,

Yes, this answers my question. As most answers do, it has generated a few more questions!:
1) I assume that you mean to poll the status of the axis for breakpoint status the same way I have the "check move complete" in the loop. Correct? If so, it will be interesting to see if this is any more efficent than what I have now, or any more accurate.
2) When using the modulus breakpoint, I wouldn't have to put anything in the loop, correct? I just have to set the configure breakpoint VI to "reset", and let the reference trigger take care of the waiting for the second signal over the RTSI line?

Thanks again.

ROB M.

[Lorne H.]

Rob,

"1) I assume that you mean to poll the status of the axis for breakpoint status the same way I have the "check move complete" in the loop. Correct?"

Yes.  Exactly.

"If so, it will be interesting to see if this is any more efficent than what I have now, or any more accurate."

As long as you have enabled the new breakpoint before the position of the breakpoint has been reached, it will be much more accurate than your previous setup.  Having a second breakpoint will be hardware timed as opposed to your previous setup which was software timed.

Basically, once your first breakpoint is reached, you will immediatly setup and enable the 2nd breakpoint.  Then, you will constantly poll your motion for move complete.  I guess I am trying to point out that the polling of the breakpoint status is only temporary and should be over very soon after the 1st breakpoint has been reached, while the polling to check to see if the move is complete will should be take a long time in comparison to the polling of the breakpoint status.

"2) When using the modulus breakpoint, I wouldn't have to put anything in the loop, correct?"

You will still need something in the while loop, because you will have to continue to poll the status of the first breakpoint to detect when it has been reached so you can run "Enable Breakpoint Output.flx".

With Modulus break points you only need to run "Enable Breakpoint Output.flx", but with a single breakpoint point you will need to run "Enable Breakpoint Output.flx" and "Load Breakpoint Position.flx".

It sounds like you are a bit confused about the operation of modulus breakpoints.  Even though they allow you to have "periodic" breakpoints, you still have to reenable the breakpoint after each breakpoint occurs.  This is different than periodic and buffered breakpoints (which your board doesn't support) which don't need to be reenabled.

Please ask more questions, as I understand this topic can be quite confusing.

Lorne Hengst
Application Engineer
National Instruments