Lessons learnt DMX over IP.. Part(1) there is standards / there is no standards

[nomis52]

The biggest thing that annoys our clients is that they have to be able to configure "complex" networks.

There will always be a learning curve with new technology. People either adapt to change or become obsolete.

It's like when DMX came about, people complained that they could no longer control their lights by hooking up batteries to the control lines and that they had to learn this new digital stuff.

At some point you have to say "the last 20 years have been great, but it's time to move on".

[nomis52]

And just to draw a comparison in the DMX world:

Lets say I go out an buy some cheap 'DMX' strobes that only work with a narrow range of timing values. I buy a controller from the same manufacturer and everything works fine.

A year later I add some movers and switch to a new console to drive them. The console outputs valid DMX (according to the standard) but it's not within the range that the cheap strobes recognize so they don't work properly.


If you were the project consultant or manufacturer of the second console what would you tell the customer? If you were the customer how would you feel?

Who is to blame? How could this situation have been avoided?

[mrpackethead]

And just to draw a comparison in the DMX world:

Lets say I go out an buy some cheap 'DMX' strobes that only work with a narrow range of timing values. I buy a controller from the same manufacturer and everything works fine.

A year later I add some movers and switch to a new console to drive them. The console outputs valid DMX (according to the standard) but it's not within the range that the cheap strobes recognize so they don't work properly.


If you were the project consultant or manufacturer of the second console what would you tell the customer? If you were the customer how would you feel?

Who is to blame? How could this situation have been avoided?

Your example is exactly what happens out there in "real world". Thats really what the entire thread is about. Despite there being some "standards" theres plenty of stuff out there that just won't work together or won't quite work as expected. In a perfect world this wouldn't happen, but its far from perfect.

Thats why you need to "test" stuff even if its so called "standard" because stuff doesn't always work as expected.

[nomis52]

Your example is exactly what happens out there in "real world".

I know, that's what I asked it . When faced with these questions everyone I've asked has given the same answer.

[mrpackethead]

There will always be a learning curve with new technology. People either adapt to change or become obsolete.

It's like when DMX came about, people complained that they could no longer control their lights by hooking up batteries to the control lines and that they had to learn this new digital stuff.

At some point you have to say "the last 20 years have been great, but it's time to move on".

Interesting that the vast majority of vendors don't' nessarily agree that they need to move on from Art-net.. One thing to say you agree with it, another thing to actually do it...

[mrpackethead]

I meant to do a cut and paste the other day from the E1.31 standard.

8.3 Multicast Subscription
Transmitters and Receivers shall use IGMP V2 [IGMP2] or IGMP V3 [IGMP3]. IGMP is used to communicate multicast address usage to network routers.
This requirement is placed on transmitters because many switches or routers do not handle incoming multicast packets well unless the source has advertised in this manner.*


The Shall is very clear. So simon is correct. If its not doing IGMP, its not doing E1.31.. You've got some pseudo e1.31 almost thing..




* American National Standard, E1.31-2009, Entertainment technology - Lightweight streaming protocol for transport of DMX512 using ACN, Revision 0.46, 23 October 2008, Entertainment Services and Technology Association ]

This thread is quite frustrating to read...

If a receiver does not support IGMP it does not support E1.31. Period. You can't support half a standard and expect things to work.

As a customer I'd take the devices back to the manufacturer and tell them you either want a patch fix or your money back. Otherwise it's like buying a car with only one gear and expecting it to perform well at all speeds.

Simon
(PLASA Standards Member)

[Zeph]

MPH, it sounds like you intend to fix that...

So, do the ECG and/or e68x implement IGMP yet?

[mrpackethead]

MPH, it sounds like you intend to fix that...

@Zeph, yes, we are currently working on implementing IGMP for our control systems.

[jstjohnz]

MPH, it sounds like you intend to fix that...

So, do the ECG and/or e68x implement IGMP yet?

The E68x controllers use IGMP version 2. However, unless the switches that the controllers are attached to implement GMP snooping, there won't be any benefit. GMP snooping is usually only found in managed switches.

[j1sys]

At the moment the ECG series do not do IGMP. We do have multicast filtering which helps a LOT on traffic load. As Jim said, IGMP won't help if you don't have an IGMP snooping switch which in the hobbyist market we believed would be the majority of the time.

The Microchip Stack, which ECG is based on (and I believe MPH hardware), did not come with IGMP. We have to add it. MPH is working on his, I've got mine working in the lab and will include it in the next round of releases. I believe Jim's Wiznet already included the protocol so he had a leg up on us.

But while we're talking standards. The standard requires that a controller "An E1.31 receiver shall also respond to 1.31 data received on its unicast address". So the complaints that my supporting unicast is non-standard is a little over the top.

-Ed