High speed logging of motion control data

[Rob B]

I have a motion control application where I would like to record the various motion control parameter to a file for later analysis.  I have tried calling support, but have not had much luck.  Today I found the advanced motion control VIs and was able to make some progress, but still not quite there.  I don't know if am going about this the best way.  Probably not.

Current application/test is moving a hydraulic cylinder aprox 7inches with a velocity of 50-150 inches/sec.  I have been using the Single Axis Test.flx.vi to control the hydraulic

servo valve.

The problem is I don't know what the system is doing.  I mean the cylinder does move, but that is about all I know.  Would like to know at least the encoder position with time stamps.  The optimum solution would record encoder position, controller target position, controller output, following error, acceleration error, velocity error, deceleration error, and time and all be updated the same as the motion control loop.

Here is what I have:

PXI 7350 motion controller

PXIe-8130 RT controller

LabView 8.5.1

I have been able to read and log the encoder position using the 'Read Encoder Data.vi' inside a timed loop running off the 1MHz clock with a 100us period.

According to the help file 'NI 7350 Timing Information' this VI has a return time of 0.1ms on a 1.47GHz processor, the 8130 has a 2.3GHz dual core processor.  The timing loop is completing in about 100us, but the encoder position value is only being updated about every 5ms or 5000 tick counts.  The test is finished in less then 40ms.

At this point if I can't get it to work I am looking and setting up a second DAQ to record the cylinder position (what the encoder is already doing) and the motion control command signal to the cylinder servo valve.  This seems a little silly to me considering the info is already in the controller.  This still will not tell me if the system is performing as directed.  For example if I command it to accel at 500,000 counts per sec, is it?  Or is it only achieving 250,000?

Any help would be greatly appreciated.

Rob Benjamin

[Jochen]

Rob,

the microcontroller on the 7350 updates the position information every 5 ms and this can't be changed. That means, that you can't get this data at a higher rate with the method that you are using. 

There are two options that might work for you:

1. You could use position capturing (high speed capturing, HSC). The 7350 allows you to capture position data to the onboard memory at a rate of 2 kHz. To be able to use this feature you will need an external 2 kHz clock. Drawbacks of this method are the limited memory on the board (64k) and for your application probably the clock rate limit of 2 kHz.
2. The second option is the one that you have already mentioned. You could use an additional DAQ device like the PCI-6601 or any M-Series board to acquire position data at high hardware clocked rates. As you know the commanded acceleration and velocity values, you could analyze these data and compare them to the theoretical position profile.
   With your PXI system no additional wiring is required. You can route the encoder signals through the PXI trigger lines from the 7350 to the DAQ device.

You are right when you write, that the information that you are looking should be available in the controller. In fact this information resides inside the firmware of the DSP and the FPGA on the board. These devices are very fast, but they don't communicate to the host PC directly but through a microcontroller. This microcontroller runs several high priority tasks, that are directly required for the motion control. Communicating to the host has lower priority, so the speed is limited.

Regards, 

Jochen Klier

National Instruments 

[Rob B]

Jochen,

Thank you for your prompt reply and clarifying what my options are.

Are there any examples for the first option, it is 10X better then the current 5ms.

I have a 6259 that I could use.  Are there any examples that would help me routing the encoder signals from the 7350 to the 6259?

Regards,

Rob Behjamin

[Jochen]

Rob,

for option one please have a look at the Buffered High-Speed Capture.vi which can be found with the Example Finder. In the RTSI.llb you can find several examples that demo several signal routing options. You could combine these examples with the one that I have mentioned before.

There are some more examples on ni.com, that should come even closer to your needs, but for some reason I can't access them at the moment. Please go to http://ni.com/examples and enter motion RTSI as a search string

I hope that helps,

Jochen 

[superfunk]

Sorry to dig this thread up but you mentionned exactly the problem I have :

---

Jochen wrote:

The second option is the one that you have already mentioned. You could use an additional DAQ device like the PCI-6601 or any M-Series board to acquire position data at high hardware clocked rates. As you know the commanded acceleration and velocity values, you could analyze these data and compare them to the theoretical position profile.
With your PXI system no additional wiring is required. You can route the encoder signals through the PXI trigger lines from the 7350 to the DAQ device.

---

I have tried to browse through examples and I only found synchronisation between a motion controller and a DAQ device. But I couldn't read position form encoder with DAQmx. I am actaully using a 7350 and I also have a M-serie card.

I would like to read encoder position with DAQ since I am already using it to read other datas.

Thanks for your help,

Christophe

[Kristoff2]

superfunk,

Please try searching for 'encoder' in the example finder.  You should find several examples regarding reading encoder values.  There are also some community examples that demonstrate reading encoder values such as:

DAQmx Encoder Measurement with Producer Consumer Architecture

https://forums.ni.com/t5/Example-Code/DAQmx-Encoder-Measurement-with-Producer-Consumer-Architecture/...

Buffered Linear Encoder Measuremen

https://forums.ni.com/t5/Example-Code/Linear-Position-Measurement-Using-Counter-Input/ta-p/3506384

Regards,

Sam K

Applications Engineer

National Instruments

www.ni.com/support

[superfunk]

Hi,

Thanks for answer and the valuable examples. I have worked a bit more on encoders and think that there are 3 ways to capture position :

-poll for position in a do-while loop using Capture position.flx which is a simple way but with all the disadvantages that we know. The sample rate is around 100Hz and can vary. I did not attach any examples showing this.

-use High-Speed Capture functions given by Motion. One can synchronize an analog sample clock with HSC but once again the sample rate is limited. I have written a simple VI using this method and I realized that I can't synchronize captures with the analog sample clock. It seems that HSC goes the faster it can, no matter what the sample clock is. For my PXI 7350, it runs aorund 200Hz.

I may route badly the sample clock though : HSC_synch_AI.vi

-forget about Motion and use 100% DAQ. By routing the two phases of the encoder through RTSI, one can aquire positions with an angular encoder given by DAQmx. I also tried to synchronize an analog sample clock with the angular encoder. It looks that solution must use higher frequency (>100kHz) to sample correctly the 2 phases otherwise it won't be correct. We lose all the advantages of counters.

I attach 2 examples of what I did. The difference is the synchornization between the sample clock and the angular encoder : the sample clock can be exported (which works well ) or just declared as the source sample clock (and samples are not correctly acquired).

Examples : DAQ_Synch_Encoder.vi & DAQ_Synch_Encoder2.vi

Thank for your time and answers

Christophe

PS: I cannot run the following VI : DAQmx Encoder Measurement with Producer Consumer Architecture. I always get error -89136 stating that the hardware cannot support the counter clock. It seems that is a solution to correctly aquire an encoder with DAQ given the fact that it uses a counter as sample clock. Which is why I tried to directly acquire positions with RTSI clocks (Counter_Encoder.vi). The acquisition is not continuous, the position is acuqired as soon as the encoder moves and I perfectly have 1024 samples for a revolution.

[IanC_]

Did you follow Jochen's suggestion and have a look at Buffered HSC?  This should allow you to acquire at 2 kHz.

Ian

[christophe.A]

I can't get Buffered HSC to work.I have no capture whatever the encoder does.

On my previous post, I joined a VI (HSC_Synch) showing how I tried to synchronise high speed capture with daq acquisition. It should be a master/slave but the HSC doesn't follow DAQ and runs around 200-400Hz.

I also tried to join the technical support online who gave me an example program which is no more than an angular encoder with an external clock (for my case the PXI ai sample clock). I had already done something similar by exporting ai sample clock to PXI Trig 0 (I think it's the same of RSTI0). By using RTSI, I loose all counter advantages, It seems that encoder signals are sampled before being reconstructed and analysed, and needs very high frequencies.

A high speed capture at 2kHz synchronized with DAQ should be the perfect way to go but I really can't get it to work.

If any NI engineer/fan/motion expert can reply and give me a clue, Thanks in advance!

Christophe

PS: I used my professional account