E1.31 Output Priority

[nedmech]

I'm looking at implementing a tiered control setup with QLC+ as my primary controller, a hardware DMX console as a backup controller, and an architectural DMX control panel (fixed installation) as the default control when the others are off. Basically, the architectural control panel controls the house lights until the controller or QLC+ start sending a signal. When QLC+ is running, it takes full control. When QLC+ is shut down, the hardware controller can be used instead.

I know I can implement this with OLA, but that requires a computer (at least a Raspberry Pi) running OLA to be on all the time for the lights to work. I was hoping to be able to assign a priority level to the E1.31 output from QLC+ so it would automatically take over from the other sources. I'm looking at implementing this with a DMXKing eDMX4 RDM, and it should automatically handle the E1.31 stream priorities. I'm just not finding where I can set the E1.31 output priority from QLC+. Has this not been implemented yet, or is it just hidden really well?

[mcallegari]

Hi, what is "E1.31 output priority" ?
Can you point me to the E1.31 specifications where they talk about this ?

[nedmech]

It's in section 6: "E1.31 Framing Layer Protocol", specifically:

6.4 Priority
A receiver conforming to this standard may receive data for the same universe from multiple sources that
may be distinguished by examining the CID in the packet. (This is a situation that cannot occur in
conventional DMX systems.)
The Priority field is an unsigned one octet field. The value is used by receivers in selecting between
multiple sources of data for a given universe number. Sources that do not support variable priority shall
transmit a priority of 100. No priority outside the range of 0 to 200 shall be transmitted on the network.
Priority increases with numerical value, i.e., 200 is a higher priority than 100.
For a given universe number, an E1.31 receiver shall treat data from packets with the highest priority as
the definitive data for that universe.

Looking at Table 1: E1.31 Packet Format, it should be in octet 108 in the packet.

[plugz]

https://github.com/mcallegari/qlcplus/b ... er.cpp#L97

[nedmech]

So, it looks like QLC+ is at least transmitting the correct default value of 100 for priority in the packet. Although it also appears it is only set in the E131Packetizer constructor, and then never touched. What is the possibility of adding a field to the E1.31 configuration dialog for setting the priority of the outgoing data? Should I add this as an Issue on github?

I'm wondering if the Priority doesn't affect the E131Controller::processPendingPackets() method as well. Per the spec, an E1.31 receiver need to be able to differentiate between packets received from different sources at different priority levels and act accordingly. I'm not seeing where the processPendingPackets method evaluates this. In my use-case, I'm probably going to have 2-3 sources sending out packets for the same E1.31 universe, just at different priority levels. I'm thinking that QLC+ will get confused and just react to all the incoming data the same, causing erratic input values. But I can see where dealing with packet priority from multiple sources could be difficult to implement.

I think this is turning into a conversation better suited for the Software Development board. Can an admin move it there?

[mcallegari]

Nathan, if QLC+ has to export all the possible parameters of all the possible protocols then it would be called OLA, not QLC+

What is exposed to the UI covers 99,9% of the cases, so you're probably into the 0.1% case.
Adding more and more and more stuff will only confuse people, turning this forum into a mess, because when average users have a problem, they try to change all the possible parameters (even if they don't know what they do) to see if they can make it work.

Since you can look at the code, I kindly ask you to:
- take as a fact that the E1.31 stream priority is fixed to 100, and tune the other transmitters with a lower or higher priority accordingly
OR
- modify the code as you prefer to expose the priority to the UI, but I don't think I will introduce such change mainstream

Of all the QLC+ plugins, I believe E1.31 is the least used, so we're really talking about a corner case here.

As for received packets, once you have more transmitters on the network, please report if you encounter issues.
Consider though, that you are talking about transmitters, not receivers, so the processPendingPackets you mentioned will do nothing if QLC+ is just transmitting.

[nedmech]

Massimo, Thank you for taking the time to reply. I will go ahead and take a look at what it will take to add the Priority to the configuration dialog. Am I correct in assuming I can recompile just the E1.31 plugin, or do I need to recompile the entire project?

I will leave the input packet priority alone for now. I realize it's a more extreme use-case. I'll report back what I find once I get all my hardware working together (should be all here in the next couple weeks).

Thanks again for the support. I really appreciate how responsive the QLC+ team is, from everything from simple questions that could've been answered by reading the documentation to off-the-wall extreme cases like mine.

[mcallegari]

Massimo, Thank you for taking the time to reply. I will go ahead and take a look at what it will take to add the Priority to the configuration dialog. Am I correct in assuming I can recompile just the E1.31 plugin, or do I need to recompile the entire project?

No problem. And correct, if you "cd plugins/E1.31" and do a "sudo make install" from there, it will build (and install) only the E1.31 plugin.

[nedmech]

OK, so compiling the project is proving more difficult than I anticipated. My only Linux machine (under-powered HP Mini running Ubuntu 14.04 LTS) refuses to install the QT tools and resources. And I quickly got lost trying to get get things to compile on my Windows 7 machine. Too many years being coddled by MS Visual Studio, I'm afraid. I thought I had everything configured per the instructions on the Wiki, and was able to compile the plugin from the command line. I was also able to load up the E1.31 project in QT Creator 3.4.2 (opensource, Qt 5.5.0) and compile. But the DLL is huge compared to the original one (> 3 MB) and is not detected correctly by QLC+ (no E1.31 plugin detected at all).

I know I'm asking quite a bit, but would anyone who is set up to compile for Windows be able to compile my changes to the E1.31 plugin for me so I can test them? My forked repo is here:

https://github.com/nedmech/qlcplus.git

I wish I could figure out how to get this to compile on my machine. I'm just not familiar enough with MinGW/gcc/Qt to be able to figure this out expediently.

[mcallegari]

By default the GIT sources are configured to build a debug version.
Debug DLLs are probably not compatible with release DLLs in Windows. Actually I never build in debug mode in Windows.

The wiki has a paragraph to switch between build modes:
https://github.com/mcallegari/qlcplus/w ... lease-mode

[nedmech]

YES!!! Finally able to compile and test!

Setting the project to Release got me partway there. It at least got the size of the files down to more expected size. QT Creator is still giving me fits looking for non-existent "ui_*.h" files, but I was able to finally compile and install from command line.

I had to recompile the entire project after all - for some reason QLC+ 4.9.1 doesn't like my new E1.31.dll. It might be because I have a newer version of Qt and MinGW than 4.9.1 was compiled with. After turning off the project settings for some of the plugins I haven't installed resources for (DMXUSB, Vellman, Enttec), the compile and install from command line finally worked. I had to manually copy the libstdc++-6.dll from MinGW into the qlcplus directory before it would run, but it is running now. I have yet to test it with hardware (should be arriving this week), but the network packet capture of the original version and my new version look the same, with the exception being that my new version can now set the Priority field value.

I would be extremely grateful if the development team would see fit to pick up my changes to the E1.31 plugin for the next release. It may just be me, but it seems like the ability to set stream priority is one of the huge advantages that sets E1.31 apart from ArtNet. Now that I can (apparently) compile the project, it's not a huge deal for me to recompile when the team issues a new release. But I'm setting this up for a facility where I may not always be available to patch in updates. It would be much easier for the end users at my facility to just be able to pick up the new install for QLC+ directly and have it work out-of-the-box without needing me to make a special build for them each time. I'll go ahead and make a pull request and let the team decide how they want to handle it.

[mcallegari]

Hey Nathan, I merged your change but then found a minor error.
See this: https://github.com/mcallegari/qlcplus/c ... c9fed38566

Thanks !

[nedmech]

Thanks, Massimo! I was struggling with that block of code, trying to understand what was happening there. I'm glad you caught my misinterpretation - it makes more sense what is going on there after looking at your commit.

Thanks again for the awesome support! I'll post an update once I have all my hardware installed and operating.