If I understand you right, you're running a slower outer control loop to compute a varying setpoint and then you've got an external PID controller that's running a faster loop to lock onto and track your setpoint. Hopefully, such a setup is a little more forgiving of timing variability in your software loop.
As to DAQ hardware, I'd say offhand that one of the PCI-express X-series multifunction boards in a desktop PC would give you quite a lot of varied capability. For better advice, have a conversation with the NI technical sales person assigned to your area. They'll know more details about a broader range of options for you to consider.
With programming care, a desktop plugin DAQ board can probably do pretty well into the low 100's of Hz and kinda sorta ok as you approach 1 kHz. Beyond that, you're increasingly at the mercy of the OS. It always thinks it has lots of other things to do for you and was not designed to parcel out tiny little sub-msec chunks of processer time in a repeatable & reliable way.
It isn't that LabVIEW itself is slow to execute. Simple math loops can run at speeds well into the MHz. When you bring in hardware, the DAQmx driver calls will start costing maybe 10's of microsec, dropping you to a max loop rate in the 10's of kHz. But you'll sometimes get starved out by the OS and find an iteration that takes as much as 10's of millisec.
You'll also likely need some live display, data logging, and other things that will further chew into your realistic looping speeds. In the LabVIEW world, the next step toward reliable control loop timing would be either LabVIEW Real-Time or LabVIEW FPGA. Just realize that each has a distinct additional learning curve even after being proficient with regular LabVIEW.
-Kevin P
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
