You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
New LED function does not work with Blocks 6.2 #114
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 :
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.
Activity
ItsHarper commentedon Mar 12, 2021
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.
jitto commentedon Mar 12, 2021
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.
ItsHarper commentedon Mar 23, 2021
Thanks for calling my attention to that. It's actually not a real problem, since
LEDgot 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 inHardwareFactory. That's when the usage ofmapLED()got deleted, as it was no longer necessary. I'll have the method itself deleted for the future.jitto commentedon Mar 24, 2021
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 :
ItsHarper commentedon Mar 24, 2021
@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 toOUTPUTbelongs. I'll make that change for a future release.jitto commentedon Mar 25, 2021
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.
ItsHarper commentedon Mar 25, 2021
@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.
ItsHarper commentedon Sep 20, 2021
7.0 is out with a fixed LED class and blocks.
Co-locate related components (FIRST-Tech-Challenge#114)
Merge pull request FIRST-Tech-Challenge#114 from FTCLib/feat-new-version