Maintain DMX Values when Re-Opened?

[RyanSever]

Would it be possible to add the functionality where the device would maintain it's dmx values if the device were to be closed then reopened?

I've noticed that the blackout command will remain either on or off if I have one application set it, then close the device and then another app open it; however, each time the device is opened, all the channels are reset to 0.

I am wondering if a feature could be added where the device would not reset its values to 0 (for instance, if the program or computer crashed - and you just wanted to resume a show from where you left off without everything going black).

In addition, it would be nice to have a function that would return the current value of a DMX channel the device is outputting, so that if a program were to open the device and the device had channels set still, the program could read the values the device has to update its copy of the DMX universe.

A way I could see this working without breaking any existing code is as follows:

1. add a function to return the value of a set channel
2. add a function that specifies whether or not the device should reset to 0 when opened.
3. add a function to return the value of the variable set by #2

The first time the device is opened, all of the channels would be set to 0 - and as such, the default value of #2 is false.

an application could set #2 to true if they wanted to maintain the channel data across sessions - and the device would check this variable each time it is opened to determine whether or not to set all chans to 0.

if an application opens a device, it may check #3 to determine whether or not it should run through #1 to get the values of the currently set channels.

this approach should not break existing code, as nothing would change except the addition of functions.

also, I would recommend the blackout routines be incorporated into this as well (preserve from session to session) as they currently behave differently than channel values.

[RyanSever]

To clarify, this "session to session" behavior would only apply to the unit while it is being powered by the USB bus. if the computer were to shut down or the device were to be unplugged from USB, it would reset to defaults (ie. set channels to 0).

This is mainly useful for preserving the state of the universe between applications or if an application were to crash.

Right now, if the device is outputting a universe of DMX and it is closed (without the channels being set to 0 or a blackout on command being issued) it will continue outputting the values until it is opened again - when it will reset them to 0.

sometimes I do not want everything reset to 0 when opened, but to continue where I left off - with maybe 200 channels set.

[ben.suffolk]

Hi Ryan,

Thanks for the ideas. The way it works at the moment is that the values are actually only zeroed when you enable TX. So if from your software you don't enable TX on the second time round then you would not actually zero all the channels.

However a new function would be of benefit to tell you if TX is enabled or not (so that your software does not need to enable it and thus zero all the channels if its already enabled, but you could if you wanted to zero all the channels enable it again as you do now).

I also think your idea of being able to query each channel number to see what its current value is would be a good idea, so the software can sync with it. I'll look into implementing these as soon as I have a spare moment or two.

Regards

Ben

[RyanSever]

Awesome, thanks for the info

[ben.suffolk]

Ryan,

New version released, please see the release notes in the Building forum.

Regards

Ben

[RyanSever]

Wow! Thanks for the quick update! I've implemented these new features into my application and everything works great!

However, when I go back through my code, I can't help but to wonder if these features would also be possible:

View Tx FPS (so that you could see the actual rate of outgoing DMX data)
Set Target Tx FPS (as I saw that you created a special "slower" firmware for someone with incompatible hardware, it may be nice if it were a feature for everyone)

Other than Tx rate, this has everything I could ever want in DMX widget! =)

the Tx rate isn't at all critical, but it would be nice to see how much of a speed increase you get when you limit the number of channels transmitted - and also be able to limit the speed for hardware that may not be able to support full speed DMX.

thanks again for the new features!

[MSwan]

Ryan,
this is from the current firmware and has been there since at least 1.2 if not 1.0 (easy to miss though since its name is different).

2.3.7 Set the last TX code - 0x4E
This is a 2 byte command, the first being 0x4E / 4F (High address bit), <low>. You should set
this as low as you need it because the lower this is, the less data that needs to be sent, and therefor
the more frames per second (refreshes) you can achieve.
Response: 0xCE

There isn't any way to see what the Tx FPS is right now but you can set how many chhannels you Tx.

[RyanSever]

I have both seen and implemented this command, I'm just interested in monitoring the status of the actual DMX output to see the "real" rate of transmission.

I like my applications to run as fast as possible, but the "max" speed of DMX is between 40 and 44 FPS. This means that it would be silly for my application to send more than 40-44 updates per second to the device..

For instance, if I am fading a channel from 0 to 255 over a period of 2 seconds, I only need to send between 80-88 updates to the device, instead of the actual 255 since DMX speed will only allow 40-44 FPS anyway.

To make my application more responsive, put less strain on my CPU, and just optimize I/O of the device, it works well to buffer the current channel values in my application, then send periodic updates to the interface if they change (ie/ every 25ms = 40fps), instead of sending an update every time a value is changed.

Using this method, I can "control" the FPS of my application->device, but only if I want it to update less frequently to conserve processing power or something.

It would be nice to know the actual speed that the device is transmitting the DMX, so if the device were only transmitting at 30fps, I only have to send an update every 33ms instead of every 25ms. While 8ms may not seem like a big deal, when applications get to the point where they're doing a bunch of stuff at once, it's nice to conserve as much processing power as possible.

The addition of a "Set Target Tx FPS" command isn't really necessary, but since the 2.4 firmware was a slowed down version for incompatible fixtures, I don't think it would be too much work to add in, just in case someone else were to encounter the same problem. Even if this were something like "Number of ms to delay", it would still work well if you could also see the real Tx rate of DMX from the device as the application could automatically adjust the number of ms to get close to the target frame rate (as opposed to the DMX device doing this internally).

I love this device, and the addition of these features aren't really necessary; they would just be a nice addition to some already complex software applications.