Team 39, 2008 LabVIEW Beta Code

[Kevin Sevcik]

Originally Posted by Joe Ross

It is the rate at which the driver station sends data. That should be raised to 40hz soon (same as IFI). I have not seen any recommendations as to a maximum.

Ah. Good to know, then. One more followup while I'm on my lunch break. Is it possible to run separate loops at higher rates for improving PID control? For example, with the IFI RC, you could set up the "fast loop" to update some of the PWM outputs at whatever speed you liked. Given that the Victors can theoretically handle update rates of 120Hz, I'd dislike having to throttle them to whatever the update rate of the DS is.

[BornaE]

Originally Posted by Kevin Sevcik

Ah. Good to know, then. One more followup while I'm on my lunch break. Is it possible to run separate loops at higher rates for improving PID control? For example, with the IFI RC, you could set up the "fast loop" to update some of the PWM outputs at whatever speed you liked. Given that the Victors can theoretically handle update rates of 120Hz, I'd dislike having to throttle them to whatever the update rate of the DS is.

Yes, you can run other loops simultaneously at different rates.
Also a new Driver Station update was released today that changed the update rate to approximately 50Hz
you can also run this loop faster, it is best if the loop OS run at a multiple of DS update rate. eg. 100Hz - 200Hz and make sure your processor doesnt run out of time.

[Greg McKaskle]

Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.

Greg McKaskle

[Joe Hershberger]

Originally Posted by Kevin Sevcik

Tom,
I'm a little concerned that I don't see any DaqMX tasks in this code. I realize it's slightly advanced stuff, but it's important slightly advanced stuff. You can set up hardware timed data sampling tasks that run at much higher frequencies than your background processing tasks, as well as setting up custom scales and all sorts of other things. Hopefully it's just that beta teams haven't gotten around to looking at that sort of thing yet, as opposed to it not being an option.

The FPGA is implemented to execute hardware timed analog acquisitions in the background. You can specify different sample rates for each module (which is more flexible than DAQmx) so that you can better tailor the measurement to the sensors connected to that module. In addition, there are hardware accumulators (DAQmx doesn't have them), oversampling / averaging engine (DAQmx doesn't have it), 8 analog triggers (DAQ boards usually have 0 to 2) and the triggers support rollover detection (DAQ triggers don't)... the list goes on and on.

Custom scales are implemented by you wrapping the GetVoltage VI with the calculations you want for your scale. The voltage values that are returned to you are scaled with factory calibration constants stored for each channel on each module during manufacturing.

Originally Posted by Greg McKaskle

Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.

The goal was to create an API that, while not as general purpose as DAQmx, provides more of the features that teams will need to excel. I hope you find that to be true. Oddly enough, for my day job I'm a driver developer for DAQmx.

[BornaE]

New Revision posted here: http://hhsrobotics.org/forums/viewto...f=4&t=3&p=6#p6

[Greg McKaskle]

It looks like you have lots of things hooked up and working. I don't see any timing in your BIG loop with all of your dig I/O stuff. That of course means it runs all out in parallel with everything else. If you can determine a time for it to run based on response, that will likely help with the responsiveness of the other loops.

My guess is that you can put a Wait of 20ms, similar to the camera loop. If that seems too slow, lower the number.

Greg McKaskle

[BornaE]

Originally Posted by Greg McKaskle

It looks like you have lots of things hooked up and working. I don't see any timing in your BIG loop with all of your dig I/O stuff. That of course means it runs all out in parallel with everything else. If you can determine a time for it to run based on response, that will likely help with the responsiveness of the other loops.

My guess is that you can put a Wait of 20ms, similar to the camera loop. If that seems too slow, lower the number.

Greg McKaskle

Oops, I forgot to put that in there.
I was using a Timed loop before that but since that was not provided with the default FRC labview, i switched it to a while loop.