Vixen 3.0 New E1.31 Output Module

[j1sys]

Now there are two ...

Attached below is a zip file containing a new Vixen 3 E1.31 Output Module v1.0.0.0

This is not related to any other E1.31 Output Module project that may be going on independently.

This is based on our existing E1.31 Plugin for Vixen 2.1 that is being used by 100s (1000s?) around the world.

The file contains E131OutputModule.dll which you should move/save into the Modules\Output directory in your Vixen3 directory tree. That's it. Now it should be available on the list of installed modules and available under the Add Output Controller function like any other output module.

The module supports PolyChrome and MonoChrome command sets with hooks in place for Animation in a future release. I didn't see any properties/editors for animatronics but saw the animation command space defined.

The module currently requires you to set the universe start slot and number of slots for universe outputs. The user much match the start slot and slots to the total amount of data it expects to receive from the sequencer for each controller. We had to do it this way to allow for multiple universe output. We may add the option for it to autosize the universes based the number of outputs as defined in Vixen3 if and only if there is a single universe for output. We have used the multi-universe output for many different features over the last two years with our existing plugin and don't want to give up the flexibility it allows. We understand that flexibility adds complexity. We may add a simple vs advanced setup form that simplifies the setup for common use.

The module can run in one of two modes.

In normal mode each output maps into a slot buffer on a 1-to-1 basis. This allows for a mix of monochrome and polychrome commands. A monochrome command will work on a single slot. A polychrome command will work on that slot plus the next 2.

In RGB mode each output maps into a slot buffer on a 1-to-3 basis. It will currently only respond to polychrome commands. The polychrome command will work on slots 1-3 for output 1, slots 4-6 for output 2, ...

-----------------------

In the examples below all naming is for demonstration/notation purpose. You can name/rename them as you wish. When working with an all RGB we put RGB in the front. When working with a Mono mix we call it Mono and add RGB as a suffix ONLY on the RGB channels.

-----------------------

In RGB mode you can create a controller with the following:

Name: RGB E131
Outputs: 8

Active: CHECKED
Universe: 101
Start Slot: 1
Slots: 24
Interface: Multicast or Unicast
TTL: 1

Assume Each Output Is RGB ...: CHECKED

Then have Vixen create channels to match:

RGB E131-1
RGB E131-2
...
RGB E131-8

Then go into EACH channel and add an RGB property.

Then design your sequence with color and run it ..... That's It.

-------------------

In Normal mode you can create a controller with the following:

Name: Mono E131
Outputs: 48

Active: CHECKED
Universe: 102
Start Slot: 1
Slots: 24
Interface: Multicast or Unicast
TTL: 1

Active: CHECKED
Universe: 103
Start Slot: 25
Slots: 24
Interface: Multicast or Unicast
TTL: 1

Assume Each Output Is RGB ...: NOT Checked

Then have Vixen create channels to match (optional):

Mono E131-1
Mono E131-2
...
Mono E131-48

Then, for example, add new channels for RGB on the first universe. Each channel should include an RGB property and should be patched to the matching starting output on the output controller:

Mono E131-1-RGB, Mono E131[1], RGB
Mono E131-4-RGB, Mono E131[4], RGB
Mono E131-7-RGB, Mono E131[7], RGB
Mono E131-10-RGB, Mono E131[10], RGB
Mono E131-13-RGB, Mono E131[13], RGB
Mono-E131-16-RGB, Mono E131[16], RGB
Mono-E131-19-RGB, Mono E131[19], RGB
Mono-E131-22-RGB, Mono E131[22], RGB

Note that each pixel starts on 1,4,7,10,13,16,19,22 respectively.

Then design your sequence. You can use color on 'Mono E131-xx-RGB' and mono on 'Mono E131-xx' (if you created them) as you wish. I'm not sure what precedence Vixen will apply. Whatever commands they resolve to and send to the controller will be processed in the order sent, both MonoChrome and PolyChrome. We have tested it with color settings followed by individual mono overrides to change the color and they have all worked as expected.

-----------------

There is much more to it. There is a statistics screen and message log to help you/us to track what is going on inside of the module. Play with it for now, kick the tires, and I will try to get a tutorial video soon. If you are unfamiliar with our previous E1.31 plugin you might look at its tutorial video to get a foundation to go forward from. Previous users should find it easy to implement.

Well that's it. Nobody else has seen it or tested it. So YMMV, IMHO, use with caution, don't expect perfection, and all the usual disclaimers. This is v1.0.0.0 and as our understanding of Vixen 3 matures and Vixen 3 matures we expect to make many changes. Some changes may destroy any previous configuration changes and require you to re-enter your output controller configuration for THIS module.

Many thanx to K.C. and the Vixen team for Vixen 3. It has come a long way and has a great future.

MANY, MANY, MANY thanx to ctmal for his tutorial series on writing output modules for Vixen 3. It gave me much insight into the hooks and architecture that saved much development time.

-Ed

[budude]

Thanks Ed! I know what I'm going to be doing this weekend now!

[CaptKirk]

Wow, I think I burned out a few brain cells trying following that description!! This looks great- guess I now need to build my E68x's and cut up some GECE strings...

[j1sys]

Ok, that was fast ....

I received several PMs about a problem. There are several different output modules that I looked at and I overlooked a 'rule'. But upon review, some of them followed one 'rule' some another.

Vixen3 sends the output module a set of commands. If there is nothing to do the command is null. It seemed logical that if there was no command, then there was nothing to do.

However, the current implementation apparently calls for the output module to consider a null command to be a set to level 0 (or color black). I was not doing that. This will cause the module to display the commands it is sent but it will leave the last set of slots as is forever. I thought this was an unusual operation and was going to discuss it with the team ASAP. I got around it in my test sequences by putting a Level=0 / Color=black after each effect.

Attached is an updated output module that follows my new understanding of the 'rule'.

It will require a change to how you implement RGB in a Mono mode. Instead of the pixel being on the first output of the set, it should be on the last output:

Mono E131-3-RGB, Mono E131[3], RGB
Mono E131-6-RGB, Mono E131[6], RGB
Mono E131-9-RGB, Mono E131[9], RGB
Mono E131-12-RGB, Mono E131[12], RGB
Mono E131-15-RGB, Mono E131[15], RGB
Mono-E131-18-RGB, Mono E131[18], RGB
Mono-E131-21-RGB, Mono E131[21], RGB
Mono-E131-24-RGB, Mono E131[24], RGB

Note that each pixel ENDS on 3,6,9,12,15,18,21,24 respectively.

This will only affect you when you are using the RGB in a Mono mode. The "Assume RGB ..." mode still works the same way.

Next?

-Ed

[rokkett]

I just want to jump in quickly and thank Ed and his team for all they have done to enable these newer technologies. His implementation of the Vixen E1.31 protocol is the gold standard and is very well tested and mature. Thankfully, he released his code to the community. I referred to and have read his implementation to get a better understanding of the E1.31 protocol and networking in C#. So get cracking on Vixen 3 and testing out your E1.31 hardware, everyone!

[aussiephil]

Ed

Many thanks for getting this out so us poor people with only some E131 gear can test Vixen3 against some real hardware.

I continue to be excited by Vixen3 and hope that with this well written output module that further work on the sequencer and software continues at full pace without concern about one of the critical required output modules.

As Rockett so well said, this is a Gold Standard and I would fully expect this to become the official E131 module for Vixen3

Again Ed, gratefull thanks for your continued hard work for the christmas lighting community.

Cheers
Phil

[chilloutdocdoc]

Just wanted to say thanks Ed.

Now I can start testing 3.0 against some of my other hardware, (and hopefully channel counts once the dev team gets the performance issues fixed up *nudge*wink*). I'm sure that this software, just like everything else you have written and created will truly set the standard for how things should be done.

Keep up the awesome work you do for the community!

[boarder3]

Is there an easier way to assign channels to rgb i have over 3000 channels?

[boarder3]

Also have some issues with universe 2 what is proper set up for 50 pixels each string 3 strings per universe. Using rgb function. I have start slot1 slots 150 and for universe 2 start slot 151 slots 150. I tried start 1 slots 450 and uni 2 start 151 slots 450 no luck. I have this working fine in vixen 2.1 and lsp Just a little different than both with rgb function

[j1sys]

Boarder3 -

on the easier way ... i don't know, more a question for the vixen 3 gurus. i wondered that myself.

on the universes ... i think i understand: 3 strings of 50 in 2 universes. so 150 pixels per universe. so 450 slots per universe.

Universe 1, start slot=1, slots=450
Universe 2, start slot=451, slots=450

you should set the outputs from vixen to be 300.

all of this assuming you want to run in "Assume RGB" mode.

-Ed

[boarder3]

I got it to work i need to ignore that 451 and start vixen on 300 worked like a charm thanks.

[j1sys]

it may be 'working' but i think you have overlapped universes. 300 pixels will be 900 slots. so 1-450 is universe 1, 451-900 is universe 2. that is start=1, slots=450 and start=451, slots=450.

[lortiz]

Hi Ed,

Thanks for this output module.

I'd like to suggest that you keep the most recent version of the module in the very first post.

Keep up the good and much appreciated work.

Leo

[budude]

+1 on updating first post.

I gave this a try tonight with a fairly small setup - RPM Bridge (DMX) to a Ren64 using the channel LEDs as indicators. Very smooth transitions - looks just great - looking forward to using Vixen 3 more and more!

[aussiephil]

Well I finally got some hardware setup to do some actual testing.

Many Thanks to Ed (j1sys) for this plugin

Setup
Vixen 3 with J1SYS E131 Plugin
160 RGB Channels define
Plugin defined with 480 output slots
One 160 pixel 2801 Flexible strip
1:29 Sequence with audio

Here's the video to prove it all works..... :)

http://vimeo.com/36180172

Now to do the behind the scenes How-to on the actual setup and sequence

Cheers
Phil

[Shockwave]

It is working on my Vixen 3 beta and I am able to see the traffic on the dev unit.

I'm also noticing that when you press Stop, the music and graphics halt, but the data coming out the ethernet continues on until the end of the data in the sequence. I'm not sure if that's the DLL or Vixen 3 error.

I also wonder where to report bugs to the community. I'm eager to help get this working right since the power it'll give us is phenomenal. Do we have a bug reporting section of the forum for this latest version of Vixen and all associated plugins?

[j1sys]

The plugin is getting data pushed to it. it is called every 'x' milliseconds by the sequencer. we don't create any data, just transmit it.

Currently, it appears, that the sequencer calls the output all the time, even when we think of it as idle. I expect some of the issues you are seeing could be related to that. Are you saying the the sequenced data are continuing to appear? or just some empty transmissions.

This plugin was a first attempt to follow our understandings of the output 'rules' from Vixen 3.0 based on information disclosed so far. I expect some changes/fixes/updates to the rules in the next release. But have no inside information to base that on. I am on the outside gleaning information as well are the users.

-Ed

[Shockwave]

Yes, actual sequence data is being thrown to my MCUs. When the 22 seconds test chase finishes, the data stops arriving at the MCU. Your data matches mine -- Vixen3 continues to sequence even when you press stop. I suspect the same problem will exist for others with other output plugins in the future too.

BTW: Thank you for these sACN dlls. I'm having a blast with them and they allow me to integrate Vixen and music into my existing stand-alone homebrew system with ease. Thanks a lot.

[Materdaddy]

I also wonder where to report bugs to the community. I'm eager to help get this working right since the power it'll give us is phenomenal. Do we have a bug reporting section of the forum for this latest version of Vixen and all associated plugins?

Vixen bugs go to http://bugs.vixenlights.com/
I believe they do NOT want plugin bugs there, only bugs for Vixen 3.0 itself.

[Shockwave]

POST DELETED BY POSTER

reason: symptoms caused by test configuration

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