Jump to content
Vari-Lite Controls Support Forum

Any software DMX-progammers out there?


droiddk

Recommended Posts

Hi 😊

I know this may be (a lot) off-topic, not related to Zero 88, but I guess the coolest lightning-guys visits this forum so I give it a try, I hope it is ok with Zero 88.

I’m a hobby programmer and at the moment I’m working on a small Java DMX-controller, a lot of fun in that. At the moment I’m working on the movement-generator but I could need some advice on how to do the 16bit movement. I think I know how to do it with 8bit but it gets a little bit more complicated when using 16bit (two channels) and doing non-linear movement (like using sine/cosine).

So: Any programmers out there, maybe with some DMX-programming experience that would like to get in contact with me? I imagine some kind of mail-contact. I would love to a have an expert to ask a few questions, not related to Java, but how to approach (maybe specifically the math-part) the general concepts. I will show my ideas and progress so far and tell where I’m stuck.

Kind Regards

droiddk

  • Like 1
Link to comment
Share on other sites

Whats your problem with it? If you calculate the movent you have 0 to 255 for 8 Bit or 0 to 65535. So the easiest way is always to calculate all values for dmx with 16 Bit. And than cut them down to 8 Bit if needed. If your fixture use 16 Bit values you only have to split the 16 Bit Value in MSB and LSB Value so you get two 8 Bit Values and transfer them in the dmx stream.

  • Like 1

I use: Zero 88 FLX S48 / ETC ColorSource 40 / GLP Creation 4096 / Chamsys MQ70 / Madrix

Link to comment
Share on other sites

Hi Erics

Thank you for your reply.

What I do know is that, when working with linear movement it’s easy to do the calculation with 16bit, like this: coarse value = 65.536 / 256 and fine value = 65.536 % 256 and that is working fine, using 16 bit combining two channels. It also works well because when the movement is linear there will also be one full fine movement (0-255) before coarse increments with 1.

For doing movement its better (one reason is the weight of the lamp) to use a sine-wave to generate the movement values, instead of linear-movement (sawtooth) so I use sine and cosine to calculate values from -1 to 1 (using degree 0-360) and calculate the DMX by this: dmxvalue = (sine * 127) + 127 and that is giving me a fine sine-curve, expressed in DMX -values ranging from 0-255.

So, I can do the movement (using sine and cosine) for the coarse channel, but I would like to use the fine channel also, so I can get smooth movements even at low speeds. My problem is that sometimes the coarse DMX -values are like this: 128, 128, 129, 129, 130 with the same DMX -value in a row and the means no fine-movements between those values. Not sure if I’m on the right approach here?

I'm still in the early days here, but when thinking about it, I don't think the "fine" should have the form as a sine-wave, I mean, the "fine" will (if using sine) go very, very, fast, both up and down, and that will mess things up if the "coarse" is still going "up". I guess the correct is that the "fine" will always have the sawtooth-shape -> sawtooth from zero to max when coarse is going up, and sawtooth from max to zero when coarse is going down. Does that makes sense?

How will you do the math/programming when calculating coarse and fine DMX-values for at sine/cosine movement?

Kind Regards

Link to comment
Share on other sites

The fine channel may not display any recognisable pattern, it certainly wouldn't follow the sine wave.

Forget about DMX and binary for a moment and consider this...

Imagine a parameter, increasing linearly by 0.75 per step. It would go 0.75, 1.5, 2.25, 3.00, 3.75 and so on. The whole numbers are going up while the fractions are going down and yet it would still plot an ascending straight line on a graph. The whole numbers are analogous to the coarse byte, the fractions to the fine byte.

As @Erics says above, calculate a 16bit result then output the most significant byte as coarse, the least significant byte as fine.

Couple of other tips...

  1. I may be wrong about this but I think some (most? all?) fixtures ignore some of the least significant bits of the least significant (fine) channel so, even if the fine output value changes by a small amount the fixture will not move.
  2. Most programming languages use signed integers with negative numbers represented in "twos complement". You need unsigned integers so, unless your language has an unsigned integer data type you may have some work to do there. Maybe you should do your calculations in floating point and write functions to convert results to 8bit, 16bit MSB and 16bit LSB.
  3. This will be easier if you use the right language to start with. Some, at least, of a finished project will need to run in real time and it should be capable of multi threading and interrupt handling. Its a bit like a swan, serene and beautiful to look at but paddling like anything under the surface. 😀

Full disclosure... Before retiring I was an analyst programmer for 40 years or so and, while I never attempted the project I have spent time thinking about it. Feel free to DM me, maybe I can help here & there.

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.