Configuring a cheap-o DMX relay board on EOS Element

So I played with it some more today and landed on a method I like. I'll document it here for anyone foolish enough to also go down this path.

Creating a multi-cell fixture to represent the board turned out to be the key for me, as that makes one fixture (the board) with 8 cells in it (the relays). The DMX foot print with this setup is auto-allocated and correct and you can't mess up addressing, snapping behavior works, all 8 relays only occupy 1 "main" channel, it shows up sensibly in the "type" field in patch, and thanks to mathilda cluing me to pay attention to "user values," each relay in the UI shows up with a value of 0 or 1 (mapping to DMX data values 0 or 255).

Of course, actually creating such a thing with the fixture editor is a big PITA because we're getting into expert-level stuff and there's no hand-holding, the conceptual model is never clearly explained, and all the jargon forms a closed system of recursive references. However, ETC has put out one hastily-written but incomplete step-by-step tutorial and that, at least, provides the key insight that you need to make a fixture representing your cell FIRST, and then "adopt" and clone that into a SECOND fixture that is your master "container" of the cells. (Exactly backward to my way of thinking, but okay.)

Once I got this, creating the master-fixture board with 8 relay-fixture cells inside was relatively straightforward. Setting the DMX offset of the master container to 0 disables the master's presence in Patch, and the relays are then addressed with dot-notation: C.1, C.2, C.3, C.4, C.5, C.6, C.7, C.8 -- where "C" is the selected channel for the entire board.

As to why setting the fixture to "image -> relay" didn't work for me -- well, I was just being stupid. I'm sure this obvious to everyone but me, but only "Intensity" is a "first-class" parameter --  makes sense; history -- anything else are secondary parameters and so show up in the (too-specifically named) ML tab, or as a direct-access button in the fixture info detail view. If you go into ML you can directly set "Relay" on and off. Duh.

So you do have a choice, you can set all the relay cells to type "Intens" and then you can address them with stuff like:

Chan 41 cell 1 thru 8 @ 01 <ret>

Or, you can set them to Image -> Relay and address them with stuff like:

Chan 41 cell 1 thru 8 Relay 1 <ret>

(Assuming you named your cell-fixture "Relay.") The only problem with this 2nd form is getting "Relay" onto the command line, which can be done with the Direct Access soft button, and there was also some other way by clicking on something in the ML tab I am blanking on now.

I assume the cool kids at ETC can just define fixtures in text files with lots of metadata and import them into the system libraries? That sure sounds easier than fighting the Fixture Editor, but of curse, too much room for user error among us idiot lay people.

So I played with it some more today and landed on a method I like. I'll document it here for anyone foolish enough to also go down this path.

Creating a multi-cell fixture to represent the board turned out to be the key for me, as that makes one fixture (the board) with 8 cells in it (the relays). The DMX foot print with this setup is auto-allocated and correct and you can't mess up addressing, snapping behavior works, all 8 relays only occupy 1 "main" channel, it shows up sensibly in the "type" field in patch, and thanks to mathilda cluing me to pay attention to "user values," each relay in the UI shows up with a value of 0 or 1 (mapping to DMX data values 0 or 255).

Of course, actually creating such a thing with the fixture editor is a big PITA because we're getting into expert-level stuff and there's no hand-holding, the conceptual model is never clearly explained, and all the jargon forms a closed system of recursive references. However, ETC has put out one hastily-written but incomplete step-by-step tutorial and that, at least, provides the key insight that you need to make a fixture representing your cell FIRST, and then "adopt" and clone that into a SECOND fixture that is your master "container" of the cells. (Exactly backward to my way of thinking, but okay.)

Once I got this, creating the master-fixture board with 8 relay-fixture cells inside was relatively straightforward. Setting the DMX offset of the master container to 0 disables the master's presence in Patch, and the relays are then addressed with dot-notation: C.1, C.2, C.3, C.4, C.5, C.6, C.7, C.8 -- where "C" is the selected channel for the entire board.

As to why setting the fixture to "image -> relay" didn't work for me -- well, I was just being stupid. I'm sure this obvious to everyone but me, but only "Intensity" is a "first-class" parameter --  makes sense; history -- anything else are secondary parameters and so show up in the (too-specifically named) ML tab, or as a direct-access button in the fixture info detail view. If you go into ML you can directly set "Relay" on and off. Duh.

So you do have a choice, you can set all the relay cells to type "Intens" and then you can address them with stuff like:

Chan 41 cell 1 thru 8 @ 01 <ret>

Or, you can set them to Image -> Relay and address them with stuff like:

Chan 41 cell 1 thru 8 Relay 1 <ret>

(Assuming you named your cell-fixture "Relay.") The only problem with this 2nd form is getting "Relay" onto the command line, which can be done with the Direct Access soft button, and there was also some other way by clicking on something in the ML tab I am blanking on now.

I assume the cool kids at ETC can just define fixtures in text files with lots of metadata and import them into the system libraries? That sure sounds easier than fighting the Fixture Editor, but of curse, too much room for user error among us idiot lay people.