• State Verified Answer
  • +1 person also asked this people also asked this
  • Date
    patchyfog
  • Date
  • Replies 7 replies
  • Subscribers 190 subscribers
  • Views 1509 views
  • Users 0 members are here

Configuring a cheap-o DMX relay board on EOS Element

Hello.


I bought a $40 Chinese 8 channel DMX relay board from Aliexpress so we could fire off some practicals in our community theater production. The board works great as an 'intensity" device, and you can patch its 8 DMX addresses to 8 Element channels and the relays will enable when the level gets over 50%. So far, so good.

But, I thought it would be fun fire up the Fixture Editor and create a custom fixture for it, mostly so the "Type" field in Patch wouldn't just say "Dimmer." I had no problem making an 8 attribute custom fixture with an 8 address DMX footprint, but then those address became a "device block" and I couldn't patch each relay individually to its own channel. (Yes, I'm a newbie.)

Soooo....I made a 1 attribute/address custom fixture called "Relay on Relay Board" and I then I could instance up 8 of those and stick 1 on each channel. This works, but only if the type of the attribute is set to "Intens." If I set it to "Relay" (from the "Image" category, I think) it doesn't seem to do anything, even if the allowed values are 0 > 100.

So, I guess I'm asking what is the "ONE TRUE WAY" to set something like this up (and get the nice snapping behavior and type display and maybe even represent the device as a unit with an 8 address footprint, but still be able to control each relay)? I also see there is an attribute type called "Relay Layer" (in "Form" I think) -- that sounds interesting, but I've no idea what it is or why it is different than a simple "Relay."

I mean, what I have (1 channel custom-named fixture with an attribute type of "Intens" and snapping clicked on) works fine and I'm not stuck, but it seems like I'm not being truly mutual with "the EOS way" -- and I'd like to be one of the cool kids.

Thanks!

  • 0

    There is no "The one and only Way". There are always a couple ways (like all ways lead to Rome).

    First of all, i would simply go with and Int-Parameter.
    And if it is ok that you can go with you Value from 0-100 you can use a "NonDim" located under "Generic" in the Fixture-Lib.

    You can also do something with a Dimmer Curve. But thats to much effort in my eyes. 

    If you like to have only the Values 0 and 1, you could edit a NonDim, or simply make a new Fixture.
    In that case enter for the User Values:

    Min 0
    Home 0
    Max 1

    And the DMX Values should be:
    Min 0
    Home 0
    Max 255 (or >=50)

    Hope that will help.

  • 0

    Really if you want them to be patched as seperate channels then patch as dimmers. Then you can patch and operate the relays separately by raising the value over 127 or 50% this is how I use these devices. Works well for me.

    And don't worry about being a newbie. we were all there once in our life. The important thing is learning and having a go which you already are.

    Regards

    Geoff

  • 0 in reply to mathilda

    Thanks for this. A conceptual thing you've given me here is that the fixture model in EOS has a notion of "user values" (what the UI shows) and output/DMX values -- which I knew about. I think I glossed over the user value part.

  • 0 in reply to Geoff Crisp

    Thanks Geoff. My engineering background and anal-retentive aesthetics would just be driven nuts if the "type" field in patch said "Dimmer" instead of "Relay On Relay Board" (or something similar). Plus I feel Patch should be somewhat self-documenting for the operator (which won't be me). Doing a custom fixture also lets me force snap, which seems like a feature.

    I'd still like to understand -- and this whole exercise is one about developing a good mental model of fixture representation in EOS at this point -- why setting the custom fixture type to "Relay" seems to break things and what the custom fixture type setting is really doing for the system, since it seems to have semantic properties the software uses to infer some default behaviors, and presumably some (vaguely specified) operational properties as well.

    Anyway, I'll get to goof with this some more in a couple of days, so maybe I'll have something new to report then.

  • 0 in reply to patchyfog

    Yeah I usually program for myself and once away from patch they are just another fixture with a channel number. You can use the label feature in patch and label it relay.

  • 0

    What i forgot to say is:

    If you use the Int-parameter you can use the Int-Wheel, this big one on the down-right side of the Desk, to bring the Relay to work with ease.

  • +1

    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 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.

Related

www.etcconnect.com