Praktijkervaring ethernet sturingen?

[Outline]

Mac, mijn bijdrage nog gelezen? Stelde ongeveer hetzelfde als jij. Alleen geef ik DMX nog wat langer, tot 15 jaar. DMX zelf is technisch volledig uitgeput, alleen de aansturende hardware groeit nog steeds groter (qua universes). Persoonlijk denk ik dat we eerst meer een tussenvariant gaan zien naar voorbeeld van MA. Dus een Ethernet-gebaseerd hoofdnetwerk met DMX als locaal netwerk. Maar de tijd zal het leren!

[VANEENBERGEN]

DMX is zeker nog lang niet dood.
de voordelen van DMX:
- zeer goedkoop te maken
- 512 kanalen is nog steeds voor heelveel toepassingen goed, zelfs als je een par dmx-lijnen gebruikt. kijk maar op het forum er zijn meer die genoeg hebben aan 1/2 lijnen dan 30+ lijnen.
- makkelijk aantesluiten in daisy-chaing (achter elkaar) ipv een sternetwerk dat ethernet is.
- robust
- lange kabel lengtes mogelijk, de RS485 is gespect tot 1200m ethernet maar 100m

voordelen ethernet fff terug zoeken op het forum

http://www.forums.licht-geluid.nl/forums/showpost.php?p=325386&postcount=27

[axs]

Sorry, maar wat versta jij onder stacks?

De data die in packets door het TCP/IP of UDP protocol worden verzonden komen eerst in een 'stack' terecht totdat alle data beschikbaar is.
Dit is meteen het nadeel van het protocol aangezien de data niet met zekerheid tijdig de ontvanger bereikt.

[VANEENBERGEN]

dan zou dit ook het geval zijn bij ACN. de basis van ACN / artnet / pathport / ETC net / MA-net is allemaal hetzelfde. ACN zou dan dus volgels jou dezelfde nadelen hebben als alle anderen.
IP data fragmentation wordt niet gebruikt. dit betekend dat het UDP packet altijd DIRECT alle data bevat. bij TCP moet je inderdaad wachten tot alles beschikbaar is, maar TCP wordt niet gebruikt (hooguit voor configuratie settingen, maar niet voor real-time data).

ik weet niet wie jou dit allemaal heeft wijs gemaakt, maar trust me die problemen bestaan er niet. Het enige "nadeel" dat art-net zou hebben is dat het noiet fijn op een office netwerk draaid. maar dat wordt normaal ook niet gedaan.

joost

[Bart Bomans]

Joost,
Je vermeld in een vorige post dat je al 40 lijnen hebt gestuurd in 1 netwerk. Nu het ArtNet protocol zelf schrijft voor dat je best niet over 20 lijnen gaat. In dat was in de tijd dat er nog geen pixelmapping werd gedaan.
Ik heb gemerkt bij pixelmapping dat je nodes hier en daar frames laten vallen. Ik heb het gechecked met de tool van Artistic license, die aangeeft dat de nieuwe data juist is, terwijl de node niet heeft gereageerd op een verandering bij vele universes. Vb 1 van de universes is bij een color bump niet meegevolgd. En dit gebeurd random, maar meestal bij de hogere universes. Bij colorbumps valt dit heel erg op doordat er geen nieuwe data wordt verzonden. We hebben ons eerst gek gezocht wat er gaande was.

Als je alle universes laat faden, dan valt het niet op omdat elke universe regelmatig veranderd.
Je kan het testen door alle universes te laten faden vb universe 1-15 (zodat er veel trafiek is), en dan een hogere universes 16-20 te laten bumpen tussen kleuren. Dan zie je dat er hier en daar een universe de frame heeft gemist. Heb je daar nieuwe firmware voor of zo die beter kan volgen?

[Bart Bomans]

Joost, ter info.
We hebben ook al geprobeerd door Ethernet switchen te verwisselen.
Via de optie 'broadcast storm protection' te disablen komen de UDP packets netjes door via de Artistic Licence tool.

[axs]

dan zou dit ook het geval zijn bij ACN. de basis van ACN / artnet / pathport / ETC net / MA-net is allemaal hetzelfde. ACN zou dan dus volgels jou dezelfde nadelen hebben als alle anderen.
IP data fragmentation wordt niet gebruikt. dit betekend dat het UDP packet altijd DIRECT alle data bevat. bij TCP moet je inderdaad wachten tot alles beschikbaar is, maar TCP wordt niet gebruikt (hooguit voor configuratie settingen, maar niet voor real-time data).

ik weet niet wie jou dit allemaal heeft wijs gemaakt, maar trust me die problemen bestaan er niet. Het enige "nadeel" dat art-net zou hebben is dat het noiet fijn op een office netwerk draaid. maar dat wordt normaal ook niet gedaan.

joost

Dank je voor de rechtzetting dan... ik was er rotvast van overtuigd dat UDP namelijk ook de data op die manier doorstuurde... en heb het ook steeds op die manier begrepen.
Ga me er dan precies toch nog stukje verder in moeten verdiepen...

[VANEENBERGEN]

@bart

zoals ik al in mijn post aangaf draaid artnet niet zo goed op office netwerken, dus ook niet op standaard office switches.

broadcast storm protection moet inderdaad worden gedisabled.
een voorbeeld. hippotizer had ook problemen met het aalsturen van meerdere DMX lijnen, tot dat we de switch vervingen.

wat gebruikt je voor het genereren van de data (DMX), ik ben erg benieuwd? 40 lijnen moet prima gaan. een voorbleed van wat we in nederland hebben gedaan. live38 hadden we 32 DMX lijnen, video communicatie en HOGIII PC op 1 netwerk zitten.

@axs
als je wat goede pointers of info wilt, meel me maar.

joost

[bobbyb]

Goed om te zien dat er goede ervaringen zijn met art net (ik heb besloten om dat ook maar te gaan gebruiken).

Ik had nog 2 vraagjes:

1: wat is een colorbump?
2: en welke router switsjes zijn dan goed en vooral welke NIET?

[qwote]live38 hadden we 32 DMX lijnen, video communicatie en HOGIII PC op 1 netwerk zitten.[/qwote]

Das een hoop

[Bart Bomans]

Hey Joost,

Het is niet het aantal universes dat je samen gebruikt, het is op de piekmomenten waarbij tergelijkertijd alle universes veranderen van waarde die het probleem zijn.
Het is reproduceerbaar met eender welke tafel die genoeg Artnet universes tergelijkertijd uitstuurd. Zelfs met 1 dmXLAN node4 zonder ethernet hub of switch is het probleem reproduceerbaar. Het lijkt me dat als er vb 20 universes tergelijkertijd veranderen, dat de processor in de node dit niet krijgt verwerkt, waardoor hier en daar frames wegvallen.
Bij een colorbump wordt die informatie maar 1 keer weggestuurd. Dus als die node dat frame niet heeft gezien, bijft heel die universe op de oude waarde staan.
Op dit moment heb ik hier de test staan met jullie Etheret dmXLAN 4 en mijn Maxxyz. Ik heb 20 universes gepatched die ik van waarde laat veranderen. Als ik de box configureer vanaf universe 9-20 begint de box frames te missen, terwijl als ik de box op de eerste universes zet. dan volgt hij goed mee.
Op de Artistic Licence DMXTool zie ik alle 20 universes perfect veranderen zonder dat er waarden verloren gaan.
Ik heb hetzelfde getest met een box van Luminex, geen problemen daar. Dus de Maxxyz die ik gebruik stuurt alles goed uit.

bobbyb: Een color bump is een zeer snelle overgang van een kleur zonder fading. Op een grote array van LED's betekend dit dat alle dmx kanalen veranderen dus ook alle Artnet univereses.

[VANEENBERGEN]

ik test/reken altijd op wordt case senario. de hele processor performace is volledig berekend. de verwerking van een ethernet packet is altijd sneller dan dat het packet lang is in micro seconden.

welke versie software draai je in de node4?

joost

[swinnenb]

Om even terug te komen op de oorspronkelijke vraag: om wat meer inforamtie te verstrekken van gebruikte protocollen en hun voor- en nadelen, wil ik hier even enkele dingen op een rij zetten. (Wel vrij theoretisch, maar daar zit het hem nu wel net)

ArtNet[INDENT]Algemeen:
[/INDENT][LIST][*] ArtNet is een netwerk protocol dat vooral gebruikt wordt om meerdere DMX lijnen (universe) te routen over een netwerk data link.[*]Tot nu het meest gebruikte protocol bij verschillende fabrikanten(meer dan 50 fabrikanten). Dit omwillen dat het een open protocol is dat vrij geïmplementeerd kan worden.[*]Gebaseerd op UDP datagram.[/LIST][INDENT]Voordelen:
[/INDENT][LIST][*]Vrij, open protocol[*]Makkelijk te implementeren[*]Als alles goed loopt: Geen broadcast storm protection, geen collision, en geen verlies van paketten. Dan geeft UDP een beter real-time resultaat dan TCP (wel andere nadelen)[/LIST][INDENT]Nadelen:
[/INDENT][LIST][*]Gebeaseerd op UDP broadcast. Omwillen dat de meesten, ArtNet zo implementeren dat alle universe gebroadcast (iedere node ontvangt alle paketten) worden, is er veel processing power nodig aan de node zijde. Sommigen gebruiken zelfs limited broadcast (255.255.255.255), en blijven zelfs niet binnen hun Submask.[*]UDP vs TCP: UDP heeft geen ingebouwd bevestigings systeem. Men is dus niet zeker of de paketjes aankomen. De nodes kunnen niet reageren dat ze het paket ontvangen hebben, of kunnen geen paket terug opvragen. Bij TCP protocollen is dit wel mogelijk, maar dit zou wel een real-time verlies betekenen.[*]Moeilijk te routen omwille van gebruik van Class A ethernet adressen.[/LIST]Conclusie: Makkelijk te gebruiken, maar het netwerk heeft hier wel te lijden onder het UDP broadcast verhaal. De processing power aan de node zijde is afhankelijk van het aantal gebruikte universes en of er gebroadcast wordt, en niet van wat het functioneel moet doen. Maw: Ook al moet een node2 maar 2 DMX universes bedienen, toch moet deze vaak (ingeval van broadcast) alle pakketen die over Ethernet arriveren van alle universes processen.

ACN[INDENT]Algemeen:
[/INDENT][LIST][*]ACN (Advanced Control Network) is niet een protocol om DMX te routen, maar is een een protocol dat hoofdzakelijk een transport paket beschrijft. Dit transport paket kan wel gebruikt worden om ook DMX informatie over te sturen, maar ook andere control paketten. Het is dus een vrij abstract paket dat op zich funtioneel niet veel inhoudt.[*]ACN bevat een methode om alle ACN devices te herkennen op een netwerk. En kan een data structuur uitwisselen die beschrijft wat een ACN device kan.[*]ACN is gebaseerd op UDP datagram.[*]Gebruikt Multicast ipv broadcast.[*]Een van de mogelijkheden die er staan aan te komen (zal wel nog enkele jaren duren???) is DMX over ACN. Maar in de toekomst als dit protocol door zal breken (?) zal een ACN device rechtstreeks aanspreekbaar zijn en zal convertie naar DMX universes enkel nodig zijn voor legacy DMX toestellen.[*]ACN is nog in ontwikkeling !!![/LIST][INDENT]Voordelen:
[/INDENT][LIST][*]UDP multicast: beter verdeling van netwerk load dan broadcast.[*]Ingebakken in ACN protocol is een methode voor het controleren of een paket aangekoemn is (niet waterdicht als TCP maar wel al veel beter dan enkel UDP).[*]Uitbreidbaar. Vrij abstract protocol dat voor veel verschillende controle toepassing in de toekomst kan gebruikt worden.[/LIST][INDENT]Nadelen:
[/INDENT][LIST][*]Nog niet beschikbaar, nog steeds in ontwikkeling (draft4) ![*]Open ???[*]Nog steeds UDP. Dus nog niet 100% zekerheid of alle paketten aankomen. Vraag is of TCP hier wel in kan meespelen omwillen van real-time aspect.[/LIST]Conclusie: Denk wel dat ACN potentieel heeft, maar het zal nog een tijdje duren voor dat dit bij de grebruiker terecht komt. Het zou wel een degelijkere oplossing kunnen bieden dan ArtNet.

Alle andere vernoemde protocollen zijn protocollen die eigendom zijn van bepaalde merken. Vandaar dat ik daar ook niet veel over te vertellen heb.

PS: RDM (Remote Device Management) wordt reeds gebruikt in verschillende LED armaturen, vooral architectural. Omdat hier addressering en dergelijk makkelijk kunne gebeuren over de DMX lijn, zeker als het armatuur fysiek niet meer bereikbaar is (ingebouwd in muren, fontijen, ...)

ArtNet is niet het beste protocol, maar wel momenteel het meest gebruikte protocol. En dat telt toch wel door. Dan mogen er al nieuwe betere protocollen bedacht zijn, zolang ze niet geïntegreerd worden zullen ze niet bij de gebruikers terecht komen. Ik denk dat Artistic Licence hier wel een zeer mooie bijdrage heeft geleverd door hun protocol (ArtNet) open te laten.

Ik hoop dat dit wat zaken duidelijk maakt.

Grtzzzzzz

[Bart Bomans]

ik test/reken altijd op wordt case senario. de hele processor performace is volledig berekend. de verwerking van een ethernet packet is altijd sneller dan dat het packet lang is in micro seconden.

welke versie software draai je in de node4?

joost

De versie is 1.5

[axs]

dit betekend dat het UDP packet altijd DIRECT alle data bevat. bij TCP moet je inderdaad wachten tot alles beschikbaar is, maar TCP wordt niet gebruikt (hooguit voor configuratie settingen, maar niet voor real-time data).

ik weet niet wie jou dit allemaal heeft wijs gemaakt, maar trust me die problemen bestaan er niet. Het enige "nadeel" dat art-net zou hebben is dat het noiet fijn op een office netwerk draaid. maar dat wordt normaal ook niet gedaan.

joost

Hoi Joost,

Blijkbaar heb ik 2 dingen door elkaar gehaald, lijkt me.
Ik ben niet zeker of alle data in 1 packet vervat zit (betwijfel het zelfs, maar hier geef ik je het voordeel van de twijfel) maar er is via UDP zeker geen controle of alle packets zijn aangekomen.
Hierdoor kan je dus packetloss krijgen waardoor er data in je ARTNET-data KAN missen.

Ik heb hier dus idd gezegd dat je dient te wachten tot alle data beschikbaar is (wat dus idd niet lijkt te kloppen) maar dat haalde ik dus door elkaar met de mogelijkheid tot packetloss over UDP.
Packet verloren is packet verloren... helaas.
En dat is net het nadeel van ARTNET wat in het toekomstige ACN wel beter kan opgevangen worden (maar nog steeds niet uitgesloten)


PS: ik ben geinteresseerd in de info die je verder hebt ivm ARTNET/ACN/... bijleren doen we met alle plezier. Mailen kan via het mailadres in mijn profiel.

[VANEENBERGEN]

@axs
Het verliezen van packeten kan nou eenmaal ebeuren. de verzender moet een simple algoritme inbouwen om het effect hiervan te verminderen.

@bart
ik ben nu met versie 1.6 bezig en ik zal er nog eens naar kijken.

joost