My team does not have the DAQ but we are still interested in testing our software using LabView as a simulator. Is this possible? It looks like the VIs provided all require the dashboard, and the tutorials talk about using the actual joysticks. This is trouble for us because the electrical team has all the sensors and joysticks, etc as they prototype and design the electrical system. This leaves the software team with only a laptop to write software and a copy of LabView.
What do you mean by simulation? If you want to test out your values, just make a variable, p1_y_test or whatever and equate that to the output from your math.
We’d like to run our code (say the autonomous portion) and check for run-time errors. Is it stepping through the code as expected? Are values being reset or set as expected? Will it run at all? We can worry about the proper values (like the distance to the end of the straightaway, or how far to turn) when we test on the actual robot. Since our time on the robot is limited though, we’d like to do all the preliminary bug finding in LabView.
The VIs provided seem to be dependant on the DAQ and dashboard. Am I wrong about this? The description talks about hardware-in-the-loop testing. If I don’t have the hardware (since another part of our team is using it), then I need another way to test the software. One of the NI spokesmen in Atlanta said I should be able to do this, but he didn’t know how. Has anyone ever tried?
To simulate the hardware (e.g. a Gyro) you could have a knob or slider that represents the sensor input. When you hit run in Labview, at the appropriate times you can manually move the knob to simulate the robot’s feedback (e.g. move the knob to the gyro’s equivilant value of -90 degrees to simulate a left turn). I would then recommend setting up a few graphical outputs that show what the motor outputs are.
It will be hard to fine-tune any PID control with this method, but it should at least be able to expose any errors. I’m going to play with Labview tonight for the first time in a few years, so I’ll see if I can give you more details then.
I’m the one who initially designed the LabVIEW simulation toolkit for the IFI system, so maybe I can be of some help here. 
The whole business with needing the DAQ and the Dashboard and all the bells and whistles that came with it was because we didn’t have any kind of access to the software running on the PIC on the IFI system. We were forced to treat the IFI system as a “black box,” with the exception of having the dashboard for SOME semblance of being able to peek at what was going on in there. We couldn’t “fake” data being used on the IFI controller via any natural mechanism, so I was forced to use the USB-DAQ device to generate the “fake” data with LabVIEW to provide to the IFI system. That way we could test code running on the IFI system and provide the necessary “stimulus” that the software/hardware expected, and then we used the Dashboard to give us an idea about what the “result” of the “stimulus” was.
Using the cRIO with LabVIEW (or the C/C++ interface for that matter) is going to be much simpler since we actually have access to the code on the cRIO device. We have the ability to throw breakpoints on the code. We have the ability to single-step through code. And, if you want to, you can easily rig up a simulation “platform” for your code and run your FRC code on your laptop - as long as you provide the necessary inputs/data via front-panel objects (dials, sliders, numeric inputs, boolean buttons, etc…). We’re working with top institutions to provide the best tutorials and documentation we can for this system, targeted to this audience. I think you’ll be pleased.
-Danny