New LED function does not work with Blocks 6.2 #114

Activity

1. ItsHarper commented on Mar 12, 2021

   

   ItsHarper

   on Mar 12, 2021

   Member

   More actions

   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.
2. jitto commented on Mar 12, 2021

   

   jitto

   on Mar 12, 2021

   More actions

   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.
3. ItsHarper commented on Mar 23, 2021

   

   ItsHarper

   on Mar 23, 2021

   Member

   More actions

   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.
4. jitto commented on Mar 24, 2021

   

   jitto

   on Mar 24, 2021

   More actions

   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)
   
5. ItsHarper commented on Mar 24, 2021

   

   ItsHarper

   on Mar 24, 2021

   Member

   More actions

   @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.
6. jitto commented on Mar 25, 2021

   

   jitto

   on Mar 25, 2021

   More actions

   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.
7. ItsHarper commented on Mar 25, 2021

   

   ItsHarper

   on Mar 25, 2021

   Last edited by ItsHarper

   Member

   More actions

   @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.
8. ItsHarper commented on Sep 20, 2021

   

   ItsHarper

   on Sep 20, 2021

   Member

   More actions

   7.0 is out with a fixed LED class and blocks.
9. ItsHarper

   closed this as completedon Sep 20, 2021
10. NicholasRHeinz

    added a commit that references this issue on Sep 24, 2023

    Co-locate related components (FIRST-Tech-Challenge#114)

    ...

    31bbf4b
11. ori-coval

    added a commit that references this issue on Aug 14, 2025

    Merge pull request FIRST-Tech-Challenge#114 from FTCLib/feat-new-version

    ...

    1414825