configure OLA to send unicast artnet messages

[Tim Bright]

Hey again,

I was wondering if it possible to configure OLA to send unicast artnet messages.

In the admin it says the primary broadcast address is 

Primary Broadcast Address

192.168.0.255

At the moment,I am not able to get any of my software to register this broadcast.  They are registering the artnet node - and I can see the packets being transmitted over the network, but I am not able to register the data I am sending via the web page DMX console in either my Max /Msp patch - or my artnet monitoring software on my PC.

Here is my artnet-config settings.  

always_broadcast = false

enabled = true

ip =

long_name = OLA - ArtNet node

net = 0

output_ports = 4

short_name = OLA - ArtNet node

subnet = 0

use_limited_broadcast = false

use_loopback = false

Many Thanks

Tim

[Andrew Frazer]

Are you able to do a dump of the traffic using wireshark?    That would probably tell us a lot about what is happening ( or not happening )

--
The Open Lighting Group: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Simon Newton]

On Mon, Jan 20, 2014 at 6:26 AM, Tim Bright <tbr...@gmail.com> wrote:

Hey again,

I was wondering if it possible to configure OLA to send unicast artnet messages.

In the admin it says the primary broadcast address is 

Primary Broadcast Address

192.168.0.255

At the moment,I am not able to get any of my software to register this broadcast.

What do you mean by "register this broadcast" ?

OLA will unicast packets iff always_broadcast is false (default) AND one or more nodes replied to ArtPoll AND there are less than 30 nodes with output ports configured for the universe.

But no, you can't manually configure addresses to unicast to.

Simon

 They are registering the artnet node - and I can see the packets being transmitted over the network, but I am not able to register the data I am sending via the web page DMX console in either my Max /Msp patch - or my artnet monitoring software on my PC.

Here is my artnet-config settings.  

always_broadcast = false

enabled = true

ip =

long_name = OLA - ArtNet node

net = 0

output_ports = 4

short_name = OLA - ArtNet node

subnet = 0

use_limited_broadcast = false

use_loopback = false

Many Thanks

Tim

[Jason Kyle]

The whole Art-Net II/III unicast thing is supposed to be transparent to the end user. Each node keeps an internal table of devices and when there’s a universe/port-address match it will unicast to that device (i.e. if there’s 4 Art-Net II/III DMX out nodes on port-address 00:0:0 it’s necessary to unicast to each one). Some Art-Net implementations handle unicast with a manual entry of [usually] 1 IP destination address rather than generating and listening for ArtPollReply messages and doing it transparently. There are some special WAN applications with gateways where manual unicast entries are justified but in almost all cases it’s just a kludge.

 

In our eDMX products we have pretty much the same conditions for unicast as OLA does. For backwards compatibility reasons an Art-Net II/III node must broadcast if it hasn’t received any ArtPollReply messages since there’s no way of knowing if only Art-Net I devices are present. Once an ArtPollReply message has been received and there’s a universe/port-address match you can start unicasting however that is only practical to a reasonable limit (30 in OLA) and we make that user definable for various reasons then beyond the limit switch back to broadcast. Sometimes there’s a mix of Art-Net I/II/III gear and thus a means to always broadcast is required. I sometimes wonder if having a never_broadcast option would be a good addition? That would cover the condition where all gear is known to be Art-Net II/III and if a node was offline for some reason the sender wouldn’t revert to broadcasting as a result.

 

Looking forward to E1.33!

 

Best Regards,

 

Jason Kyle

DMXking.com / JPK Systems Limited

[Tim Bright]

Thanks for all this everyone, I will have a look at all these suggestions, including the TCPdump when I get a chance in the next couple of days

many thanks

TIm

[Andrew Frazer]

If you are starting out on a project, why not considering using E1.31 instead?  Its so much simpler.

[Steve French]

I agree with Andrew!!  E1.31 (sACN) is much more elegant and easier to implement.  I have also heard that the protocol implementation itself is much more efficient.  (does anyone know of a good paper explaining the technical details of why sACN is more efficient and a better standard than Artnet?  One point that sticks out from my memory after a discussion with John Huntington is that Artnet keeps sending data @ DMX rates even when the data is static, while sACN only sends when the data changes, resulting in significantly less redundant and unnecessary network traffic.  I think there are many other reasons too.)

Thx!

--

Respectfully,

Steve French

President, Volt Vision

www.voltvision.com

Sent from my iPhone

[Simon Newton]

On Tue, Jan 21, 2014 at 6:53 AM, Steve French <voltv...@gmail.com> wrote:

I agree with Andrew!!  E1.31 (sACN) is much more elegant and easier to implement.  I have also heard that the protocol implementation itself is much more efficient.  (does anyone know of a good paper explaining the technical details of why sACN is more efficient and a better standard than Artnet?  One point that sticks out from my memory after a discussion with John Huntington is that Artnet keeps sending data @ DMX rates even when the data is static, while sACN only sends when the data changes, resulting in significantly less redundant and unnecessary network traffic.  I think there are many other reasons too.)

That's really up to the controller implementation. sACN has to send at least one packet every 3 seconds otherwise the receivers can timeout.

The real win comes from the fact sACN is multicast, whereas ArtNet is some combination of unicast / broadcast.

Simon

[Jason Kyle]

But only when there’s a device discovery mechanism to at least match Art-Net (and no E1.17 doesn’t count lol). sACN has a higher protocol overhead than Art-Net so byte for byte sACN is less efficient. So far as sending redundant network traffic goes that’s not correct since it’s entirely controller dependant and Art-Net nodes are required to hold the last scene forever versus sACN cutting to blackout within seconds.

 

Multicast when not implemented properly in network infrastructure is as bad a broadcast. Personally I see this as a stumbling block for mass adoption of sACN because most think they can just choose Multicast and they’re done but unfortunately that’s not the case. Without a decent L2/L3 network switch and an IGMP querier (some L2/L3 switches have one built in but inactive by default) all your multicast traffic will end up on every single network port and thus fed to every device on the network. Only when your sACN nodes generate IGMP messages and your infrastructure acts accordingly will Multicast actually work properly.

 

I suspect real implementations of sACN with device discovery will end up having pretty much the exact same unicast mechanism as Art-Net alongside multicast.

[ro...@thebartons.org.uk]

From a network point of view, sACN has the benefit that it is easy to
filter traffic based on universe number (you can just block/allow
239.255.0.x where x is the universe number).

On 2014-01-21 18:50, Jason Kyle wrote:
> But only when there's a device discovery mechanism to at least match
> Art-Net (and no E1.17 doesn't count lol). sACN has a higher protocol
> overhead than Art-Net so byte for byte sACN is less efficient. So far
> as sending redundant network traffic goes that's not correct since
> it's entirely controller dependant and Art-Net nodes are required to
> hold the last scene forever versus sACN cutting to blackout within
> seconds.
>
> Multicast when not implemented properly in network infrastructure is
> as bad a broadcast. Personally I see this as a stumbling block for
> mass adoption of sACN because most think they can just choose
> Multicast and they're done but unfortunately that's not the case.
> Without a decent L2/L3 network switch and an IGMP querier (some L2/L3
> switches have one built in but inactive by default) all your multicast
> traffic will end up on every single network port and thus fed to every
> device on the network. Only when your sACN nodes generate IGMP
> messages and your infrastructure acts accordingly will Multicast
> actually work properly.
>
> I suspect real implementations of sACN with device discovery will end
> up having pretty much the exact same unicast mechanism as Art-Net
> alongside multicast.
>
> Best Regards,
>
> Jason Kyle
>
> DMXking.com / JPK Systems Limited
>

> FROM: open-l...@googlegroups.com
> [mailto:open-l...@googlegroups.com] ON BEHALF OF Simon Newton
> SENT: Wednesday, 22 January 2014 05:59
> TO: open-lighting
> SUBJECT: Re: [open-lighting] configure OLA to send unicast artnet

> messages
>
> On Tue, Jan 21, 2014 at 6:53 AM, Steve French <voltv...@gmail.com>
> wrote:
>
> I agree with Andrew!! E1.31 (sACN) is much more elegant and easier to
> implement. I have also heard that the protocol implementation itself
> is much more efficient. (does anyone know of a good paper explaining
> the technical details of why sACN is more efficient and a better
> standard than Artnet? One point that sticks out from my memory after a
> discussion with John Huntington is that Artnet keeps sending data @
> DMX rates even when the data is static, while sACN only sends when the
> data changes, resulting in significantly less redundant and
> unnecessary network traffic. I think there are many other reasons
> too.)
>
> That's really up to the controller implementation. sACN has to send at
> least one packet every 3 seconds otherwise the receivers can timeout.
>
> The real win comes from the fact sACN is multicast, whereas ArtNet is
> some combination of unicast / broadcast.
>
> Simon
>
>> Thx!
>>
>> --
>>
>> Respectfully,
>>
>> Steve French
>>
>> President, Volt Vision
>>

>> www.voltvision.com [1]

>> DMXking.com [2] / JPK Systems Limited
>>
>> FROM: open-l...@googlegroups.com [mailto:open-l...@googlegroups.com]
>> ON BEHALF OF Simon Newton
>> SENT: Tuesday, 21 January 2014 08:02
>> TO: open-lighting
>> SUBJECT: Re: [open-lighting] configure OLA to send unicast artnet

>> (irc.freenode.org [3])

>> To unsubscribe from this group, send email to
>> open-lightin...@googlegroups.com
>> For more options, visit

>> https://groups.google.com/groups/opt_out?hl=en [4]

>>
>> --
>> The Open Lighting Group: open-l...@googlegroups.com, #openlighting

>> (irc.freenode.org [3])

>> To unsubscribe from this group, send email to
>> open-lightin...@googlegroups.com
>> For more options, visit

>> https://groups.google.com/groups/opt_out?hl=en [4]

>>
>> --
>> The Open Lighting Group: open-l...@googlegroups.com,

>> #openlighting (irc.freenode.org [5])

>> To unsubscribe from this group, send email to
>> open-lightin...@googlegroups.com
>> For more options, visit

>> https://groups.google.com/groups/opt_out?hl=en [4]

>>
>> --
>> The Open Lighting Group: open-l...@googlegroups.com,

>> #openlighting (irc.freenode.org [5])

>> To unsubscribe from this group, send email to
>> open-lightin...@googlegroups.com
>> For more options, visit

>> https://groups.google.com/groups/opt_out?hl=en [4]

>
> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting

> (irc.freenode.org [5])

> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

> [4]

>
> --
> The Open Lighting Group: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

> [4]

>
> --
> The Open Lighting Group: open-l...@googlegroups.com,
> #openlighting (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit

> https://groups.google.com/groups/opt_out?hl=en [4]
>
>
> Links:
> ------
> [1] http://www.voltvision.com
> [2] http://DMXking.com
> [3] http://irc.freenode.org/
> [4] https://groups.google.com/groups/opt_out?hl=en
> [5] http://irc.freenode.org

[Andrew Frazer]

There's multiple switches under $100 now that support igmp snooping complete with igmp query. I'm seeing more customers migrating. It's just not that hard. Vendors who don't support it will get left behind.

[Jason Kyle]

That's great news. Perhaps you could share your list of budget switches with
IGMP support?

-----Original Message-----
From: open-l...@googlegroups.com [mailto:open-l...@googlegroups.com]

[Jason Kyle]

Totally agree there but I think if you're filtering then something's gone wrong with your multicasting!
Don't get me wrong I'm not against sACN in any way. Just pointing out it's not viable in many installations due to a lack of device discovery and in fact we still run Art-Net discovery on our hardware when sACN is in use. Once discovery has been added sACN is definitely preferable.

[Andrew Frazer]

I'll post on the OLA Wiki a little later today.

[Andrew Frazer]

> Totally agree there but I think if you're filtering then something's gone wrong with your multicasting!

There was a couple of times i have used multicast filters to sort out some really tricky network issues. ( not in a lighting system mind you ). But you could have only ever regarded that as a hack! and it was a last resort.
I note that several micro controller implementations ( PIC comes to mind first ) have a multicast filters. But the point of building a proper network is that none of this is needed!

> Don't get me wrong I'm not against sACN in any way. Just pointing out it's not viable in many installations due to a lack of device discovery

Why is device discovery actually important?

[Andrew Frazer]

Just a couple that came to mind immediately.



http://www.dlink.com.au/products/?pid=1010 $62.00
Theres a stack of them from TP-Link ( really cheap )
NEtgear GS105E $35.00

On 31/01/2014, at 11:15 PM, Jason Kyle <ja...@jpk.co.nz> wrote: