We have 5 quad encoders and 1 sonar using all 12 digital ports. Ports 3/4 are not responding. Debugger shows Sensor Name but says No Sensor. When I plug in two touch sensors into the ports, Touch Sensors work fine.
Is there a problem using all 12 digital ports for encoders and sonar??
@jpearman Yes, ports 4 and 10 cannot be used at the same time for quad encoders and/or sonars. So a practical maximum of 5 devices. (and it's not a ROBOTC issue but a hardware issue).
Have not used but output of sonar on one of the shared port should work right? Doesn't use the interrupt.
@tabor473 Have not used but output of sonar on one of the shared port should work right? Doesn't use the interrupt.
I forget which way around the sonar wiring goes, but you do need adjacent ports for all these sensors so you would need to use 9&10 and I think 9 would be the output.
We are using 4 encoders and 1 sonar, and I have gotten it to work: You must plug them in this configuration:
#pragma config(Sensor, dgtl1, encRF, sensorQuadEncoder)
#pragma config(Sensor, dgtl3, encRB, sensorQuadEncoder)
#pragma config(Sensor, dgtl5, encLB, sensorQuadEncoder)
#pragma config(Sensor, dgtl7, encLF, sensorQuadEncoder)
#pragma config(Sensor, dgtl9, test, sensorTouch)
#pragma config(Sensor, dgtl10, indicatorLED, sensorLEDtoVCC)
#pragma config(Sensor, dgtl11, ultrasonic, sensorSONAR_inch)
and then add this in your preauton:
SensorType[dgtl3] = sensorNone;
SensorType[dgtl3] = sensorQuadEncoder;
@Oedipus Vex We are using 4 encoders and 1 sonar, and I have gotten it to work: You must plug them in this configuration:;
If 10 were not an output you wouldn't need to do the SensorType dance in the code, that's another related issue that I believe is specific to ROBOTC.
We recently (last night) re-discovered this feature as well. Couldn't figure out how best to get all the devices reporting, and actually saw some different behavior in robot C when it was running on a Mac (boot camp) vs a PC.
We are using 5 OSE with 2 LED output ports. We had the LEDs in 9 and 10 and we could not get readings from the OSE in port 3/4 which is a slight variant of the problem James originally described as a hardware feature in the Cortex pin assignments. In the end after much trial and error we discover we can reliably plug an OSE into 1&2, the LED outputs in 3&4 and the additional OSEs in 5-12.
For some time on the mac, we would not see the OSE in 1&2 show up in the debugger, if we tried to define OSEs in 3&4 and 9&10 the same H/W config & S/W test program on the PC resulted in seeing the sensor in the debugger but no data when conflicting ports were defined. not sure why OSE in 1&2 as properly labeled would not appear in the debugger when the code was running on a MaC/bootcamp machine vs native to the PC.
I'm glad we had spare cortexes & PCs, to test with.
@fretless_kb The debugger behavior should be the same using a Mac (with a VM or bootcamp) and PC, I have no idea what was happening there. I can only assume that there was either a version mismatch or something had been changed in the preferences on one of the two machines.
The "bug" in RobotC is that, because digital ports are configured in order starting at port 1, the configuration of port 10 can disrupt the configuration of port 4 if port 10 is an output and port 4 was setup as an input needing to use an interrupt.
We were all puzzled over the differences in debugger output. We'll try to reproduce this and get some more data...
The ports issues make sense. Thanks for explaining that.
Happy New Year!