Can NI PCI-7342 support simultaneous PID control and data acquisition?

[A_squared]

I'm interested in the NI PCI-7342 card, but I have a few questions I couldn't find answers to. I'd like to do a PID control (single axis) of a system that may run for a month or more. During that time, we'd like to acquire force and position data, graph it on the screen and write it to a file. We'd like to keep a lot of data for 10 minutes and only a little for the duration in case something breaks so that we can determine what happened. My questions are:
Can we simultaneously have the card doing PID control and acquiring data from analog inputs? If so, do you have an estimated limit to how fast we can poll the card?

A related question but not required is: can we also send the position control signal for the PID loop to the card? It would be nice to be able to tell the system to do non-periodic functions that were sent from the computer. Again, could you estimate the fastest loop rate we could have and still send all the control signals from the computer? A order of magnitude estimate would be fine and we realize that LabView RT is must in this case.

Finally, is there another card that may be better for this configuration and are there any programming examples that may be applicable to this situation?

Thanks in advance for your help and insight!

[Jochen]

1. The 7342 has its own CPU that's running multiple tasks in a time sliced model. One of the time slices is used for host communication. The PID algorithm is running on a seperate DSP. Thus host communication and PID control don't interfere with each other. So the preliminary answer is yes, you can run PID control and data acquisition in parallel.

2. As you need to acquire position and force simultaneously the only way to do this is with only a 7342 in the system is doing a software poll. You should expect a maximum poll rate of about 200 readings per second.
There are some drawbacks here:
a) Jitter. The CPU on the 7342 is running its own cycles that can't be synchronized with the reading cycles of your host system (this won't be improved by LabVIEW RT)
b) Synchronization. You can't make sure that you get the 100% exact correlation between force and position.
c) Accuracy. The ADCs on the 7342 are 12 bit and can't be calibrated. Still you could do a software calibration.

3. I don't understand exactly what you mean with this question:"can we also send the position control signal for the PID loop to the card?.
You can always send commands from the host to the board. This won't affect your reading rate significantly.

4. As you can tell from 2.) I don't think that this hardware setup would be the ideal solution but if the specs I provided meet your requirements just go for it.
If your standards are a bit higher NI can provide much better options for doing the measurements at low cost even without the need of using LabVIEW RT.
Even the cheapest M-Series board, the NI PCI-6220 provides superior accurracy (16 bit, calibratable) and performance (250 kS/s, hardware timed, DMA transfer)as well as direct quadrature encoder connectivity and buffered position measurement modes. I would highly recommend choosing this or a similar board for your measurements. You also can synchronize the two measurements in hardware.

Best regards,

Jochen Klier
National Instruments Germany

[ChadE]

I like Jochen's answer, but I still have some questions.

1. Do you need motion control or just PID?

2. Does your force and position data need to be hardware timed or is software timed ok? I think Jochen covered this question pretty well.

Depending on your answer to the questions above, the solution varies from just a motion control card or a motion control card synchronized with M-Series, to RT and M-Series, to NI SoftMotion Development Module on RT with M-Series.

Just a Motion Control Card can read position and force data (software timed) about 200 per second.

You could synchronize your data acquisition on M-Series with the position of the motion by using breakpoints and RTSI. You may want to switch to a NI 735x board for periodic and buffered breakpoints (NI 734x and 733x have modulus breakpoints where each breakpoint has to be reinitialized in software). Periodic Breakpoints can trigger on periodic positions at speeds up to 4 MHz, Buffered Breakpoints allow for speeds up to 2 KHz with variable distances, Modulus Breakpoints max speed is about 150 Hz (reinitialized in software).

RT and M-Series could be used to do data acquisition and PID if you don't need motion. And if you do need motion, you could add NI SoftMotion Development Module to this solution.

Best Regards,

[A_squared]

I hadn't been looking at the DAQ cards too much. I'll have to do a little research there. PID control should be sufficient and hardware timed position and force measurements will probably be necessary. The other more expensive option I was considering was the PCI FPGA card (NI PCI-7831R). It would handle the PID and could write the force and position data to a buffer that I would read periodically. It has the added advantage of being able to go to much higher loop rates. 500 Hz was the maximum operating frequency I was considering and I understand the DAQ are only good to about 100 Hz. Slightly off-topic question, but is Labview RT required with the NI PCI-7831R? Price and being restricted to integer math are the downsides.

[Jochen]

1. I need to eliminate a misunderstanding. DAQ is capable of acquiring data with a rate up to 10 MHz, depending on the board you choose. The 6220 that I have suggested provides a maximum sampling rate of 250 kHz acquisition rate (block transfer).
If you are talking about the PID rate that could be reached with a DAQ board then 100 Hz might be ok if the application is running on a Windows system. On a LabVIEW RT system you should expect stable PID rates up to 10 kHz (depending on your application).

2. I don't have the feeling that your application requires an FPGA board. But to answer your question: You can run a PCI-7831R in a Windows PC without the need of using LabVIEW RT. The FPGA boards are great for sophisticated high-speed control applications and for custom digital communication but on the other hand I don't see the point why you should use it for your application as it adds a certain degree of complexity as you already mentioned.

So in my opinion you should choose between a combined motion/DAQ setup and a LabVIEW RT system with only DAQ components for control and data acquisition.

You answered Chad's question that you need PID rather than motion control. Please consider the following:

- Do you need to control position, velocity and acceleration/deceleration?
- Is the PID rate provided by the 7342 (up to 8 kHz for two axes) ok for your application?

If this meets your requirements then I would recommend using the motion/DAQ combination which by the way should be the cheapest solution.

- Do you need to be able to define your own control algorithm (beyond PID)?
- Do you need to react on events other than limit switch state changes in real-time?

In this case LabVIEW RT with DAQ components might be the better choice.

Regards,

Jochen Klier
National Instruments Germany

[A_squared]

Thanks for everyone's input. I'm a little confused about your last response. I would love it if the M-series DAQs could support loop rates of even 4kHz, but I read 1 kHz was about the max with Labview RT (http://www.ni.com/support/labview/real-time/faq.htm#pid). Is the possible loop rate higher than what is quoted in this webpage higher because of DAQmx, the M-series DAQs, or faster computers? I did notice that several PXI solutions could reach te required rates, but that would be more expensive than all the other suggested solutions. This is starting as a single axis with hopefully a maximum PID loop rate of 4-5kHz, but in the future multiple channels (<6) may want to be added. Does anyone have a feeling of how much that would affect the maximum loop rate? I was just wondering if the PCI bus communication was the limiting factor, or if processor computation was also limiting performance (3GHz P4 and 512MB 400MHz DDR2 RAM computer). I don't need anything special for the PID control except velocity feed forward, but it would be nice to add the ability to limit force while controlling position (i.e. if the force exceeds some threshold then switch to a force PID loop instead of position). I understand the motion controller probably can't do this. Thanks again. I'm getting a much better understanding of each systems capability that I wasn't about to find in the knowledgebase and other NI areas.

[Jochen]

Yes, the PID loop rate depends very much on the CPU type used and it does not only depend on the clock rate of the CPU but on its architecture(shorter pipelines will yield better PID performance).
PXI solutions should give you much better PID performance than 1 kHz.

PC-based LV RT solutions are a bit tricky as you need special hardware but it could be a viable solution.

With a motion Control boards it's also possible to switch from position control to force control. I have worked with several customers who do this. But I agree that it might not be easy to switch flawlessly from one control type to the other. But on the other hand this will always be a tough issue if you need to do this dynamically - regardless which hardware you use.

Jochen

[Rodj]

The NI-735x motion controllers does support changing feedback on the fly. This is a new feature in the NI-Motion 6.1.5 update. You no longer have to disable the axis to change the feedback source. The only requirement now is that you are not performing a move. I have seen this used successfully in another application.

Also if you are planning to "make" a motion controller with LabVIEW-RT and a DAQ board, consider the NI SoftMotion Development Module for LabVIEW. This module provides you with a trajectory generator, spline engine, and example PID code.

Rodger S.

[NoviceS]

With ref. to Mr. Jochen's reply (message 2 of 8), I want a clarification. Does he mean that NI PCI 6220 alone is enough or should it be used along with the PCI 7342 card.

We have a similar application to be developed. We have to capture torque and also the angle of rotation of the motor. We need to get the data (torque) @ every .5 deg. angle of the motor.  The speeed of the motor will be around 20-40 rpm per second.

Thanks