Output expander data to/from pattern code

Is it possible to read the values stored in the output expander config (starts and pin counts per wire) into the pattern code? Or… is it possible to change the output expander settings from pattern code?

I’m building a sync system, where 5 different boxes will be running different lengths and directions of LEDs, but all will play in sync across an entire vehicle. I can custom map it easily, but if I could read that data, I could also detect which box is which. Or, if I could write that data, I could set the output expander via code; then I just have to set the node id of each box, and I won’t have to set up the rest.

Even if it’s possible it’ll take me longer to set up the code and test it than to just write the settings to the boxes, but the me fixing a problem at 4am in a dust storm will REALLY thank me for that piece of work.

Hey @barclander!

Right now, the output expander config is not accessible or settable from pattern code.

I’m struggling to understand how it makes your workflow easier; is the idea that if you need to swap in a spare on-playa, it’d be nice if the pattern code itself was the thing setting the output expander config?

Without understanding more, my initial approach would be to code my patterns around nodeIDs as you mentioned, and download a separate backup archive of each device once I have things working well. The backup archive includes the map and output expander configs, so swapping in a spare would just involve restoring one of my known-good archives.

If there was something really specific about the number of LEDs in each expander channel that I wanted to access in pattern code, I think the approach I would take is to encode the overall output expander config for all 5 nodes in an array that’s in the shared code. For example, let’s say I’ve assigned a nodeId of 0 through 4 to my 5 controllers. Let’s say they’re configured like this:

  • Pixelblaze 1: no output expander, 40 pixels
  • Pixelblaze 2: output expander using one channel of 50 pixels
  • Pixelblaze 3: output expander using 2 channels, 100 and 200 pixels
  • Pixelblaze 4 and 5: output expander using 7 channels, 150 pixels on the first four outputs and 30 on the last three outputs

I might use code like this:

nodeOEChannels = [[40],
                  [50],
                  [100, 200],
                  [150,150,150,150,30,30,30],
                  [150,150,150,150,30,30,30]
                 ]

// Given a nodeId which is also an index into `nodeOEChannels`,
//   and an index for the specific pixel being calculated on this controller,
//   return the 0-indexed channel number on the current controller
function getChannelIdx(nodeId, index) {...}

// Given a nodeId which is also an index into `nodeOEChannels`,
//   and an index for the specific pixel being calculated on this controller,
//   return the number of pixels in the current output expander channel
function getChannelPixelCount(nodeId, index) {...}

I left the implementation of those helper functions to you until I get more clarification that this would help with what you’re trying to do!

Yeah, that’s how I have it now (well, it’s programmatically generating the array based on nodeId and strip lengths, and strip directions, to minimize the number of hard-coded variables, but the end result is the same). The specific length need is for running patterns that loop around the vehicle.

I just generate a pixels[] array once, and then I can do a renderPixel function that holds all the rendering code.

render(index) { 
  renderPixel(pixels[index]);
} 

It’s not too bad to have a quick laminated doc that details the setup for each box.

1 Like