need help in reducing latency and perform faster motion

[MaxXx]

Hello,

I have written a VI to automate an experiment and control two different instruments, one is a high-speed linear motor made by aerotech and the other is an oscilloscope TDS3034B from tektronix. The highspeed linear motor is used to move a probe mounted on it and the oscilloscope to take voltage data. The experiment require that the probe moves in, hold 30ms (wait time), take data, and move out. This process repeats with small increment in distance. All of this need to be done with a time frame of less than 100ms or the probe will be destroyed by the heat. The linear motor will move the probe at 3000mm/s.

The VI I made using flat sequence performed all the motion correctly but the time for the probe to move in and back out takes at least 1 second. The problem is not how fast the linear motor can move but the time after it moved in, stopped, and then move out. This seems to be caused by LabView's execution of flat/stack sequence.

I have tried removing the flat sequence and put the subVI in order as follow: movein VI, waitmotion VI, fetchwaveform VI, moveout VI. This made the probe move out in less than 500ms but it wouldnt execute the fetchwaveform VI until the probe has already moved out, making the data is useless. I tried putting the fetchwaveform VI in the same sequence as the movein and waitmotion VI with the moveout VI in the next sequence but this also caused it to take longer than 1s to move out. Using the flat/stack sequence seems to increase latency. 

I have spent days trying to figure out different ways and testing them but they didnt work. Please help if you have any ideas or suggestions.

Thank you,

Max

[MaxXx]

I have attached the VI here.

[Coq_Rouge]

Which labview do you use

[Ben]

I have not looked at the code but this sounds like you are not opening references ahead of time and then using those refs while doing the work. THat one change could help a lot with speed.

Ben

[johnsold]

I would suggest parallel execution of the motion control and the data acquisition.  Arm the acquisition before the motion starts, trigger it when the probe is in position, and read it after the probe has been extracted.

With the speeds and timing you are describing I would not count on being able to do this reliably on a computer with a desktop operating system.  If the OS spends a few milliseconds doing something other than operating the motion controller, you may miss the target.

I recommend that the motion be controlled in  hardware: Send the distance and speed commands to the controller in advance.  Arm the scope.  Send a trigger to the motion controller.  Trigger the scope from a signal from the motion controller hardware when the probe is in position.  Send the reverse speed and direction commands to the controller.  After the minimum time in position, trigger the controller to extract the probe.  Ideally, the controller would have the capability to insert the probe, dwell in position for a preset time, and remove the probe all from a single command/trigger.

If the controller cannot do this,  a real time OS or FPGA may be needed to be sure things will work as fast as you want.

I have no idea how fast .net transactions are, but that may be part of the problem.  Certainly the GPIB transaction with the scope may take more time than you want to allow in that frame.  This is part of the reason I suggested parallel executions above.

Lynn

[Coq_Rouge]

First of all your small stop loop, uses alone 50% of your CPU time (at least on my computer). And it does nothing at all.  Also do you control your scope timing/trigger manually? I can not see you have programmed anything that control those functions. But they do indeed influence on how fast your scope are able to return data. You have not mentioned for how many msec you want to collect data before you are finish.  Your scop buffer can be 500 or 10000 samples . The default value is 10000. I could be that your scop do not return data before the buffer is filled up. Even if you only request 500 bytes. I do think the buffer need to be full before the scop return data. If you only need 500 samples, you should set your buffer to that size. It can shave of some msec on your timing.  

I have made some changes to your main VI. But consider it only as first aid. I have not your measurement setup so I can not debug or test

[MaxXx]

Lynn, Thank you so much for your suggestions. I am fairly new to motion control so can you please provide more information as to where I can get a real time OS or FPGA and what is needed.

Message Edited by MaxXx on 05-28-2009 04:59 PM

[MaxXx]

Thank you Coq rouge for the modification. The oscilloscope is fast and it returns data properly in the time required so it is not the problem. The fetchwaveform VI is what trigger the scope take 500 data points and the default on the scope is set to 500. I will test the VI you have made tomorrow and get back to you.

Thanks

Message Edited by MaxXx on 05-28-2009 04:59 PM

[Coq_Rouge]

After some thinking I do not think you need RT target or FPGA like johnsold suggested, it is somewhat overkill. I think it more about using the scope correct, and take advance of the autonomous behavior the scope has. I my latest example I have used single sequence acquisition. This mean then the scope acquisition is started with the command ":ACQ STATE ON;" it fills the buffer and stop. You just specify the  recording time with the "Time Per Record (4.0e-3 s)" control. Then this operation is started you can forget about the scop and concentrate on pulling the arm out. Then the arm is out out you have all the time in the world for reading data from the scope. So reading 10000 samples is OK. Also programming a scope is not so hard as you may think. You can download the manual here http://www2.tek.com/cmswpt/madetails.lotr?ct=MA&cs=mpm&ci=11148&lc=EN

I would also recommend that you change program layout the next time you do something like this. A state machine is much better. Proper error handling is not possible in your program. I know this is school project, and as soon your program works. You wrap things up put it all in a fancy cover. The final touch is to slap on a Max sticker 😉  

[Coq_Rouge]

---

MaxXx wrote:

Thank you Coq rouge for the modification. The oscilloscope is fast and it returns data properly in the time required so it is not the problem. The fetchwaveform VI is what trigger the scope take 500 data points and the default on the scope is set to 500.

---

Just to correct one thing. The fetchwaveform VI do NOT trigger the scope. In your first program the scope was run continuously or in some trigger mode. What the fetchwaveform VI do is to read data from your current scope buffer. In your first program the acquisition is started with the Initiate Acquisition.VI. This is the equivalent of pressing the front-panel RUN/STOP button. In my example we do the equivalent of pushing the "SIGNLE SEQ" button. This way you have much more control.