[industrial ethernet] real time eisen

[Verwijderd]

Ik heb het volgende probleem:

Voor een klant dienen we zo'n 480 voedingen aan te sturen. Middels een multicast message moeten we in staat zijn om bij alle voedingen tegelijkertijd de setpoint kunnen verhogen. Met tegelijkertijd bedoel ik een interval in de trant van 0.01 seconde.

Wij hebben daarbij voorgesteld canbus te gebruiken omdat dit een deterministische bus is. De klant wil echter graag dat er industrial ethernet gebruikt wordt.

Mijn vraag is, is industrial ethernet daar wel geschikt voor? Naar mijn weten is industrial ethernet niet deterministisch. Hoe kan ik berekenen wat het maximale tijdsverschil is dat een frame wordt afgehandeld?

Een laatste optie is hardwired een synchronisatiesignaal naar de periferie te sturen, je verstuurd dan een verzoek om een setpoint te wijzigen en middels het synchronisatiesignaal wordt de boel dan daadwerkelijk uitgevoerd, dit is echter geen fraaie optie.

Ik heb wel iets gelezen van IGMP snooping maar nergens kan ik exact achterhalen hoe "real time" ik industrial ethernet kan krijgen.

[ Voor 8% gewijzigd door Verwijderd op 26-01-2005 09:24 . Reden: Stuk over snooping toegevoegd ]

[reddog33hummer]

Industrieel ethernet.... ik weet niet hoeveel dat verschilt met normaal ethernet.
Maar voor normaal ethernet hangt het af of die motoren ook terug praten. Als je het one way gebruikt Dan is de maximale tijd 2,5 ms (max doorlooptijd ethernet) mits het paket niet verloren gaat. Als ze terug praten dan krijg je een kans verdeling met colissions, waarbij elke collision 5 ms kost om te detecteren en dan de random wachttijd. Dit zou je kunen verkleinen door collision domeinen te maken.

Ethernet is niet echt realtime. Het kan voorkomen dat je heeeeeel laat een response krijgt. Maar de kans daarom is laag. Dus het hangt van je omgeving af, en hoeveel industrieel ethernet verschilt. Mijn advies pak het boek van tanenbaum erbij, daar staat in hoe je dat berekenen kan.

http://www.uga.edu/netinfo/netguide/rtimecalc.html

[ Voor 33% gewijzigd door reddog33hummer op 26-01-2005 13:43 ]

[Verwijderd]

echt een google vraag >>> http://ethernet.industrial-networking.com/

maar je idee is volgens mij juist, can-bus is voor zo'n toepassing veel beter aangezien daar geen collisions op voorkomen (tot max 70% belasting werkt het fantastisch, 70% ethernet belasting hoe snel ook is dramatisch )

[Verwijderd]

Verwijderd schreef op woensdag 26 januari 2005 @ 14:50:
echt een google vraag >>> http://ethernet.industrial-networking.com/

maar je idee is volgens mij juist, can-bus is voor zo'n toepassing veel beter aangezien daar geen collisions op voorkomen (tot max 70% belasting werkt het fantastisch, 70% ethernet belasting hoe snel ook is dramatisch )

Ik vind het geen echte google vraag, ik ben ook in staat om zoektermen in google in te tikken en ja, deze site ben ik daarbij oa ook tegengekomen. deze site ben ik (uiteraard) al tegengekomen. Hierop vind ik echter niet de informatie die ik zocht. Ik wou vooral weten wat de worst case scenario's zijn bij het verzenden van de frames via ethernet.

De bedrijven die positief zijn (Rockwell automation) geven echter geen duidelijke fundering voor hun mening. Ik weet dat siemens bezig is met een realtime ethernet variant die ze willen onderbrengen binnen hun "profibus club" maar daar kan pas in de loop van het jaar wat van verwacht worden.

Cisco levert realtime switches maar dat veranderd in feite niets aan het collision verhaal, alleen de overdracht van de switch en het verbeterd ondersteunen van multicasting.

Ik zal in het boek van Tanenbaum kijken naar de berekeningen mbt het ethernet netwerk.

[TNijpjes]

Er zijn tegenwoordig PLC leveranciers die Real time met garantie van de delaytijden informatie over ethernet kunnen sturen. Voor profibus is bijvoorbeeld profinet ontwikkeld. Dit wordt vooral door Siemens gesteund. Verder dacht ik dat ook Can ook al via Ethernet kan communiceren. Ik weet niet wat de bovenliggende besturing is, maar persoonlijk heb ik goede dingen gehoord over Allen Bradley. (Tip ga direct naar AB support, deze kunnen veel nuttige info geven) (hmm zie dat KlukKluk het zelfde denkt).

Vraag me alleen af waarom binnen 10ms je alle setpoint wil veranderen. Is de met verificatie? De Can bus determistisch is klopt, Profibus ook. Can bus heeft het voordeel dat alleen data verstuurd wordt als er data verstuurd moet worden. Profibus en dergelijk blijven constant data versturen. Dit betekend dat Can een gunstigere belasting KAN hebben.

Linkje CAN -> Ethernet http://www.phytec.com/can...terface/canethgateway.htm
Linkje Profibus -> Ethernet https://mall.automation.s...ta/500/en/100210376K1.PDF

[Verwijderd]

Er staan honderden voedingen parallel te draaien dus als het setpoint omhooggaat moeten ze allemaal "tegelijk" op het nieuwe setpoint gaan draaien anders gaan zaken als terugwatt (voeding neemt vermogen op ipv geven, zeer schadelijk) spelen.

Ik dacht zelf dat het profinet systeem nog niet volledig gereed was, het probleem is wel dat aan de voedingzijde evt. een siemens plc systeem gebruikt kan worden maar voor de aansturing zal een pc gebruikt worden die waarschijnlijk onder linux gaat draaien icm epics als scada systeem. Een pci kaart oid zal dan nodig zijn.

Voor epics weet ik niet of siemens al drivers heeft. Eventueel kan ik op basis van c++ functies die die kaart aansturen zelf drivers programmeren, heb jij (crosmozes) ervaring met profinet?

[ Voor 55% gewijzigd door Verwijderd op 28-01-2005 11:25 ]

[TNijpjes]

Persoonlijk heb ik nog geen ervaring met Profinet, alleen maar wat info van Siemens gelezen.
Blijf het wel een riskante bezigheid als de setpoint generatie zo nauwkeurig komt. (als je bang bent voor terug voeding, kan de kleinste afwijking al problemen geven) Lijkt me verstandiger om het systeem robuster te maken qua terug voeding.
Maar als je praat over honderden voedingen, denk dat je bij ieder bus systeem een probleem gaat krijgen. Of je moet aan een broadcast systeem gaan denken. Weet niet welk bus systeem dit met realtime garantie kan doen. Wat ook o.a. CAN bus heeft zijn beperkingen alleen al qua maximaal aantal slaves per netwerk.
Denk dat er eerst een goed gekeken moet worden naar de applicatie voordat er een bus gekozen wordt. Vooral naar de mogelijke gevolgens en kans op communicatie verlies. (bij broadcast b.v geen controle op ontvangst zonder collision probleem. )

But just my 2 cents

O, voor ik het vergeet, kan epics niet via OPC met Siemens praten. Er zijn genoeg OPC drivers te vinden die een link kunnen leggen tussen Siemens en Linux. Hierdoor kan er eenvoudiger met een PLC gesproken worden. Tenminste als je al een PLC wilt gaan gebruiken voor het aansturen. Waarom niet rechtstreeks vanuit de PC met alle slaves praten.

Kortom, denk dat de keuze niet eenvoudig zal worden.

(Ben wel geïnteresseerd in de uiteindelijke oplossing, en ook de toepassing )

[ Voor 22% gewijzigd door TNijpjes op 01-02-2005 20:46 . Reden: OPC info toegevoegd ]

[Verwijderd]

De definitieve toepassing zal nog even op zich laten wachten, de gegevens die ik vroeg waren nodig voor een offerte, waarschijnlijk zal er ook een synchronisatiesignaal meegegeven worden, ik zal zeker wat via dit topic laten horen indien het project gestart wordt (waarschijnlijk zal dat de komende maanden gebeuren). Iig bedankt voor de info!

De robuustheid zal wel goed komen, mijn bedrijf is gespecialiseerd in grote voedingen, een trend in de markt is een modulair systeem van meerdere voedingen die parallel gaan draaien en daar wil men in gaan duiken.

[ Voor 25% gewijzigd door Verwijderd op 01-02-2005 21:36 ]

[The_Butler]

Mijn bedrijf is gespecialiseerd in safety systems, en safe ethernet is een van onze producten. Ik weel niet hoe inteligent joun controllers zijn, maar ik zelf zou in dit geval een commando + nieuw setpoint (met bevestiging) naar iedere unit sturen, het commando bevat een tijd wanneer het niewe setpoint van kracht is (bijv. 3:00:00.000 AM), via een SNTP broadcast kan je er voor zorgen dat alles de juiste tijd heeft, hoewel in dit geval de scantijd van de PLC's (+/- 6 ms, 4 ms als je een super klein programma draait) roet in het eten kan gooien. Maar ik begin nu teveel op iemand van de afdeling verkoop te lijken. wat ik zou doen:

stuur de informatie naar iedere voeding
wacht op een gezonde respons van iedere voeding
geef een startsein wanneer het nieuw setpoint van kracht wordt


<edit>
Is de order toevallig voor een nieuwe chloor fabriek?
<edit>

[ Voor 6% gewijzigd door The_Butler op 03-02-2005 22:48 ]

[Verwijderd]

Ik neem aan dat die chloorfabriek niet in Australie zit,
het idee van een timestamp of een synchronisatiesignaal was ook hetgene wat bij mij speelde

[Verwijderd]

480 voedingen binnen 0,01 seconde het setpoint verhogen? Aan wat voor voedingen moeten we dan denken?

Reken voor het verzenden maar 20ms over ethernet. Ik neem aan dat alle 480 voedingen niet binnen een straal van 100 meter van de PLC/PC zitten dus je bent zowiezo switches nodig. Hierdoor krijg je altijd een extra delay.

De intelligentie van je voeding is mij onbekend, maar Modbus over TCP/Ip zou een oplossing kunnen zijn. Hieronder een stuk uit de laatste mailing van Modbus http://www.modbus-ida.org/default.htm:

Modbus frames: serial vs.
Sentekin Can wrote: How does serial
Modbus message, which is variable
length, form into fixed length Ethernet
frame?
Jiri Baum replied, “The TCP part of
TCP/IP simulates a continuous
connection. Just ignore the whole frame
thing and send your data. The TCP/IP
stack will break it into packets, send
them, retransmit them if they get lost
or corrupted, etc.”
Another reader suggested, “Modbus
TCP is Modbus RTU that has been
enveloped into a TCP data header.
Layer 1-6 is all TCP/IP data header.
Layer 7 is the application layer, which
holds the Modbus RTU data frame.
The only difference is that NODE
ADDRESS=1 as default.
“Function code is Modbus function
code to read or write same as RTU;
target register is the same as RTU;
number of registers is same as RTU;
data out is same as RTU and data in is
same as RTU; and the CRC check is the
same as RTU. The Modbus message is
not fixed. Many people will send a
Modbus TCP message over Ethernet to
serial converter, which strips out the
TCP/IP header and sends the Modbus
RTU message to the remote serial
device. By changing the Node address
to the remote node address this makes
it possible to communicate to serial
devices over Ethernet.”
Lynn Linse added, “I am not sure what
you mean by ‘fixed length Ethernet
frame.’ Ethernet has a minimum size to
enable collision detection (I think it’s 64
bytes?). However the link, IP, and TCP
headers occupy most of this. Any
Modbus/TCP message will be larger
than this min size.
Max Modbus serial message is 255 bytes
(3 + 250 + 2); Max Modbus/TCPmessage turns out to be 259 bytes (6 +
3 + 250); Max Ethernet frame is 1500
bytes (given no fragmentation). So
Modbus creates no size problems under
Ethernet.
“Or perhaps you mean since Modbus
RTU’s length is ‘felt out’ by watching
for time gap; how is Modbus/TCP
length detected? The Modbus/TCP
header includes a length byte, so it is
explicitly defined within the first six
bytes.
“In other words, the Master in your
case does not have the slightest idea of
where the ‘reply’ came from (the store
& forward machine in your case) – it
simply assumes it is from the slave and
processes it as such.
“As a practical solution, you may want
to insert a delay, so your Master is
‘deaf ’ for the amount of time the store
& forward machine ‘talks’.”

Je hebt dus zeer waarschijnlijk meer dan genoeg bits ter beschikking om je nieuwe waarde in 1 Ethernet frame te verzenden. Als je voedingen intelligentie bezitten zou je kunnen volstaan met het verzenden van de + of - waarde (dus zoveel meer of zoveel minder) om de lengte te beperken.

Hou wel rekening met invloeden op het energienet! 480 voedingen die binnen 0,01 seconde hun setpoint gaan verhogen kunnen een aardige invloed op de hoofdvoeding hebben. Wellicht is het helemaal niet verstandig om ze allemaal gelijktijdig te gaan verhogen?!

[Verwijderd]

OOPSIE!!!

Ik las onze handleiding verkeerd: het is 0,20ms in plaats van 20ms.

Ethernetpaket senden = 0,20 ms
Verarbeitungszeit HauptGerat senden = 3,00 ms
Anfrage (( 8 Byte + 3Byte(Sync.)) x Zykluszeit ) = 2,75 ms
Verarbeitungszeit Slave = 2,00 ms
Antwort ((5 Byte+3 Byte(Sync.) + n ) x Zykluszeit = 3,50 ms
Verarbeitungszeit HauptGerat empfangen = 3,00 ms
Ethernetpaket empfangen = 0,20 ms
------------------
Gesamtzeit = 14,65 ms

[Verwijderd]

Maak je maar geen zorgen over het energienet, dmv filteren en de eigen centrale zal dit geen probleem zijn, nauwkeurigheid is het belangrijkste en het net kan deze belasting wel aan (condenstatorbanken)

[Verwijderd]

Verwijderd schreef op dinsdag 08 februari 2005 @ 15:58:
Maak je maar geen zorgen over het energienet, dmv filteren en de eigen centrale zal dit geen probleem zijn, nauwkeurigheid is het belangrijkste en het net kan deze belasting wel aan (condenstatorbanken)

Ok, heb je al een idee hoe je het gaat aanpakken? Ga je het met echte Ethernetnodes doen of met een protocol-over-Ethernet?

Wat moet ik me voorstellen bij de voedingen? Is het voor gelijkspanning of anders?

[Verwijderd]

Je noemde Rockwel automation, kijk dan eens hier: www.hima.com

Met Profibus red je dit IMHO nooit, zelfs canbus lijkt me lastig.
In basis is Profibus een treintje met data in de wagonnetjes. Voor elke node heb je een wagonnetje nodig en het treintje rijdt cyclisch door de draden. Het aantal wagonnetjes is beperkt.
Bij Canbus kan in basis elke node zelf een treintje starten met data voor 1 of meerdere ontvangers.

Je zou een aantal modbus-IP-gateways kunnen gaan gebruiken die elk een aantal voedingen als slaves hebben. Elke gateway hangt aan ethernet en werkt als lokale master die de data of analoog of via RS485/Modbus wegschrijft naar je voedingen en eventueel de actuele waarde uit je voedingen leest. De gateway verstuurd vervolgens alle nieuwe waarden naar je PC/PLC. Voordeel is dat je rekenkracht lokaal houdt en je met truucjes een groter deel van een ethernetframe kunt benutten.
Voor zover ik nu weet kan elk frame maar data voor 1 adres bevatten. Met de masters verminder je het aantal adressen in je systeem.

[Bierkameel]

Ik weet niet precies waar het over gaat maar hebben die dingen een naam of nummer zodat je kan kijken hoe ver ze weg staan in het netwerk?

Dan zou je de voedingen die vooraan staan een pakketje sturen met een iets langere delay en dan de achterste voedingen geen delay zodat alles tegelijk omgezet word.
Dit is dan wel precisie werk en erg moeilijk

[Verwijderd]

zoals ik het nu bekijk zijn er 3 oplossingen mogelijk, ik laat het protocol gemakshalve even achterwege

- Broadcast versturen, nadeel is dat je niet weet of de berichten allemaal zijn ontvangen en of ze tegelijk zijn aangekomen. Voordeel is dat je maar 1x hoeft te versturen

- Afzonderlijk een bericht sturen met timestamp voor uitvoering. Periodiek een synchronisatiesignaal om de tijd gelijk te krijgen bij al de componenten. Je kunt de voedingen evt laten controleren of ze binnen een bepaald interval een synchronisatiesignaal hebben gekregen en dit laten meewegen in de bevestiging. Nadeel, meer tijd nodig. Voordeel, je weet dat alles is binnengekomen.

- Zelfde als vorige maar dan zonder timestamp maar met een hardwired timestamp signaal, bij een hoog signaal dient de opdracht te worden uitgevoerd, nadeel is de externe bedrading, voordeel is dat de tijd tussen de voedingen niet hoeft te worden gesynchroniseerd.

De tweede oplossing lijkt mij de meest veilige en daarna kan wel voor het bussysteem worden gekozen. De settings hoeven niet vaak verandert te worden maar wel tegelijk