New LED function does not work with Blocks 6.2
tjhawkey opened this issue · 8 comments
There's a new Rev LED and corresponding function in blocks 6.2. Problem is -- it doesn't work.
The cable and LEDs themselves are fine and they work fine when defined as digital devices.
REV folks confirmed.
The LED function in Blocks actually isn't new, or specifically designed for this new hardware. I'd have to look up details on why it doesn't work for the new device, but it's not 100% shocking that it doesn't.
Looking at 6.2, com.qualcomm.hardware.HardwareFactory.mapLED function is not called from mapDigitalDevice or anywhere else. Seems to be a functionality not fully implemented.
Looking at 6.2, com.qualcomm.hardware.HardwareFactory.mapLED function is not called from mapDigitalDevice or anywhere else. Seems to be a functionality not fully implemented.
Thanks for calling my attention to that. It's actually not a real problem, since LED got converted to an annotation-defined device type instead of a hard-coded one a few years ago so that it no longer needed special-cased code in HardwareFactory. That's when the usage of mapLED() got deleted, as it was no longer necessary. I'll have the method itself deleted for the future.
Another possible source of problem - LED constructor calls setDigitalChannelMode to set to OUTPUT mode, but init op mode resets all digital channels to INPUT - causing LED.enable to do nothing (LynxDigitalChannelController.setDigitalChannelState checks mode == OUTPUT before sending output command). Stacktrace below shows where all digital channels gets reset to INPUT :
internalSetDigitalChannelMode:180, LynxDigitalChannelController (com.qualcomm.hardware.lynx)
initializeHardware:99, LynxDigitalChannelController (com.qualcomm.hardware.lynx)
resetDeviceConfigurationForOpMode:203, LynxController (com.qualcomm.hardware.lynx)
resetHardwareForOpMode:381, OpModeManagerImpl (org.firstinspires.ftc.robotcore.internal.opmode)
runActiveOpMode:347, OpModeManagerImpl (org.firstinspires.ftc.robotcore.internal.opmode)
@jitto Great catch! I think that's our issue.
The LED class actually dates way back to the very first release of the Robot Controller in 2015, and there was no resetDeviceConfigurationForOpMode() method until 2016, which is where the line that sets the mode to OUTPUT belongs. I'll make that change for a future release.
I believe there is also an order problem. LynxController.resetDeviceConfigurationForOpMode gets called after LED.resetDeviceConfigurationForOpMode when I did a local debug. If there is a way to change the order, I do not see it yet.
@jitto Dang, you're really on top of it. I discovered that as well (inconsistently), and implemented a fix, so that all LynxController subclasses get reset first.
7.0 is out with a fixed LED class and blocks.