Eric,
Encoder signals: your board has 2 counters and both can interface directly to a quadrature encoder. The "measurement" you get can be a signed quadrature position, including scaling into physical units like mm, rad, deg, or whatever.
PWM: your board can use a counter to generate a PWM signal. It's possible to load in a new set of freq & duty cycle parameters on the fly to change the duty cycle without interruption of the pulse train.
The rest of this post is kind of an early warning. You've got some weeks of learning basics about LabVIEW syntax and DAQ programming before these things would be an obstacle. But they'll probably be rearing their heads eventually.
Problem: Your board only has a total of 2 counters. If you use them for the 2 encoders, you can't also generate PWM. Maybe part of the project is for you to design and build some interface circuitry. I think you'll be best off if you use the counters of the 6229 for the encoder measurements and find another way to generate your control signal. Analog output seems natural if that's allowed.
Other problem: this is supposed to be a real-time control system. Unless you're using LabVIEW Real-Time, you'll be running under Windows. So your control loop will *not* always run at a constant rate, and is at risk of becoming unstable as a result.
Personal experience: I had a motion system designed for LabVIEW real-time that needed to track a smooth periodic signal (not exactly a sinusoid, but not too far off). The device moved about 3-4 feet on a linear track at a 1-2 Hz rate. Under LabVIEW RT, it controlled nicely with a 500 Hz control loop rate. When I tried running the same program under standard LabVIEW in Windows, the motion would become erratic -- smooth for a while, then a hesitation and an extreme adjustment. I doubt it could have kept an inverted pendulum from falling.
I didn't need or try to optimize it for running under Windows so I suspect there were ways to improve it significantly. But there'd probably always be a risk of the motion going erratic or unstable at any time. At a minimum you'd want to close other applications, keep your actual control loop in a high priority thread, and put your user interface (inputs, display) in a separate thread.
There's a bunch of info on threads, priorities, and execution systems here on ni.com when you are far enough along to need it, but that'll probably be a few weeks.
Good luck with the project. You'll be able to find quite a bit of info by searching both the forums and the official support resources here on ni.com, then posting specific questions you can't find answers for.
-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.
