Trouble with Digital breakout IO PWM

[eatbuckshot]

I also posted this in chiefdelphi but havn't got an answer yet

Its really late, I'm having trouble using anything off of the digital breakout thing

tried to use DigitalOutput DigitalInput on all 14 pins tested setting values to true tested by probing to see if there was anything and attempting to short the signal and gnd... tried to set values for jaguar
i just have no idea what's wrong.

I do notice this in the console everytime i run any program

>>>>Fatal error "Digital module loop timing is not the expected value" in DigitalModu
le() in DigitalModule.cpp at line 56

DIO LoopTiming: 108, expecting: 261

i don't even know where i can find the .cpp i only see .h

[Joe Hershberger]

I do notice this in the console everytime i run any program

>>>>Fatal error "Digital module loop timing is not the expected value"
 in DigitalModule() in DigitalModule.cpp at line 56

DIO LoopTiming: 108, expecting: 261

This error comes from not having the 9403 module plugged into the slot that you are trying to use.

i don't even know where i can find the .cpp i only see .h

You need to get the WPILib source code to look at the .cpp files. Please look at the WPI Software Updates page for the source to the library version you are using. This page and all other software updates are linked from the USFIRST FRC Control System page.

[eatbuckshot]

Ahh, Thank you again Joe. Soon after posting I did stumble across the wpilib src code so I have that already. However I actually a few hours ago did accidently fix the DIO looptiming problem too by reordering the configuration for the slots... It's interesting that you say "the slot I was trying to use", but when I first started getting things running, I didn't have any code creating DigitalOutputs DigitalInputs, or Jaguars .. just printfs and I still got that error..

Other members put together the cRio assuming that slot order doesn't matter. I thought so as well, but I guess not? I thought that each module would be dynamically assigned. It seems I have to have it in the configuration of 1-Analog,2-Analog, 3-nothing,4-dio,5-nothing,6-dio,7-nothing,8-solenoids.

Before this I tried explicity declaring DigitalInputs and Outputs yet, it didn't work. I also tried the constructor that's suppose to automatically use the first dio module. After rearranging EVERYTHING works.

Another thing.. I read in the cpp guide that Digital io and slots are suppose to be 0 based, but testing doesn't say that, will they stay 1-based?

[Joe Hershberger]

Ahh, Thank you again Joe. Soon after posting I did stumble across the wpilib src code so I have that already. However I actually a few hours ago did accidently fix the DIO looptiming problem too by reordering the configuration for the slots... It's interesting that you say "the slot I was trying to use", but when I first started getting things running, I didn't have any code creating DigitalOutputs DigitalInputs, or Jaguars .. just printfs and I still got that error..

If you enable the stack trace, then it will tell you what code is calling the function that generated the error. Every time a function is called, a pointer to the location that did the calling is pushed onto the cal stack so that when the function returns, it will go back to the place it was called from. In the error handler, we added a method for printing out all of those function calls that are on the stack so you can see exactly what path through the code caused the error.

You can enable the stack tracing on errors by calling:

wpi_stackTraceEnable(true);

which is in Utility.h. You can use this in your own code too if you want to. Simply call wpi_assert() with some expression that evaluates to false, and you will get a stack trace, the file name, line number, and function that the assert was called from. You can also cause the function the suspend (like hitting a break point) if you call:

wpi_suspendOnAssertEnabled(true);

Then you can attach to the task and it will be waiting for you to resume it. You probably want to avoid putting this in production code... wouldn't want to hit a breakpoint while you're on the field competing!

Other members put together the cRio assuming that slot order doesn't matter. I thought so as well, but I guess not? I thought that each module would be dynamically assigned. It seems I have to have it in the configuration of 1-Analog,2-Analog, 3-nothing,4-dio,5-nothing,6-dio,7-nothing,8-solenoids.

It absolutely matters which slots they are plugged into. The reason is that there are dedicated wires from the FPGA to each slot. The FPGA is expecting certain modules to be on the other ends of those wires. It is not dynamic. The configuration you listed is correct.

Before this I tried explicity declaring DigitalInputs and Outputs yet, it didn't work. I also tried the constructor that's suppose to automatically use the first dio module. After rearranging EVERYTHING works.

The constructor that selects the first module selects it based on the assumed fixed positions. There is no dynamic module detection going on there. Glad it works for you now.

Another thing.. I read in the cpp guide that Digital io and slots are suppose to be 0 based, but testing doesn't say that, will they stay 1-based?

They will all stay 1 based. What documentation says it is 0 based? We should fix the documentation.

[eatbuckshot]

Let's see I don't remember exactly, but I just checked in the html documentation and some of the pdfs
class_sensor_base.html

bool SensorBase::CheckDigitalChannel ( UINT32 channel ) [static]
Check that the digital channel number is valid. Verify that the channel number is one of the legal channel numbers. Channel numbers are 0-based.


bool SensorBase::CheckRelayChannel ( UINT32 channel ) [static]
Check that the digital channel number is valid. Verify that the channel number is one of the legal channel numbers. Channel numbers are 0-based.


bool SensorBase::CheckPWMChannel ( UINT32 channel ) [static]
Check that the digital channel number is valid. Verify that the channel number is one of the legal channel numbers. Channel numbers are 0-based.

cppref.pdf too I think, not sure if there are any others

Thank you