Modbus RTU

3 characters de lijn hoog houden klinkt wel erg als een "Break" op de lijn zetten.

Een beetje UART kan dat maar of je dat ook met je USB/RS485 converter kunt doen weet ik niet.

Anders een zien uit te vissen welke chip er precies in je converter zit.
Via de VID code in het register of zo is dat wel uit te vogelen.
Daar zijn er maar een handvol van. De beroemde FTDI/Profilec of CPD21xx etc.

Dan het datasheet opzoeken en kijken of dat ondersteund wordt (via de driver ook dus). Het lijkt me stug dat daar geen API call voor is.

Wat ik vreemd vind:
Je schrijft dat je een error reply krijgt van 'het toestel'.
Ik neem aan dat je met 'het toestel' dat industriële toestel bedoelt.

Een correct geïmplementeerd Modbus protocol betekent o.a. dat het device alleen antwoord geeft als het een geheel correct bericht ontvangt met dus een juiste crc.
Een error reply betekent dan dat in jouw verzonden bericht één of meer parameters niet kloppen voor de betreffende slave. Bijvoorbeeld een foute opdrachtcode, foutief data adres, foutieve lengte enz.

Omdat zowel je PC als de PLC een antwoord geven moeten ze beide een juist bericht verzonden hebben. Weet je wel zeker dat ook de datainhoud van beide berichten het zelfde is ?

Ik ben ook heel benieuwd welke foutcode je krijgt.

Dag allen,
Alvast bedankt voor de antwoorden.

@henri62:
Het is een standaard FTDI chipje dat erin zit.
Ik bekijk of er API's beschikbaar zijn.

@Leo-Bolier:

Inderdaad, de eerste trein is van mijn PC, nadien komt de datatrein van het industriële apparaat.

De errorcode die ik terug krijg is "illegal data adres".
Inderdaad, daarmee kan ik je volgen omdat het toestel toch antwoord en de CRC hiervoor correct moet zijn.

Ik ben er zeker van dat beide berichten qua data hetzelfde zijn, want als ik mijn usb convertor op de datalijn bij op die van de PLC zet en ik sniff de data, krijg ik dezelfde HEX adressen binnen.
Ik verzend dus 1 op 1 hetzelfde...

Ik heb het programma modbus poll als testomgeving, maar zelfs als ik de indentieke HEX string verzend met een eenvoudig terminal programma krijg ik hetzelfde resultaat.

Ik zal de module nogeens op de scoop (een andere dan de reeds geposte) hangen om de details te vergelijken.
Thuis heb ik betere meetapparatuur staan

Dit lijkt te zot voor woorden!

Je stuurt precies het zelfde bericht, met juiste crc, wat ook als zodanig wordt ontvangen omdat je antwoord krijgt.
Maar de ene keer krijg je een correct antwoord en bij de ander het bericht foutief data adres.
Welk pakket je ook gebruikt zou domweg dan niet mogen uitmaken.

Mijn gedachten gingen er in eerste instantie naar uit dat je in het ene geval een programma gebruikte wat automatisch het data adres aanpaste en in het andere geval niet. Ik weet dat er programma's bestaan die een offset zoals binnen plc's gebruikelijk is of was van (20000 of 30000, wat was het ?) automatisch optellen bij het adres wat je op keyboard invoert.

Ook moet je soms uitkijken dat er programma's zijn die bij 1 in plaats van 0 beginnen te tellen. Het gewenste data adres moet je dan 1 hoger kiezen.

Als dat voor de slave niet nodig is (bij elk mij bekend modbus device is dat zo) zou je dan zo'n foutbericht retour krijgen.

Suggesties/vragen:
- Een hex dump van beide uitgaande en retourstrings ?
- Probeer je een lees of schrijfactie te doen ?
- Misschien zinvol om eens een andere instructie te proberen. Bijvoorbeeld instructiecode 17 (11Hex) report slave ident.
Daar wordt geen adres mee verzonden.

Inderdaad...

Neen, ik weet dat er soms met een offset gewerkt wordt, maar vandaar dat ik met een terminal programma werk, om echt elk HEX adresje hetzelfde te hebben.
de 3xx of 4xx reeksen slagen op de functiecodes, holding registers, coils, of je wil lezen of schrijven etc..

Ik heb ook al random registers proberen uit te lezen, op verschillende adressen.

Ik heb ook al het modbus protocol doorgenomen, waar ze spreken dat als je geen party hebt, je verpicht 2 stopbits moet gebruiken om aan de correcte lengte te komen, ook geprobeerd, zonder resultaat...

-Hex dump, hier een printscreen van de vraag en het antwoord(errorcode)

-Ik probeer een holdingregister te lezen.
-Andere heb ik ook reeds geprobeerd, zonder succes.
Ik ben er zeker van dat het om een low level hardware probleem gaat.
Meer screenshots van scoopbeelden volgen...

Ik heb geen testprogramma meer bij de hand om de crc's te controleren maar ik ga er van uit dat jij dat al gedaan hebt en dat daar geen probleem mee is.

Drie dingen die me opvallen:
-1- het adres wat je wilt lezen (C6 68) is wel erg hoog. Wat ik normaliter tegenkom zijn adressen van hooguit een paar honderd. Maar ik neem ook aan dat jouw device blijkbaar zo in elkaar steekt (kan ik ergens de modbus implementatie van dat ding vinden ?).

-2- Het tweede wat ik (nu pas serieus naar gekeken) zie is het verschil in de hardware timing bij een goed en een fout bericht.
Bij een goed bericht gaat aan het begin van jouw transmissie de lijn ongeveer 0,7msec laag (anderhalf bittijd, startbit) alvorens de bitjes uitgaan. Aan het einde gaat de lijn ongeveer 1 bittijd laag. Dat zie je niet bij het foutbericht.
In de reply zie je dat startbit niet maar wel iets wat een stopbit kan zijn.
Hardwarematig is er duidelijk verschil. Maar nog steeds lijkt het dat de slave een goede crc krijgt. Of....heel dubieus, ondanks een niet deugend bericht toch een antwoord geeft...

-3- De screendump geeft aan dat je op 19k2 zit. Klopt ook met je scoopbeeld. Maar op de screendump zie ik ook iets als Custom BR = 9600 en Rx clear = 27. Wat is dat ?

Bij mijn weten kun je met een usb-485 converter de lijnconditie niet met software besturen.

Silence is een hoog op de ingang van de UART dacht ik. Jouw scoopbeeld laat de differential zien maar in elk geval in rust en lang genoeg. Je kunt hier niet aan zien wat een rust op de lijn betekent voor de ingang van de UART.

Ik heb nog nooit een probleem gehad met Modbus en het aantal start en stopbits. Ik heb ooit 1 device meegemaakt wat 8 bits + parity gebruikte. Alle andere devices werkten met 1 start en 1 stopbit en zonder parity.

Kun je toch eens instructie code 17 proberen ? kijken wat voor foutcode je dan krijgt .....

Bij mijn weten kun je met een usb-485 converter de lijnconditie niet met software besturen.

De FT232R ondersteund wel de break. Dus verwacht ik er in de API ook een functie dit dit kan. Maar dat is het probleem dus NIET! Daar hoef je niet verder naar te zoeken.

Het protocol spreekt over een MARK conditie van 3.5 characters, dat is dus een idle line.

Bon, hierbij de prints van mijn scoopbeelden.
Zoals je kan zien zijn beide INDENTIEK, buiten dat er achteraan en vooraan het signaal laag blijft.
Blijkbaar is een MARK line toch geen idle??

Transmit van PLC (en goede reply)

Transmit met rs485 omvormer (en foutbericht als relpy)

Misschien toch eens naar de API kijken...

UPDATE:
Als ik 2 stopbits instel op de software waarmee ik het toesel poll, krijg ik 1x op de 3 berichten goed antwoord.
Blijkt dat de laatste bit dan iets langer laag blijft en de slave dan wel wilt antwoorden.

[Bericht gewijzigd door coldrestart op donderdag 19 maart 2015 18:58:21 (23%)]

Heb je ook als parity "mark" geprobeert, en hoe ziet het scope-beeld er dan uit?

Gek ja, wat ik zo snel gevonden had over modbus is dat het een zou mark moeten zijn. Zelf zou ik verwachten dat het een break (space) is, dus echt de bus driven, dat heb ik andere protocollen ook gezien.

Maar voor hetzelfde kan het op internet ook gewoon fout staan, er staat zoveel onzin op. Ergens proberen een officiele MODBUS spec zien te vinden lijkt me verstandig.

Wat ook kan is dat de module "implemetator" het verkeerd begrepen heeft en een break verwacht. Zal ook niet de eerste keer zijn.

'Mark' haalt niets uit, ik krijg random foutcodes.
Ik doe mijn testen samen met een CP341 kaart van Siemens (die dus wel de slave goed uitleest) en daar kan je enkel none/even/odd als pariteit selecteren, dus ik denk niet dat dat iets oplevert.

Als ik 2 stopbits instel op de software waarmee ik het toesel poll, krijg ik 1x op de 3 berichten goed antwoord.
Blijkt dat de laatste bit dan iets langer laag blijft en de slave dan wel wilt antwoorden.

Nu wordt het wat onduidelijk. Ik had begrepen dat je altijd een foutbericht kreeg vanuit de USB converter; maar nu toch ook wel eens geen antwoord ?

Sorry voor de onduidelijkheid, de slave antwoord altijd, maar soms met een foutcode, soms gewoon goed.

Waarschijnlijk gewoon troep van de vorige foute transmissies.

Ik zou toch eens een break proberen.

De truuk om de timing van 3 characters precies te krijgen is (zonder knoeiwerk met delay loops):

BREAK aanzetten, 3 willekeurige characters transmitten en wachten tot de buffer leeg is, BREAK uitzetten.

Dan lijkt het er sterk op dat je zowel een timingprobleem als een niet correcte Modbus implementatie in dat toestel hebt.

Daarom ben ik nog steeds zeer benieuwd wat het antwoord op instructie 17 is: dat bericht bevat geen data adressen zou dat dus ook nooit als foutcode kunnen geven.

In Modbus is het essentieel dat de slave alleen mag antwoorden op een volledig bericht met correcte CRC.
Of moet ik nu geloven dat de problematische timing er steeds voor zorgt dat de slave wartaal berichten ontvangt met correcte crc?

Inderdaad, ik denk ook eerder aan zoiets.
Het probleem is vooral om dit aan de fabrikant te kunnen aantonen dat zijn module buiten de spec's ligt.

Op aanvraag -> het antwoord als ik de slave poll met functiecode $11
Het slave adres is 3.

Ik denk niet dat de timing van het bericht zélf is dat verkeerd is, zie vorige scoopbeelden, maar het feit dat vooraan en achteraan het bericht de lijn laag staat.

Ik heb reeds de spec's gelezen op de site van modbus.org,
Citaat "State "Idle" = no pending request. This is the initial state after power-up."
Waarom gaat een PLC dan toch wél die datalijnen naar de grond trekken?

Ik zal het probleem niet kunnen oplossen, maar wil wel weten dat mijn testtools al dan niet OK, zodat ik daarop 100% kan vertrouwen.

Ik heb nu mijn cursors op de bittrein gezet.
Zoals je kan zien zijn beide exact hetzelfde 4.12ms, het ligt puur aan de "ilde" state vooraan en achteraan.

PLC request:

PC request:

UPDATE:
Als ik enkel functiecode $11 stuur, zonder het slaveadres, met of zonder CRC antwoord de slave niet.

UPDATE2:

Ik kan alleen maar vaststellen dat de slave niet correct antwoord, misschien is mijn rs485 omvormer niet 100% correct ivm de START en END condities, maar dan zou de slave gewoon niet mogen antwoorden ipv te antwoorden dat er een verkeerd adres opgevraagd wordt.

Alvast bedankt allemaal voor de hulp!
Weer vanalles bijgeleerd!

[Bericht gewijzigd door coldrestart op donderdag 19 maart 2015 19:59:38 (34%)]

Instructie 11H wordt beantwoord met error code 1: instructie not valid. Dat kan betekenen dat deze functie niet geïmplementeerd is in dat device. Dat zou kunnen. Ik meen dat Modbus dat niet verplicht stelt. Schieten we dus weinig mee op.
Kun je nakijken in de protocol implementatie van je apparaat of dat klopt ?

Het is logisch dat alleen een 11H zenden geen antwoord oplevert.

Afgezien van het timing gebeuren is mijns inzien het Modbus protocol niet correct geïmplementeerd.

In de windows API bestaat volgens mij deze functie:
SetCommBreak() en ClearCommBreak()

(https://msdn.microsoft.com/en-us/library/windows/desktop/aa363433%28v=…)
Geen idee of die aanwezig zijn in die vcp driver.

Ik zou dat als eerste proberen en kijken of het zo wel werkt.

-edit- FT_SetBreakOn() en FT_SetBreakOff() zitten in de FTDI library:
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programme…

[Bericht gewijzigd door henri62 op vrijdag 20 maart 2015 00:40:03 (24%)]

@Leo-Bolier: Het toestel ondersteunt niet de functiecode $11, dus vandaar dat die piste eindigt.

@henri62:
Thanks, nu even de test gedaan, op de site van FTDI stonden er ook een paar VB voorbeelden, eventjes een test gedaan met dat commando:

Code:

Wanneer ik enkel de break in de software 1ms actief maak krijg ik

Spijtig genoeg gaat het signaal naar boven ipv naar onder, (ja ik heb wel degelijk er eerst eventjes de normale string doorgejaagd om te zien dat de polariteit correct is van mijn diff lijnen)
wat dus wil zeggen dat ik dit probleem met een break commando niet kan oplossen

Ik blijf erbij dat dat toestel op softwarevlak maar half en half in elkaar hangt.
Alvast bedankt iedereen.

Helemaal mee eens dat de Modbus implementatie van dat toestel niet deugt. Wat is het voor een ding en van welke fabrikant ?
Nu maar hopen dat het een club is die je klachten serieus neemt en gaat onderzoeken in plaats van terugkomt met antwoorden als ...hebt u dit wel geprobeerd of dat ......
Eerlijk gezegd is het behoorlijk amateuristisch dat er zo'n fout in zit....
Succes verder !

Eigenaardig, iets is hier onlogisch!

Het signaal op die scoop plaatjes is dat een differential meting of maar een van de twee lijnen van de RS232 RS485 bus?

Als het 1 lijn is van de RS485 bus, zet de andere lijn er ook eens bij?
Misschien dat een van de lijnen niet correct gestuurd wordt.

@Leo Bolier, ik wil geen merken/fabrikanten in slecht daglicht zetten/ problemen mee krijgen, vandaar dat ik dit niet vermeld heb.
Maar laat ons zeggen dat het toch een vrij grote fabrikant is.
Soms is het sneller om een alternatief van een andere fabrikant te zoeken. (De module is in de prijsklasse van +-200€)

@henri62, Het signaal op de scoop is altijd op A en B lijn van rs485 gemeten, heeft dus niets te maken met rs232.
RS485 is differentiaal, dus je kan niet meten op "de andere lijn".
Ik heb geen biasweerstanden of dergelijke.

Die RS232 was een typefoutje. Daaronder staat het wel goed (zal het effe fixen).

Op 21 maart 2015 19:42:18 schreef coldrestart ...
RS485 is differentiaal, dus je kan niet meten op "de andere lijn".
Ik heb geen biasweerstanden of dergelijke.

Juist wel daarom is het differentiaal!

Maar HOE heb je gemeten, differentieel of niet, dat weet ik nu nog niet.

En welk type RS485 driver gebruik je?

-edit-
Eigenlijk wil je een SPACE op de lijn zetten. Dus alleen de driver enable aansturen TX dus idle, of dat kan in die converter weet ik niet. Ik heb daar nog niet een API call voor gevonden.
Dat is ook eigenlijk een beetje apart want normaal wordt de driver enable (DE) pin door de TX (via een timeout) aangestuurd en kan dat niet via de COM-port api wat die is alleen voor RS232 (is nu geen typefout ).