Vixen 3.0 New E1.31 Output Module

[cessnapilot]

I have the E680 and have noticed that if the E1.31 controller is activated in vixen then I get constant data to the E680 controller. You can stop the data stream by stopping the execution engine in vixen.

This also happens with the open dmx output plugin. And what I have noticed is that the dmx module I have hooked up with this plugin doesn't go through its test sequence.

So I think vixen3 is sending an "all off" data stream when a sequence is not running.

[j1sys]

currently it appears that vixen 3.0 calls the output plugin constantly. most of the idle calls include 'null' commands. in my first implementation i assumed that 'null' commands should be ignored (logical to me). however, at the end of an effect, for example a simple setlevel for 1 second, vixen does not send a 'reset' to black but does start sending 'null' commands. to conform with the accepted norm i was advised to implement all 'null' commands as set to zero. currently i do just that AND send ALL data out the E1.31.

You can safely run the initial release to see the difference in the data bandwidth but will see that effects live on forever until a new effect is encountered. I played with adding a simple setlevel=0%/black effect after each effect in the sequence and it looked the same but was tedious to always place the 'stopper' after each effect.

to help relieve the data stream i intend to add an optional tuneably tracking of the data stream with 'tell me X times' and interval keep-alive that will filter out extraneous data transmission.

i believe this may be addressed by the vixen team in near future releases based on discussions with other output module developers. but that is just my opinion and not based on any communication from them.

Ed

[Shockwave]

Would it be possible to implement the following pseudocode?

new timeslice
clear buffer
clear flag
on command received,
---write commanded data to spots in buffer
---set flag
upon finish command,
--- if flag is set
------write buffer to IP address

This way, spots with no commands for them will be black (off). And when no commands arrive, the flag isn't set and data doesn't get written out to the ethernet. I find it odd that this has to be handled in the DLL rather in the renderer, since everyone running every other sort of interface is going to have the same hung-data problem we have with sACN. It would be better if Vixen handled the render to a buffer and then passed a pointer to the buffer, allowing the plugin folks to worry more about interfacing to their hardware than rendering (which to my mind needs to be in Vixen if for no other reason than to guarantee the identical output regardless of what plugin you use).

[j1sys]

i've already got a procedure that will work. it just builds a new buffer, compares to old, if same for 'x' times it stops sending for 'y' seconds and then resends burst of 'x' times again. we uses this same logic in some of our other software/hardware. This in in line with E1.31/DMX guidelines where you should retransmit several times in case of data loss and then can back off. then some hardware needs a keep-alive once every so often or it's defined rules could declare loss of traffic and shutdown the lights for safety.

i agree it shouldn't be the output modules decision. i think it is a 'snafu' that is currently being addressed. but that's why this is called a beta.

-Ed

[sallz0r]

i believe this may be addressed by the vixen team in near future releases based on discussions with other output module developers. but that is just my opinion and not based on any communication from them.

Sorry, can you clarify the problem? The execuition engine simply gives the output module the current state of all its channels; its up to the module to decide what to do with them. If there shouldn't be anything happening for a channel, it simply gets NULL.

I'm not sure if there are any changes planned that relate to that flow.

[Shockwave]

BTW: disregard the fault I was talking about. I took out my debug dump and the error went away. It was caused by a blocking serial function in my RTOS.

[StandingInAwe85]

Just curious if anyone has gotten this to work with the latest release of Vixen 3 (I think it's 3.0.2.2). It doesn't show up as a controller type for me after putting in the dll file.

[sallz0r]

Just curious if anyone has gotten this to work with the latest release of Vixen 3 (I think it's 3.0.2.2). It doesn't show up as a controller type for me after putting in the dll file.

The one downloaded from this thread isn't going to be compatible with the latest versions; earlier this year, fairly major components of the framework involving the way data is moved to controllers was changed. So it's probably not even going to be loaded properly.

There is some code in the public repo for an E1.31 module, however I don't think anyone's gotten it working yet. If you know of any devs that have the hardware (or are familar with it, at least!) please let us know! That's the one weak spot we have -- we can't test/develop all the controllers, since we don't have the hardware. :-(

[StandingInAwe85]

The one downloaded from this thread isn't going to be compatible with the latest versions; earlier this year, fairly major components of the framework involving the way data is moved to controllers was changed. So it's probably not even going to be loaded properly.

There is some code in the public repo for an E1.31 module, however I don't think anyone's gotten it working yet. If you know of any devs that have the hardware (or are familar with it, at least!) please let us know! That's the one weak spot we have -- we can't test/develop all the controllers, since we don't have the hardware. :-(

Yeah, I saw the other thread talking about it (under the how-do-I) right after posting. I tried out the one there and had the same problem with my network card not showing up in the list... I'm by no means a developer (despite working as a server\network admin) though I do have a basic understanding... and my show is running 100% E1.31 devices this year (2 pixel controllers and a couple of RPM's DMX bridges) so I'd be willing to test. Maybe I'll take a look at the code and see if I can spot something with this.

Is this the right spot for the most current code? https://github.com/sall/vixen-module...s/Output/E1.31

[sallz0r]

Yeah, I saw the other thread talking about it (under the how-do-I) right after posting. I tried out the one there and had the same problem with my network card not showing up in the list... I'm by no means a developer (despite working as a server\network admin) though I do have a basic understanding... and my show is running 100% E1.31 devices this year (2 pixel controllers and a couple of RPM's DMX bridges) so I'd be willing to test. Maybe I'll take a look at the code and see if I can spot something with this.

Is this the right spot for the most current code? https://github.com/sall/vixen-module...s/Output/E1.31

Hey, that would be fantastic! thanks for that!

Yep, that's the module that we have in the repo. I'm not 100% sure what it is -- I've never looked at it myself, and I'm not sure who imported it originally -- but I *think* it's just a direct port of J1sys's module for v2, with a few changes to try and get it working in the Vixen beta of yesteryear. So there will probably also need to be some changes to get it working with the updated data flow models, I'm not sure.

(Note that I don't think this is the same module that j1sys posted above: I don't think we have the source for that. It would be great it would could amalgamate them, or ditch ours and get j1sys's into the repo if it's better, etc.)

Feel free to follow up (via PM or a new thread, or here) if you want a hand with figuring out how the output modules work, and any other v3-specific stuff. You can always look at the other modules (renard, the dummy lighting controller, etc.) to get a feel for how they work as well.