DMX in PLC (Wago?)

KNX?? Kan een mod en topic tital aanpassen: moet DMX zijn...
het is al laat.

Hier is het protocol wat meer in detail uitgewerkt:
https://community.element14.com/technologies/open-source-hardware/b/bl…

De grootste uitdaging is om het break patroon te maken van 92 us (constant laag).(-edit- er stond 44 us maar strike thru werkt niet meer?)
Dat krijg je normaal gesproken niet voor elkaar met een normale UART en moet je wat truken gaat uithalen.

Er zijn twee oplossingen waarmee je dat kunt doen:

Oplossing 1: De baudrate omschakelen zodat 1 byte data (0x00) een minimale 92us low tijd heeft en dan het byte 0x00 verzenden. Komt niet heel erg nauw kwa timing.
Waarschijnlijk lukt het op de 115k2 baudrate.
Daarna wachten tot de UART leeg is (End of transmit).
Na die transmissie de baudrate weer terugschakelen op de 250 kB die standaard is.

Oplossing 2: Je kunt het UART break bit inschakelen, dan 2 bytes data verzenden.
Daarna wachten tot de UART leeg is (End of transmit).
Dan de break uitschakelen.

De oplossing 2 vind ik zelf het meest elegant. Dan hoef je niet te klooien met de baudrate switches.

Je hebt nog een andere uitdaging, de vraag is of die PLC wel 250 kbit aan kan?

En kun je het BREAK bit van de UART in de PLC wel vanuit je software bij?
Anders moet je oplossing 1 kiezen, maar dan krijg je de hassle van het omprogrammeren van de baudrate elke keer.
Kun je in de PLC snel genoeg zien of de transmitter empty is?

Wikipedia heeft er best een goed artikel over.
Ik het kort: na de 'start' reutel blaf je er 512 bytes uit.
Elk device heeft 1 of meerdere adressen. En het is gewoon bytes tellen. Dus adres 412 zal de 413-de byte zijn (zo ff uit m'n hoofd).
Hoe je een device aanstuurt zal uit de documentatie van het device moeten blijken. Oorspronkelijk waren het 1-kanaal dimmers. Ik heb er ooit nog wel eens mee gestoeid met een RGBWO spot (serieus ding, 5 kleuren en dan ook nog een 'master' channel). Die gebruikte dus 6 adressen.
Je kunt er - uitgaande van DMX512 max. 512 bytes uit douwen, dus max. 512 adressen. Dat heet dan een 'universe'.
Wil je meer (of heb je overlappende adressen), dan moet je een 2de universe beginnen. Volgens mij is het RS845. Maar dat vertelt wikipedia je wel.

Ik heb geen idee hoe je dat in een WAGO PLC frot (vooral die start sequence zou nog wel eens een dingetje kunnen zijn). Ook niet of die 250kbps haalt.

Ik had het destijds in een AVR zitten die met een simpel protocolletje via RS232 vanuit de PC commando's kreeg om bepaalde adressen een bepaalde waarde te geven. De AVR had een memory map (ik ging niet verder dan 128 bytes, voor die toepassing ruim genoeg). En die zorgde ervoor dat de sequence steeds herhaald werd zodat de PC wat heeeeel anders kon gaan doen. In dit geval dus 'lampjes op een bepaald patroon zetten' en meer hoefde niet.

@henri: je kunt natuurlijk ook heeeeel vies dat met een separate uitgang oplossen. En dan hard-wired ORen (of ANDen, ik heb de logica ff niet voor me). Hoef je niks met die UART te knoeien

Op zondag 5 januari 2025 21:53:06 schreef EricP:
@henri: je kunt natuurlijk ook heeeeel vies dat met een separate uitgang oplossen. En dan hard-wired ORen (of ANDen, ik heb de logica ff niet voor me). Hoef je niks met die UART te knoeien

Dat kan in dit geval niet want het is een bestaande PLC.

Wat denk je wat het BREAK bit in een UART doet? => Juist precies dit, er zit een OR gate in die de TX lijn hard op actief schakelt. Zo vies is dat dus niet.
(Op dezelfde manier kun je ook een MARK maken, zit ook in veel UARTs)

Ik kan me ergens van heel lang geleden herinneren dat je 2 of 3 dummy bytes moest verzenden voor die break in DMX, ik zal het nog eens effe bekijken.

-edit-
In het wikipedia artikel staat inderdaad dat de minimum break 92us moet zijn. En de MAB 12us (is hoog tijd na de break, Mark After Break).
Die 44 us klopt dus niet.

1 bit MAB geeft dus een baudrate van 1/12 μs => 83333 bits/s.
92 bits low bij 11 bits (start+8 data+2 stop) 11/92 μs => 119565 bits/s

Als je de UART dus op 115k2 zet en je verstuurd 1 byte is je MAB 8.68 us formeel te kort maar de receiver zou die correct moeten ontvangen.
Maar daar tussenin moet je de UART nog omprogrammeren en haal je die timing wel.
De BREAK wordt dan 95,49 μs, binnen spec dus.

Dat kan in dit geval niet want het is een bestaande PLC.

En waarom kan dat daar dan niet? Timing is niet kritisch, je zou het zelfs met een relais kunnen doen (over 'vies' gesproken ).

Wat denk je wat het BREAK bit in een UART doet? => Juist precies dit, er zit een OR gate in die de TX lijn hard op actief schakelt. Zo vies is dat dus niet.
(Op dezelfde manier kun je ook een MARK maken, zit ook in veel UARTs)

Dat hangt erg van de UART af. Ik ken wel wat controllers waar het anders in elkaar zit. Maar in de context van dit verhaal verder niet zo relevant. Niemand (nou ja, bijna niemand) weet wat erin zit en waarschijnlijk ook niet hoe je dit soor dingen aanstuurt.

1 bit MAB geeft dus een baudrate van 1/12 us => 83333 bits/s.
92 bits low bij 11 bits (start+8 data+2 stop) 11/92 us => 119565 bits/s

Als je de UART dus op 115k2 zet en je verstuurd 1 byte is je MAB 8.68 us formeel te kort maar de receiver zou die correct moeten ontvangen.
Maar daar tussenin moet je de UART nog omprogrammeren en haal je die timing wel.
De BREAK wordt dan 95,49 us, binnen spec dus.

Overigens weet ik vrij zeker dat die timing niet zo kritisch is. Als in: er is geen enkele adressering en het is niks meer dan een stel bytes naar buiten pompen. Ergens moet men weten wanneer dat begint. Dit is het trucje daarvoor.
Die BREAK wordt gedetecteerd en daarna moet er 'even' rust op de lijn zijn - dat zal wel nodig zijn om het start bit te kunnen detecteren.

Die 44μS is natuurlijk de tansmissietijd voor 1 byte. Dat komt met 11 bits overeen met 250kbps, zo uit het hoofd... (4μS per bit, dan ben je er).

[edit]Wikipedia is het met me eens: die BREAK en MAB tijden zijn minima.

Het is dus veel simpeler: Je blaft er ALTIJD 512 bytes uit.

Ofwel: tijdje niets en dan een Start en dan 512 bytes eruit blaffen. TOPPIE, dat moet wel lukken. De tijd tussen de frames heb je nodig om je nieuwe byte in de UART te zetten,d us die heb je altijd wel...

De WAGO PLC heeft een ingebouwde uart met RS485 driver, daar kun je niks aan veranderen.

Je MOET een break op de lijn zetten, dat is formeel een "framing violation" van het serieel protocol, daar reageert de ontvanger namelijk op (geeft een special status bit in de UART RX) dat is de trigger voor de ontvanger om de rits van maximaal 513 bytes te ontvangen. (Je mag namelijk ook slechts 2 bytes verzenden)

Om zoiets te maken moet je dus zorgen dat je stop bit dus laag is gedurende de verzending van een normaal byte om die "violation" te maken. Of je maakt botweg de TX lijn laag gedurende X tijd > frame tijd.

Dat is inderdaad nogal verschillend voor alle UART chips die in de markt zijn. Maar dat wil niet zeggen dat het op een WAGO PLC niet kan. Vaak zijn de API's om de UART aan te sturen van buiten beschikbaar.
Zeer grote kans dat deze PLC CodeSys doet. Dan moet je in de library even kijken op je via het functieblok de BREAK functie aan kunt zetten.
(Site codesys is nu offline kan het niet opzoeken nu)
Kan dat niet, moet je met de baudrate gaan rommelen zoals ik in optie 1 zei.
(Maar in Codesys kan dat ook wel een uitdaging zijn om dat snel te doen)

De timing is ook niet heel kritisch, break TX >= 92 μs en de ontvanger moet >= 88 μs herkennen. Daar zitten dus die 2 bytes-break die ik al eerder opnoemde wat ik me zo uit mijn hoofd herinnerde.

Mark is hetzelfde verhaal, TX >=12 μs en de ontvanger moet >= 8 μs herkennen.

De timing tussen de bytes is niet heel kritisch.

Dat het vaak wel werkt buiten spec wil niet zeggen dat het goed is, kom ik weer op mijn stokpaardje: Niet doen want je komt uiteindelijk toch in de problemen dat het in een keer niet meer werkt.

Op zondag 5 januari 2025 22:45:35 schreef High met Henk:
Het is dus veel simpeler: Je blaft er ALTIJD 512 bytes uit.

Dat moet je dus niet doen wil je snel kunnen updaten, dan worden je cycletijden langer. (zijn er trouwens 513)
En dat is formeel ook buiten spec, na die rits moet je nog steeds een break sturen. Soms werkt het, soms niet.

-edit-
Nog wat, ik sta er niks van te kijken dat er voor CodeSys een standaard DMX driver is. Dan is het al een stuk simpeler.

Ik geloof ook dat je op die Wagos een eigen C programma kunt draaien (is intern linux), met native interface te koppelen. Dan kun je het zelf maken als je wilt. (zal nog een hele uitdaging zijn denk ik).

Maar het grootste probleem denk ik dat die 250 kbits rate wordt.

Ik kan mij niet voorstellen dat een PLC hier bij moderne fixtures handig voor is, maar ik ben wel benieuwd of het lukt..

Voor het beantwoorden van zo een vraag van een buurman zou ik niets gaan ontwikkelen maar een open-source oplossing op goedkope hardware downloaden.

Wago 750-652

als ze 28 kratjes bier minder kopen hebben ze hem.

https://www.wago.com/nl/d/15925

Waarom niet gewoon een Raspi, of een RS485 converter van een paar euro aan een oude laptop of zo? Ik zie ook niet in waarom je dit in een PLC zou willen doen. Nu ben jij straks ook de enige die iets aan die PLC kan veranderen.

Je schrijft het niet expliciet, maar ik begrijp dat je de DMX master wilt maken, geen slave device, toch? Een slave in die PLC lijkt me een uitdaging, want het zal moeilijk worden om die tijd tussen de pakketten te detecteren, die is veel korter dan de normale cyclustijd.

Op maandag 6 januari 2025 11:46:25 schreef SparkyGSX: Een slave in die PLC lijkt me een uitdaging, want het zal moeilijk worden om die tijd tussen de pakketten te detecteren, die is veel korter dan de normale cyclustijd.

Dat heeft toch eigenlijk niks met de cyclustijd te maken, het is dan ook gewoon mogelijk met de RS485 kaartjes zoals aangegeven.
Met de RS485 op de PLC zelf is het niet mogelijk. Maar hij wil idd een master maken.

Als het met een PLC moet zou ik zelf kiezen voor een gateway ModbusTCP naar DMX.

Zelf geen ervaring met e!COCKPIT. Is blijkbaar een eigen codesys variant.
Maar ik heb van anderen er niet veel goeds over gehoord.
Maar als die een DMX master kunnen maken zou het in CodeSys3.5 ook moeten kunnen zou ik zeggen.

Op maandag 6 januari 2025 12:32:34 schreef GJ_:
Als het met een PLC moet zou ik zelf kiezen voor een gateway ModbusTCP naar DMX.

Als zoiets bestaat is dat wel de mooiste oplossing. Dat werkt gegarandeerd.

[Bericht gewijzigd door henri62 op maandag 6 januari 2025 13:01:21 (11%)]

Op maandag 6 januari 2025 12:54:53 schreef henri62: Als zoiets bestaat...

Daar is wel het een en ander voor te vinden.

Op maandag 6 januari 2025 11:46:25 schreef SparkyGSX:
Waarom niet gewoon een Raspi, of een RS485 converter van een paar euro aan een oude laptop of zo?

Dat lijkt hier inderdaad een geschiktere oplossing, in een PLC zou ik dit niet direct gaan zoeken/bouwen.

Om de eenvoudige reden dat ik in een PC niets kan schrijven?
arduino of PLC lukt wel, maar PC is enorme overhead en hoop ellende die ik niet snap......

daarbij is een PLC degelijker dan een PC.
Echter de WAGO gaat hem niet worden... Bleek een veldbuscoppelaar voor MODbus (RTU) te zijn.

Vond nog wel Siemens S7 300, maar dat is allemaal Profibus, dus gaat hem ook niet worden.
ben nog even bezig met een andere PLC.

Ik kan me geen PLC bedenken die dit op de aanwezige RS485 kan. Die profibus op die 300 is ook RS485, maar daar krijg je echt geen DMX uit.

Ik ga mee met de rest: neem een Rpi en struin internet af naar DMX op Rpi. Ik denk dat je dan het snelste klaar bent.

[Bericht gewijzigd door GJ_ op maandag 6 januari 2025 16:19:35 (30%)]

Het is een carnavalswagen, het ding moet het 2 dagen doen, toch? Hoe degelijk moet het zijn, als je een oud laptop met een converter hebt van een paar euro, en een reserve laptop met een reserve converter?

Misschien is dit juist wel een leuk projectje om iets anders te leren dan dat wat je al jaren doet. Op een PC, met windows of linux, kun je dit maken met Python, of C, of voor mijn part visual basic of C# als het echt moet (zou ik niet doen, maar het kan). Je zou dat kunnen doen met een USB naar RS485 converter, of met een Arduino met een RS485 line driver, die je via USB (virtuele seriele poort) aanstuurt. Als je alleen één of een paar vaste patronen wilt laten zien, kan het waarschijnlijk ook wel met een Arduino zonder de PC. Dat kan dan een klassieke Arduino zijn, of een ESP32 of zo.

Het voordeel van een Arduino is dat je er ook eenvoudig nog addresseerbare LED strips bij kunt hangen, mochten ze dat willen.

Ik zocht naar "raspberry DMX", en de eerste hit was https://www.bitwizard.nl/shop/DMX-interface-for-Raspberry-pi

Dat is de webshop van REW, als hij er hardware voor heeft, heeft hij vast ook wel simpele demo sofware waar je mee kunt beginnen.

[Bericht gewijzigd door SparkyGSX op maandag 6 januari 2025 16:29:21 (12%)]

De Wago kan het dus.
maar ik heb er nog 1 op het oog die het kan (denk ik)

maar dan zou ik liever een Arduino aan wijden.
is ook een optie

dit moet je helemaal niet in een plc willen doen. Daar is geen enkel voordeel aan. Zeker als je nog na moet gaan denken of je het dmx protocol uberhaubt met een plc gemaakt krijgt.
Ik denk dat je veel makkelijker een kant en klaar opensource projectje kan maken wat draait idd op een laptop of pi en daar een showtje in programmeren.
En dan gewoon een usb naar dmx dongeltje, of je koopt op marktplaats voor een paar tientjes een dmx tafeltje gewoon lekker dedicated, klaar is kees.

Ik heb zelf voor mijn kerst showtje gebruikt gemaakt van xlights als show composer, die kan ook DMX doen, maar ik denk dat de leer curve daar ook wat lastig voor is als het is voor de snelle hulp

met een arduino ben je het snelste klaar denk ik. Daar heb je gewoon kant en klare libraries voor

Jullie vergeten even voor het gemak dat het niet alleen licht is, maar ook beweging met frequentie regelaars, hydrauliek en nog wat meuk.

hoe ga ik dat doen met een PC en alles gesynchroniseerd?

Op maandag 6 januari 2025 16:29:23 schreef High met Henk:
De Wago kan het dus.

Nou ja, de Wago kan het alleen met het speciale communicatiekaartje.
Als je toch een PLC wil gebruiken ziu ik een gateway zoeken.

Op maandag 6 januari 2025 17:23:06 schreef High met Henk:
Jullie vergeten even voor het gemak dat het niet alleen licht is, maar ook beweging met frequentie regelaars, hydrauliek en nog wat meuk.

hoe ga ik dat doen met een PC en alles gesynchroniseerd?

Er was al iets zei je? Hoe deed men dit in het verleden?

Mss is de RevolutionPi iets voor dit project? Deze kan dit met 2 vingers in de neus.

En met Codesys kun je je PLC prog in Ladder bv schrijven, en in NodeRed doe je al de rest van je gekke dingen. Heb je in paar avondjes wel draaiende, en zal ook draaien als ze de stekker insteken op hun chinees generatorke.

Maar kost ook wat...

Op maandag 6 januari 2025 18:45:08 schreef Sine:
[...]

Er was al iets zei je? Hoe deed men dit in het verleden?

losse DMX mengtafels
en freq regelaars vast.

Maar ze gaan nu voor een A wagen dus stuk groter en meer beweging..

ik ga woensdag even kijken voor die andere PLC en anders idd een arduino. voordeel is dat ik die wel weer aan een PC kan hangen met geluid.. Dus dat zou helemaal een mooie combinatie zijn. een PLC aan de PC hangen kan wel, maar is heel wat lastiger.

echter bij een arduino moet je weer allerhande shields gaan kopen/bouwen... en dat is helemaal niet handig.