I am running an application where I am synchronizing data acquisition with stepper motor motion using the breakpoint functionality of my motion controller. Ideally I would like to synchronize the start of DAQ with a known position of the motor to within 1ms.
The way I currently have the code set up, my motor and encoder initially start at zero steps/counts and then move in a negative direction. I want the DAQ to start pretty close to the start of the motion (the exact start time doesn't matter, but I do need to accurately measure the corresponding position); to accomplish this, I set my breakpoint to trigger when the encoder position is at -1. However, looking at the measured encoder position (using Read Encoder Position.flx), it is clear that the encoder 'jumps' from 0 to -10 steps as the motor moves through the first step. Depending on the angular velocity of the motor, this step takes ~5ms.
So I guess my question is, even though the breakpoint is set at -1 will it actually trigger when the encoder reads -10 since it does not stop at exactly -1? Or will I need to somehow interpolate between the measurements of 0 and -10 to estimate the instant that the encoder crosses -1?
I am using a PXI-7354 motion controller and a PXI-6229 DAQ mounted in a PXIe-1062Q chassis. The DAQ is connected to a SCXI-1520 strain gauge module with a SCXI-1314 mounting block (I don't think that matters in terms of the latency of the trigger). My motors are set at 400 steps/rev and the corresponding encoders are at 4000counts/rev; they are connected to the motion controller via a UMI-7774.
Thanks in advance for your help!
Solved! Go to Solution.
I would have a few questions for you about the application.
The Analog Input card is mounted in the PXI 8Slot Chassis; does this chassis have a controller or is it being managed from a computer? Are you starting up the Data Acquisition task through software, or would you be using a RTSI line?
After looking around a little bit, I found the following set of examples:
While they are not particularly new, they do something similar and the architecture might thus be of interest. The reason as to why I bring these up is that if we are starting up the matter in software, that more than 1 ms is rather likely due to jitter.
I would initially say that the breakpoint would happen when it passes through the location at hand (and thus at -10 in that particular case). However, I am not quite sure about this last part, so I will look into the matter further.
To answer your questions: the chassis is managed from my computer, and the DAQ task is triggered by a breakpoint sent over the RTSI line.
I have actually seen those examples; I based my Labview code (mostly) off of the example VI 25229.vi and the 202928.vi (which is included in the link you sent). I went ahead and uploaded my code with this post (sorry, it's a bit messy). It is basically an expanded version of 25229.vi which has been modified to allow contoured motion, as well as incorporating some facets of my experimental setup (gear ratios, etc).
I guess I am not 100% certain what you mean when you say that 'more than 1ms is rather likely due to jitter'. Could you elaborate on that a bit for me please?
I was mentioning jitter due to the fact that I, initially, thought you would be starting the data acquisition after a certain point via software. That is to say that you would be reading the signal that would denote the acquisition start and beggining this acquisition after a software trigger. This kind of process would have a great amount of jitter and thus not begin and end always with the same timing.
Ultimately, I have not quite yet found out whether it would hit when it was -10 or when passing through; I did, however, want to answer the other question regarding jitter in the meantime.
Are you a doctor yet? Have you figured out how to make paper planes fly in the wind yet?
PS, Simon says he will write you tomorrow.
I must apologize, I made some research but guess I must have forgotten to post it.
After discussing the matter with a contact in R&D, it would seem that the breakpoint will trigger when the encoder passes the -1 mark. Now, if there is a read when the encoder is at the -10, it might mark in software that the motor stopped at the -10 position. However, since the matter is done in hardware, the pulse will be sent exactly when the encoder passes through that -1 point.
Once again, I apologize for the delay and wish you a great day.