Hello! Please tell me how to set up this program to work with this controller.
I have no experience, and I do not know how to use it.
Maybe someone has already worked with such a controller?
Thank you, very much.
E1.31(sACN) Controller + QLC
-
- Posts: 1274
- Joined: Mon Apr 13, 2015 7:05 am
- Location: Bratislava, Slovakia
- Real Name: Jano Svitok
- Contact:
In short:
You need to know
1. IP address of the sacn controller
2. universe numbers for each of the four outputs
These you will learn from the sacn controller documentation/software
3. Your QLC+ computer must be on the same LAN as the controller, and use IP from the same subnet
(if you don't know what a subnet is, post here IP address of your controller, or better google it and learn some
IP network basics, it will come handy when you'll troubleshoot your setup).
Now:
- go to input/output tab
- if you don't have 4 universes already, add some so that you have 4 universes (big red + at the top)
- for each universe, check sacn in the output column on the right and select proper sacn universe and IP address
That's it. Now you can go to simple desk tab and try to raise some faders to see if the lights react.
For the rest, see QLC+ tutorials.
You need to know
1. IP address of the sacn controller
2. universe numbers for each of the four outputs
These you will learn from the sacn controller documentation/software
3. Your QLC+ computer must be on the same LAN as the controller, and use IP from the same subnet
(if you don't know what a subnet is, post here IP address of your controller, or better google it and learn some
IP network basics, it will come handy when you'll troubleshoot your setup).
Now:
- go to input/output tab
- if you don't have 4 universes already, add some so that you have 4 universes (big red + at the top)
- for each universe, check sacn in the output column on the right and select proper sacn universe and IP address
That's it. Now you can go to simple desk tab and try to raise some faders to see if the lights react.
For the rest, see QLC+ tutorials.
-
- Posts: 5
- Joined: Sun Apr 22, 2018 7:16 am
- Real Name: Yamil Pons
Hello,
I have a problem with this type of connection to control a led strip WS2812b
I have managed to connect the controller to the network, but it does not respond as it should, it does not respect the colors or the pixels
Is there any difference in the unicast or multicast connection?
Thank you
I have a problem with this type of connection to control a led strip WS2812b
I have managed to connect the controller to the network, but it does not respond as it should, it does not respect the colors or the pixels
Is there any difference in the unicast or multicast connection?
Thank you
- GGGss
- Posts: 2732
- Joined: Mon Sep 12, 2016 7:15 pm
- Location: Belgium
- Real Name: Fredje Gallon
Since it's not hardware connected to the host (QLC+) it cannot be a driver problem...
The picture clearly gives already a lot of hints:
* Multicast format
* initial IP 192.168.1.206
* a mode button
I'd first make sure a (not the QLC+) computer has an IP in the 192.168.1.x range (subnet mask 255.255.255.0).
From that computer browse to this device... since you can control it somehow - this would be my first step.
I think that on the interface you'll have to set certain port numbers or multicast addresses for the universes to listen to??
Then you can 'prepare' the QLC+ computer, have it set to an IP-address in the same range, unblocking UDP ports, unblocking traffic to these addresses, etc etc
Then you will have to prepare QLC+ so that universes are outputted to correct settings above.
You should be able to sniff these multicast packets... an try to figure out what's going wrong.
This is more network related than pure DMX and every smallest detail has to fit.
(Even putting a smart network switch in between can influence the outcome ... weather it works or don't)
This is the reason I'm more in favour of unicast packets since it's easier to sniff and detect what is going (wr)on(g)
I'm very sure the manual will reveal many of the secrets you have to know beforehand. But no indication of manufacturer - so happy hunting to find the manual
The picture clearly gives already a lot of hints:
* Multicast format
* initial IP 192.168.1.206
* a mode button
I'd first make sure a (not the QLC+) computer has an IP in the 192.168.1.x range (subnet mask 255.255.255.0).
From that computer browse to this device... since you can control it somehow - this would be my first step.
I think that on the interface you'll have to set certain port numbers or multicast addresses for the universes to listen to??
Then you can 'prepare' the QLC+ computer, have it set to an IP-address in the same range, unblocking UDP ports, unblocking traffic to these addresses, etc etc
Then you will have to prepare QLC+ so that universes are outputted to correct settings above.
You should be able to sniff these multicast packets... an try to figure out what's going wrong.
This is more network related than pure DMX and every smallest detail has to fit.
(Even putting a smart network switch in between can influence the outcome ... weather it works or don't)
This is the reason I'm more in favour of unicast packets since it's easier to sniff and detect what is going (wr)on(g)
I'm very sure the manual will reveal many of the secrets you have to know beforehand. But no indication of manufacturer - so happy hunting to find the manual
All electric machines work on smoke... when the smoke escapes... they don't work anymore
- GGGss
- Posts: 2732
- Joined: Mon Sep 12, 2016 7:15 pm
- Location: Belgium
- Real Name: Fredje Gallon
But you are able to address the pixels. Hey that is a succes
My hint to research what's going wrong is thinking in a 1-based system. We use to think 0-based in DMX. Once you pass by a network a universe 0 becomes universe 1... The same can go with addresses...
All electric machines work on smoke... when the smoke escapes... they don't work anymore
-
- Posts: 4
- Joined: Mon Apr 30, 2018 8:44 pm
- Real Name: Richard
Oh, I spoke too soon. We did get it!
For us it was just a matter of getting the subnet and things all in alignment and then the clincher for us was doing a reset with two flashes which forces the static IP rather than DHCP.
YAY
good luck
For us it was just a matter of getting the subnet and things all in alignment and then the clincher for us was doing a reset with two flashes which forces the static IP rather than DHCP.
YAY
good luck