Exceed 512 channels in fixture.... causes crash

[ralbrightii]

I found some really neat Wifi pixel controllers that can handle up to 2048 pixels. (https://www.aliexpress.com/item/32854807170.html) And they work GREAT in QLC+.... until you try to add a fixture exceeding 512 channels. These controllers use Art-Net.

I can confirm multiple times, that any time I add a fixture with a mode over 512 channels, QLC crashes. However if I add a mode with under 512 channels, it allows me to for a single time to go into the properties and change the mode to above 512 channels. Next time I try accessing the properties... QLC crashes.

Used on 4.12.1, however it doesn't look like that particular bug was fixed in 4.12.2.

Any suggestions on running very large pixel counts under 1 Art-Net universe?

(I have included my custom built fixtures that do cause the errors.)

HolidayCoro-Pixel-Bar.qxf

(365.31 KiB) Downloaded 297 times

[GGGss]

You know that a DMX universe is limited to 512 channels by design?

And looking how Artnet is treated on that interface ... I have some bad news for you:

You are limited to 170 pixels in Artnet so 170 x 3 = 510 channels.
Does explain a lot does it?

With other tested devices (and I did use them) you would have to configure 12 universes for the 2048 RBG pixels...
DMX 0.0 - 0.510 px1 - px170
DMX 1.0 - 1.510 px171 - px341
...
DMX 12.0 - 12.510 px1879 - px2048

[GGGss]

Looking at your fixture definition you will have to delete all pixels > 170
I can see now why QLC+ is doomed to crash if you use a fixture like that... QLC+ cannot bind the DMX channels with that fixture without exceeding DMX Universe standard.
(and what did you want to achieve with those modes? A mode is bound to the fixture hardware - so here there is only 1 mode present: 170px 170 heads)

[ralbrightii]

You know that a DMX universe is limited to 512 channels by design?

And looking how Artnet is treated on that interface ... I have some bad news for you:
ScreenHunter_04 Sep. 06 09.47.png

You are limited to 170 pixels in Artnet so 170 x 3 = 510 channels.
Does explain a lot does it?

With other tested devices (and I did use them) you would have to configure 12 universes for the 2048 RBG pixels...
DMX 0.0 - 0.510 px1 - px170
DMX 1.0 - 1.510 px171 - px341
...
DMX 12.0 - 12.510 px1879 - px2048

Thank you. I honestly did not see that little blurb. (Went back, and sure enough, black and white, right in front of me.) DOH!

[ralbrightii]

Is there a way for QLC+ to control large matrices in one "Universe"? How do these smaller controllers then control 2048 pixels with only one connection point?

[GGGss]

Yes there is
but not in one universe (why? It doesn't matter to your programming)

A universe is bound to the physical aspect of DMX = 1 cable carrying 512 channels to max. 32 fixtures (unless spliters)
Since we can use Artnet (cASN, e.xxx) as a medium we have multiple DMX carriers (cables) bound into one medium (network).
These make sure that we can give commands to numerous fixtures.

Now if you want to address 2048 pixels you'll need at least 12 universes. 2048px x 3 (RBG) = 6144 channels / 512 = 12
In practice you will divide the pixels in groups (say the width of your screen) and each row needs its own controller (not necessarily - it makes programming easier)
Let's work this out:
A) 2048px = (4w x 3h) and say B) 4w = 3h - old fashion 4/3 ratio

[OddSocks]

This is one of the reasons I have been requesting a tick box on the RGB matrix creation pop-up to fill the matrix with just RGB fixtures rather than fixtures that span a whole row / column.

I have a number of pixel strings that are 150 pixels long. My controller is an Advatek pixlite 16 mkii . This control board will cope with 16,320 RGB pixels but numbers them sequentially to fill the universes on each output.

With the RGB matrix creator at the moment, if you wanted to create a matrix with 14 x 150 strings (2,100 Pixels) it will create 14 universes with just 150 pixels on each one with 62 channels unused, rather than 12 full universes with 170 pixels in each and one last universe with 60.

Now I could split this so that each string was feed from an output on the board, but as each output can handle 1,020 pixels, that would be a massive waist of resources.

[GGGss]

We are getting off topic here...

Depending on your version of the board (ECO) every output needs 6 (2) universes to reach max. pixels per output...
So how you arrange your pixels depends on hardware wireing.

Say that you can create Universes with 170px ... how are you going to separate them in hardwire?
output 1: [r1] 150px new row [r2] 20px + 130px [r3] 40px + 110px [r4] 60px + 90px [r5] 80px + 70px [r6] 100px + 50px
and now (!) [r7] 20px + 100px AND 30px from output 2...

I really would like to see how you are going to separate all these strings of pixels in QLC+
It will involve massive manual labour.

And what type of pixel will you use? The time you need to refresh 1020px will be huge vs refresh speeds QLC+ can provide.
In this case I'd be really happy 'to waiste' resources. For the price of that board I can only work for 3hrs, manual rearranging groups of pixels in QLC+