Motion Control and Motor Drives

cancel
Showing results for 
Search instead for 
Did you mean: 

HSC limitations of the PXI-7344

I have an application where I would like to measure position data (encoder and analog value) from a relatively fast moving mechanism - so want to use the highest sampling rate possible while keeping both measurements synced. I am using the PXI-7344 for motion control and the PXI-6221/PXIe-6361 for analog DAQ.

 

My approach is to use one RTSI line to provide the DAQ sampling clock (possibly divided with a counter for even higher sampling rates with the DAQ card) to the HSC trigger of the PXI-7344. According to the PXI-7344 datasheet, the maximum trigger repetition rate is 1kHz, but the HSC has to be re-enabled in software after every capture. I have a program doing exactly that and it seems to be working fine - but I can't achieve rates on the HSC higher than approx. 150Hz. I assume the bottleneck here is either the host communication (most likely) or the PXI CPU is too slow with re-enabling the HSC (very unlikely - it is a 2.7GHz Quadcore and I am polling the HSC status as fast as possible in a while loop w/o any waits).

My next approach would be to write an onboard program to do the same thing and write the positions into an onboard buffer which I would read after the program is done, but according to the NI-Motion help these programs run inside the RTOS on the onboard µC with a repetition rate of 2ms, which would mean a maximum HSC rate of 500Hz (theoretical).

 

This is of course better than 150Hz, but now I am wondering how I could use the full capabilities of the trigger input of the card (e.g. achieve a HSC rate of 1kHz). Is this even possible/foreseen with the 7344?

0 Kudos
Message 1 of 3
(4,603 Views)

After re-checking the datasheet, I discovered that I apparently made a mistake; the maximum repetitive rate for the trigger input is 100Hz, not 1kHz. But that begs the question how I can achieve rates up to 150Hz then?

 

And my original question is still valid I think: What's the actual limitation of the HSC rate, and where does it come from?

 

Also, just for clarification: HSC stands for High Speed Capture.

0 Kudos
Message 2 of 3
(4,558 Views)

HSC rearming rate is system dependent and affected by many factors. 100 Hz is a rate, that can be achieved on most systems. You might higher rates than that, but that's not guaranteed.

 

Onboard programming typically doesn't result in much better results, as the onboard CPU runs the user programs in a low priority task, which gets interrupted frequently by high priority tasks like limit switch monitoring and so on.

 

In general that's the bottleneck, that explains the limitation. On a 7344 HSC needs to get rearmed after every trigger occurrence in the user program and in both cases (host and onboard programming) the rearming needs to be executed by a low priority process on the onboard CPU.

 

By the way: You are referring to a 2 ms interval. In fact, that's the default value of a time slice assigned to an onboard program. This is not equal with the onboard program's cycle time, which is typically higher - depending on the amount of code and the interrupts caused by higher priority processes.

 

I hope that explains the behavior. For higher HSC rates up to 2 kHz please use a 7350 board.

 

Kind regards,

Jochen Klier

National Instruments

0 Kudos
Message 3 of 3
(4,553 Views)