OPP Lamp Driver Numbering seems to truncate the board number

[unRARed]

We're trying to run a chain of 6 OPP Cypress boards with mpf 0.57.x (both from source and through the package manager) in this project.. We kept running into Duplicate Switch issues such as this one:

Config File Error in light: Duplicate light number <class 'mpf.platforms.opp.opp_incand.OPPIncand'> 16 for light <light.l_spinner_07>

Our lights config is from here. We've tried changing the subtype, adding/dropping the platform: opp, dropping the tags and just about everything we can think of. It seems like the "board" part of the light numbering is being truncated somewhere per print debugging the _check_duplicate_light_numbers method. The game seems to boot as long as the second number is different.

I was able to reproduce with this simple config:

#config_version=6

hardware:
 platform: opp
 driverboards: gen2
 lights: opp

opp:
  baud: 115200
  ports: /dev/cu.usbmodem101

lights:
  l_backbox_match_00:
    subtype: matrix
    number: 0-0
  l_grooveline_lit:
    subtype: matrix
    number: 2-0

Sure enough, we get more or less the same error:

Config File Error in light: Duplicate number <class 'mpf.platforms.opp.opp_incand.OPPIncand'> 0 for light <light.l_grooveline_lit> Context: (None, '0', <class 'mpf.platforms.opp.opp_incand.OPPIncand'>) Error Code: CFE-light-10

Moving the second lamp to number 2-1 boots without issue:

lights:
  l_backbox_match_00:
    subtype: matrix
    number: 0-0
  l_grooveline_lit:
    subtype: matrix
    number: 2-1

Here's the result of our mpf hardware scan

drivers:
Not implemented
---------
opp:
Connected CPUs:
 - Port: /dev/cu.usbmodem101 at 115200 baud. Chain Serial: /dev/cu.usbmodem101
 -> Board: 0x20 Firmware: 0x1000004
 -> Board: 0x21 Firmware: 0x1000004
 -> Board: 0x22 Firmware: 0x1000004
 -> Board: 0x23 Firmware: 0x1000004
 -> Board: 0x24 Firmware: 0x1000004
 -> Board: 0x25 Firmware: 0x1000004

Incand cards:
 - Chain: /dev/cu.usbmodem101 Board: 0x20 Card: 0 Numbers: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]
 - Chain: /dev/cu.usbmodem101 Board: 0x21 Card: 1 Numbers: [16, 17, 18, 19, 20, 21, 22, 23]
 - Chain: /dev/cu.usbmodem101 Board: 0x22 Card: 2 Numbers: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]
 - Chain: /dev/cu.usbmodem101 Board: 0x23 Card: 3 Numbers: [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]
 - Chain: /dev/cu.usbmodem101 Board: 0x24 Card: 4 Numbers: [8, 9, 10, 11, 12, 13, 14, 15]
 - Chain: /dev/cu.usbmodem101 Board: 0x25 Card: 5 Numbers: [8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23]

Input cards:
 - Chain: /dev/cu.usbmodem101 Board: 0x20 Card: 0 Numbers: [24, 25, 26, 27]
 - Chain: /dev/cu.usbmodem101 Board: 0x21 Card: 1 Numbers: [0, 1, 2, 3, 8, 9, 10, 11, 24, 25, 26, 27, 28, 29, 30, 31]
 - Chain: /dev/cu.usbmodem101 Board: 0x22 Card: 2 Numbers: [24, 25, 26, 27, 28, 29, 30, 31]
 - Chain: /dev/cu.usbmodem101 Board: 0x23 Card: 3 Numbers: [0, 1, 2, 3, 24, 25, 26, 27, 28, 29, 30, 31]
 - Chain: /dev/cu.usbmodem101 Board: 0x24 Card: 4 Numbers: [0, 1, 2, 3, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31]
 - Chain: /dev/cu.usbmodem101 Board: 0x25 Card: 5 Numbers: [0, 1, 2, 3, 24, 25, 26, 27, 28, 29, 30, 31]

Solenoid cards:
 - Chain: /dev/cu.usbmodem101 Board: 0x20 Card: 0 Numbers: [12, 13, 14, 15]
 - Chain: /dev/cu.usbmodem101 Board: 0x21 Card: 1 Numbers: [0, 1, 2, 3, 4, 5, 6, 7]
 - Chain: /dev/cu.usbmodem101 Board: 0x23 Card: 3 Numbers: [0, 1, 2, 3]
 - Chain: /dev/cu.usbmodem101 Board: 0x24 Card: 4 Numbers: [0, 1, 2, 3]
 - Chain: /dev/cu.usbmodem101 Board: 0x25 Card: 5 Numbers: [0, 1, 2, 3]

---------
Stop called on serial connection /dev/cu.usbmodem101

[cobra18t]

Could you try assigning a chain number to the port and using the full number to address the lights? Like assign it to chain 0 and then use the number 0-2-16. I am wondering if there is an issue with the shorthand numbering.

I am not as familiar with the PSOC version of OPP and don't have a hardware test setup for it.

[unRARed]

Didn't know how to set the chain(s)? But this boots:

#config_version=6

hardware:
 platform: opp
 driverboards: gen2
 lights: opp

opp:
  baud: 115200
  ports: /dev/cu.usbmodem101
  # chains: ???

lights:
  l_backbox_match_00:
    subtype: matrix
    number: "/dev/cu.usbmodem101-0-0"
  l_grooveline_lit:
    subtype: matrix
    number: "/dev/cu.usbmodem101-2-1"

While this:

...
lights:
  l_backbox_match_00:
    subtype: matrix
    number: "/dev/cu.usbmodem101-0-0"
  l_grooveline_lit:
    subtype: matrix
    number: "/dev/cu.usbmodem101-2-0"

Has the same result:

ConfigFileError: Config File Error in light: Duplicate number <class 'mpf.platforms.opp.opp_incand.OPPIncand'> 0 for light <light.l_grooveline_lit> Context: (None, '0', <class 'mpf.platforms.opp.opp_incand.OPPIncand'>) Error Code: CFE-light-10 (https://missionpinball.org/logs)

So is this just the duplicate light check specific to OPP Cypress?

[unRARed]

Actually, this is probably what you meant? But same result... if the last digit is the same, it thinks it's a dup:

#config_version=6

hardware:
 platform: opp
 driverboards: gen2
 lights: opp

opp:
  baud: 115200
  ports: /dev/cu.usbmodem101
  chains:
    0: /dev/cu.usbmodem101

lights:
  l_backbox_match_00:
    subtype: matrix
    number: 0-0-0
  l_grooveline_lit:
    subtype: matrix
    number: 0-2-0 # throws but number: 0-2-1 works

[cobra18t]

The shorthand is not relevant for the STM32 OPP since each board is it's own chain since it is USB connected. We always use the full 3 element number. That is what I recommend for you as well.

Now to figure out why it is doing this...

[unRARed]

So would you say my last config example above is best practice going forward for OPP numbering (chain-board-number)? With a loop of Cypress boards, the chain would always be static 0? And so each number would be:

0-BOARD_INDEX{0..BOARD_COUNT}-NUMBER_INDEX{0..31}

From looking at the source, I feel like the incand_card is not being considered for OPPIncand when counted in the _check_duplicate_light_numbers method. But makes me wonder how it ever worked? Or did folks mostly use Fadecandy or other light platforms? Or perhaps simply never more than 32 lamps???

[cobra18t]

Yes, that looks like a good practice. Similarly, STM32 users always have the middle number as a 0.

I have never used an Incand card. I have only use neopixels or coil outputs as light drivers. Let me take a look in a couple places and report back.

[unRARed]

I submitted #1868 as a naive first whack at a fix. I don't know the code base well enough to know if this is a good approach or not.

[unRARed]

Similarly, STM32 users always have the middle number as a 0.

Ahhh, that would explain why there wouldn't ever be a dup for that setup then.