Compact rio not being able to use C

[BradAMiller]

Originally Posted by rwood359

Please lobby for the have-nots. Some dialog can start as soon as we have the documentation and tools. Getting some things cleared up now may reduce your work load when everyone gets the full system.

Everyone on the project is 100% behind that goal. We hope to make it available as soon as possible.

This sounds like fun! I have some concerns about breakpoints and motors. Are breakpoints tied into the FPGA to pause PWMs?

This particular issue caused lots of discussion. Sometimes it's desirable to have the motors running while debugging and the robot is up on blocks. Other times it isn't, and possibly dangerous.

We implemented a user watchdog timer that is enabled by default (but can be disabled) and will automatically stop the motors if your program doesn't periodically call a method. If used, it would shut down the motors on a breakpoint. But like seat belts, if you don't use them you can get in trouble. And this gets even more complicated by the fact that multiple tasks can be running - but you can set the debugger to interrupt all running tasks on a breakpoint as an option.

There is also a system level code that will shutdown the motors in the event of a communications failure, disable or e-stop.

Thanks for the information on the gyros. My real question is about the level of documentation of the FPGA that is sitting between the code and the devices. One of your earlier posts in this thread described both specific device interfaces and generalized tools to build an interface. How detailed as to timing and timing constraints will the documentation be?
For example, in your response above, you described the functionality of the gyro driver without giving any data rates. Will the functional document have the data rates for the sampling and such? You don't need to give details here.

I wouldn't expect to see documentation on the FPGA interfaces, not because we're keeping secrets from people, we're just out of time. You can look at the code to understand what's going on.

We are trying to document as much of the specs as possible, like data acquisition rates and subsystem block diagrams. And you can always ask questions.

[Dave Flowerday]

Originally Posted by BradAMiller

We implemented a user watchdog timer that is enabled by default (but can be disabled) and will automatically stop the motors if your program doesn't periodically call a method.

Brad,
Isn't a hardware watchdog being used? If the processor completely locks up, does PWM generation stop, or does the PWM hardware continue to run with the last value given?

How can the system be considered absolutely safe if it is still possible for the motors to run while user processes are stopped at a breakpoint (I assume the processor is still running since I presume that a run-mode debugger is being used)? With the IFI system, if the user processor stopped updating the master for any reason the motors were shut down. Personally I think this is the only safe way to implement a "robot disable" function.

I guess I'm trying to find out how the "robot disable" function is actually implemented in the new system. I.e. what hardware is generating the PWM signal, and what conditions cause that hardware to stop generating and therefore shut down the motors? Is that hardware being updated by some sort of system (non-user modifiable) task?

[Roboj]

Originally Posted by Dave Flowerday

Brad,
I guess I'm trying to find out how the "robot disable" function is actually implemented in the new system. I.e. what hardware is generating the PWM signal, and what conditions cause that hardware to stop generating and therefore shut down the motors? Is that hardware being updated by some sort of system (non-user modifiable) task?

Hi Dave,
The watchdog is implemented in the FPGA. Therefore, it is a non-modifiable and non-crashable task. If the watchdog isn't strobed at a minimum rate, the I/O (which is also controlled by the FPGA) will go to safe mode. Therefore, PWMs are set to the proper value to halt the motors. As mentioned in Brad's message, there are ways that the strobing of the watchdog can continue to run while debugging if that is desired. As Brad mentioned, there are some disadvantages/hazards to allowing this also.

Besides not wanting to throw too much technology at the participants at once, this is another reason we aren't allowing you to re-program the FPGA this year. We can't risk teams accidentally disabling the safety features until there are some features added to LabVIEW FPGA to let you do this safely.