droiddk Posted February 18, 2023 Report Posted February 18, 2023 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 1 Quote
Erics Posted February 20, 2023 Report Posted February 20, 2023 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. 1 Quote I use: Zero 88 FLX S48 / ETC ColorSource 40 / GLP Creation 4096 / Chamsys MQ70 / Madrix
droiddk Posted February 20, 2023 Author Report Posted February 20, 2023 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 Quote
Davidmk Posted February 21, 2023 Report Posted February 21, 2023 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... 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. 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. 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.  1 Quote
droiddk Posted February 21, 2023 Author Report Posted February 21, 2023 @Erics & @Davidmk Thank you for your input. I think I got it, roughly  Kind Regards  Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.