2 delta plc's en 2 LORA radio modules

M-i-c-h-e-l

Golden Member

Goedenavond,

Ik ben bezig om de communicatie op te zetten tussen 2 PLC's.
De master PLC moet data kunnen opvragen van de slave PLC.

Het zijn 2 Delta DVP-12SE PLC's.
De ingebouwde functionaliteit hiervoor heet "Data exchange".
Protocol is Modbus over Tcp/IP.

Wanneer de 2 PLC's worden verbonden dmv een netwerkkabeltje, dan wordt de registerdata netjes uit de Slave gelezen en ontvangen op de Master.
Tot zover alles naar wens.

Nu is het de bedoeling dat de verbinding niet loopt via een netwerkkabeltje maar via 2 Long Range Radio modules. En dit krijg ik niet voor elkaar. De leds op de modules laten zien dat er wel communicatie is.
Dus baudrate, parity ed komen overeen.
De modules zijn de Ebyte E90-DTU 433C30E.

De configuratie is dus deze:

Master PLC <----> Lora Server ....... Lora Client <----> Slave PLC.

Wanneer ik in plaats van de PLC's 2 computers neem, dan kan ik netjes tekst heen en weer verzenden.

Iemand een idee wat ik fout zou kunnen doen?
Kan het zijn dat de Delta PLC niet helemaal de modbus standaard volgt?

Bestaat er een stuk hardware waarmee ik de modbus kan afluisteren?
Met software lukt dat niet omdat het eea met ip adressen op elkaar afgestemd is en mijn computer daar niet tussen komt zeg maar.

Kan het misgaan in de master/slave en client/server configuratie?

Iemand ervaring met een dergelijke configuratie?

Een TcpIp verbinding met simpele LoRa tranceivers???
Zijn 2 ESP modules dan niet veel handiger? (die zijn bedoeld om met TcpIp te werken)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
M-i-c-h-e-l

Golden Member

De modules zijn ervoor gemaakt Arco.
Dan zou je verwachten dat het ook werkt.
Het werkt ook wel met 2 PC's.
Maar met 2 PLC's dus niet. De vraag is dus waarom dat niet werkt.

Maar die modules zijn niet gewoon een transparant pad waar je aan een kant iets instopt en het er dan aan de andere kant weer uitkomt. Althans, die modules heb ik nog nooit gezien. Lora is daarbij ook nog eens bedoeld voor hele lage datarates.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
M-i-c-h-e-l

Golden Member

De modules hoeven niet high speed te zijn.
Er moeten periodiek registerwaarden uitgelezen worden.
Ga maar na hoe weinig data dat is.

De modules werken in TCP client/server modus.
Met 2 computers verbonden via de LORA modules werkt dat inderdaad transparant, beide richtingen op.
Wat je vanaf pc1 verstuurt, komt netjes aan op pc2.
En andersom ook.

Ik zou verwachten dat het dan dus met 2 plc's ook zo zou werken.
Maar dat is dus niet zo.

De vraag is nu waarom dat niet zo is.

Kun je niet een gewone seriele verbinding via die LoRa's opzetten?
TcpIp geeft een enorme overhead met kans op problemen en is bij een directe verbinding tussen 2 apparaten niet echt zinvol...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
M-i-c-h-e-l

Golden Member

Je kunt met die modules inderdaad ook een RS485 verbinding maken.
Maar we zijn nu bezig te kijken of er een TCPIP verbinding gebruikt kan worden in combinatie met de PLC's die uiteraard ook TCPiP ondersteunen.

Het is een experiment om te kijken of de Lora modules bruikbaar zijn om Modbus over TCPIP te laten lopen.
Zo ja, dan worden ze later in grotere systemen toegepast.

Voor nu zoek ik dus de oorzaak van het niet ontvangen van het response modbus bericht door de PLC master.

Ik snap dat er genoeg alternatieven zijn, maar dat is de kwestie nog niet.

Als het werkt met 2 pc's probeer dan een pc en plc, met pc als zender.

Als je dan niets ontvangt dan weet je tenminste dat het alleen de ontvangende plc kan zijn.

Op 22 oktober 2021 20:59:45 schreef M-i-c-h-e-l:
Voor nu zoek ik dus de oorzaak van het niet ontvangen van het response modbus bericht door de PLC master.

Misschien door de lange delay in het pad? De zender krijgt pas na lange tijd een antwoord terug. Misschien is er dan een time-out afgelopen waardoor de zender het als mislukt beschouwt.

"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Peter112

Special Member

TCP/IP Retransmission Timeout kun je die niet ergens verhogen, ik heb even gezocht op jou type plc maar daar bestaan weer tig subtype's van.

Timeout is TTL (Time To Live)

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com

Ik heb even kort door de handleiding van dat ding gestnuffeld:

https://www.cdebyte.net/uploads/201921823/E90-DTU(433C30).pdf

Hij ondersteund RS232 en RS485, en hij vermeld ook dat hij voor modbus bedoeld is.

Maar er zit geen ethernet connector op.
De string "tcp" komt niet voor in die handleiding.

Op 22 oktober 2021 20:01:22 schreef M-i-c-h-e-l:
De modules werken in TCP client/server modus.

???
Er zit geen ethernet op de LORA modules. Alleen RS232 en RS485.
(https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol bestaat, maar het is onwaarscheinlijk dat dit gebruikt of ondersteund wordt).

Modbus over RS485 ondersteund 2 verschillende standaarden. een oud "ascii" formaat en een wat compacter formaat. Gebruiken alle onderdelen hetzelfde formaat?

De data op Modbus over RS485 zijn in standaard serieel formaat. Met een RS485 transceiver (een IC van EUR2) kan elke microcontroller dat formaat uitlezen. RS-485 <=> USB printjes zijn ook vrij gebruikelijk. Ik denk dat je hiermee en met wireshark het netwerk verkeer in de gaten kan houden, maar ik weet niet zeker of Wireshark kijkt naar andere interfaces dan Ethernet.

Modbus RTU verkeer kun je ook bekijken en analyseren met een logic analyser.
Met onderstaand kastje (Kan voor <EUR10 op Ali) en Sigrok / Pulseview kun je Modbus (en 100+ andere protocollen) bekijken op je PC. Om het wat robuster te maken is het wel aan te raden er (ook) een RS485 receiver tussen te hangen.

https://www.antratek.nl/logic-analyzer-25mhz-8-channel
https://sigrok.org/

Wireshark werkt grotendeels op "pakket" basis, terwijl een logic analyser rechtstreks de data sampelt (Maar alleen eenen en nullen, en niet de analoge signaal nivo's. Daarvoor heb je een oscilloscoop nodig)

M-i-c-h-e-l

Golden Member

Dank voor het meedenken allemaal.

@Kortsluiting_Online Ik noemde in de startpost het type E90-DTU 433C30E.
De E staat voor Ethernet.
De handleiding is hier te vinden.

Shiptronic

Golden Member

link naar de handleiding werkt niet.

Wie de vraag stelt, zal met het antwoord moeten leren leven.
M-i-c-h-e-l

Golden Member

Nogmaals: ebyte.com/en/product-view-news.html?id=407

[Bericht gewijzigd door M-i-c-h-e-l op 24 oktober 2021 16:58:30 (19%)]

Peter112

Special Member

nog steeds n(g)i(n)x 400

https://www-ebyte-com.translate.goog/en/data-download.html?_x_tr_sl=en… maar dan beland je in een enorme brei van downloads

[Bericht gewijzigd door Peter112 op 24 oktober 2021 17:07:20 (77%)]

M-i-c-h-e-l

Golden Member

Nou moe, net werkte de link wel....
hij werkt ook wel, maar dan moet je ff door "de beveiliging heen".

Dan maar effekes op deze manier:

E90-DTU(433X30).pdf

En nog vorderingen met het project?

Modbus is een vrij eenvoudig protocol, wat het gemakkelijk maakt om problemen op te sporen.

Nu moet je eerst zeker zijn dat je radio verbindingen wel goed werken, en dat de paketten in hun geheel aankomen.

Eerst even een test op socket niveau doen met bvb SocketTest of ander telnet programma.
Wat tekstjes over en weer sturen op poort 502 (standaard modbus poort)

Dan zou ik beginnen met een modbus master simulator op PC op je rf module te zetten en een modbus slave simulator op de andere rf module.
Op beide PC's wireshark installeren en je kan je pakketjes volgen.

Wil je met je PLC die pakketjes gaan sniffen met een externe PC met wireshark, dan zal je moeten investeren in een switch met de functionaliteit "port mirroring". Daar kan je dan het netwerkverkeer ook naar je PC sturen en de paketten volgen.

In wireshark zit reeds het modbus TCP protocol ingebakken, dus het is heel makkelijk om die pakketjes te volgen.

Op 24 oktober 2021 17:34:07 schreef M-i-c-h-e-l:
Nou moe, net werkte de link wel....

De link in de post mist de ":" na de "https".

four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
M-i-c-h-e-l

Golden Member

Bedankt voor het meedenken weer.
Intussen ben ik wat verder gekomen.

Ik ben met wireshark op 2 pc's in de weer geweest.
Ik heb 2 switches met inderdaad port mirroring geconfigureerd.
Ik zie nette modbus frames binnenkomen op de slave plc via de 2 LORA modules. Ik zie op de master PLC een nette modbus frame geresponsd worden.

Ik constateer dat de lora modules juist werken.
Het probleem is nu dat de Slave PLC als data "0001 0000 ....." binnenkrijgt, en "0000 0000 ....." terugstuurt. Hij moet "0001 0000 ...." terugsturen.

De vraag is nu: waarom geeft de slave PLC via Lora modules allemaal nullen terug, maar geeft hij via een netwerkkabel wel "0001 0000 ..." terug?

Ik heb alle mogelijkheden al geprobeerd maar ik kom er niet uit.

Hierbij de configuratie waarmee getest wordt.

M-i-c-h-e-l

Golden Member

Na heel wat geexperimenteer kom ik tot de conclusie dat de radio modules prima werken.

Alleen er zit een timing probleem in de hele communicatie.
De PLC geeft geen mogelijkheid om timing parameters aan te passen.

Het enige wat ik kan aanpassen is de bitrate en air rate op de radio modules.

Een volgende stap is om de "automatische data exchange functie" van de PLC te vergeten en zelf een ethernet-verbinding te programmeren.

Als er al een timeout setting zou zijn, moet die op de ethernet interface van de PLC zitten...

Arco - "Simplicity is a prerequisite for reliability" - hard en software ontwikkeling: www.arcovox.com
Peter112

Special Member

Je kunt udp proberen, daarna op de zendende plc x seconden op antwoord wachten of de ontvanger iets ontvangen heeft. udp = send and forget in principe. Dus de zendende plc moet wachten op antowoord van de andere plc en niet op de op de TCP ack.

M-i-c-h-e-l

Golden Member

Op 2 november 2021 17:49:02 schreef Peter112:
Je kunt udp proberen, daarna op de zendende plc x seconden op antwoord wachten of de ontvanger iets ontvangen heeft. udp = send and forget in principe. Dus de zendende plc moet wachten op antowoord van de andere plc en niet op de op de TCP ack.

Bedankt voor de tip, alleen de PLC's ondersteunen geen UDP.

M-i-c-h-e-l

Golden Member

Op 22 oktober 2021 17:56:31 schreef Arco:
Een TcpIp verbinding met simpele LoRa tranceivers???
Zijn 2 ESP modules dan niet veel handiger? (die zijn bedoeld om met TcpIp te werken)

We gaan inderdaad met ESP32 verder Arco.
Heb jij daar ervaring mee?

Vooralsnog willen we met de ESP32 M1 gaan werken maar die laten nog even op zich wachten door het chiptekort.