Modbus RTU

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 (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 (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 (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 ;-)).

Ik heb differentieel gemeten, dus probe op één lijn, de ground van de probe op de andere lijn.

De driver die ik voor de testen gebruikt heb is dezelfde als je link van de pdf documentatie.
Er bestaan inderdaad 2 soorten drivers:
-Een VCP -> enkel virtuele seriële poort
-Een D2XX -> rechtsreeks spreken met de chip.

In die convertor is die FTDI chip het enigste processor, de rest is gewoon logica voor de singaalniveau's.

Op 21 maart 2015 20:39:36 schreef coldrestart:
Ik heb differentieel gemeten, dus probe op één lijn, de ground van de probe op de andere lijn.

Dat is dus niet differentieel maar gewoon een lijn kortsluiten via je scoop!
Een differentiele meting doe je met twee probes en die laat je in de scoop van elkaar aftrekken. OF Je gebruikt er een speciale differential probe voor (maar die zul je waarschijnlijk niet hebben want zijn nogal kostbaar).

In de FTDI adapter moet iets zitten van een speciale RS485 driver. Anders ligt daar dus je probleem!

Toch niet, mijn scope hangt op een scheidingstranformator.
De massa van de probe is zwevend ten opzichte van de massa van de rs485 verbinding.
Ik heb differentiaal probes, HZ100 van hameg, ikzal daar ook eens mee testen, maar aangezien de scoop toch volledig gescheiden is zou dit geen verschil mogen geven.

Ik zal de omvormer nogeens openschroeven.

Anders toch even beide signalen apart meten en kijken wat de DC offset is tov GND en of de signalen symmetrisch zijn.

Ik heb de test gedaan, hierbij de printscreen:

Waarbij:

De oranje en roze lijnen de datalijnen zijn gemeten per kanaal met probes op ground.
De rode lijn het verschil is van beide signalen.
De groene lijn het signaal gemeten met een differentiaalprobe.

Het is niet heel duidelijk te zien, het oranje loopt door de roze lijn heen.
Wat wel gek is dat de lijnen lijken te starten op 0V terwijl ik verwacht dat deze ergens op een 1/2 Vcc zou moeten zitten. Die oranje lijn is vreemd.

Verder is er wel wat asymmetrie maar niet schokkend.

Je zei dat je geen bias-sing had dacht ik ergens. Maak eens een line termination van 120 Ohm en een weerstand naar +5 en een naar GND van 1k2 of zo (A=+ B=- zijde).
Laat die diff signalen dan weg uit je scoop plaatje en zet de A/B signalen onder elkaar.

Nog om even terug te komen op die meting met de probe massa aan het signaal hangen (en je scoop isoleren van het net), dat maakt wel uit. De GND pin van je scoop heeft een vele malen grotere capaciteit naar aarde waardoor je signaal verziekt wordt.

Ik heb altijd mijn line termination zitten van 2x 120ohm.
De biasweerstanden van 1K2 maken op elke manier geen verschil.

Ik vindt dat dat verzieken nog goed meevalt, de aarding van mijn scoop is afgekoppeld (IT) dus het zou dan enkel de "massa" metaal en koper van mijn scoop tov de lucht het verschil moeten maken.
Maar toch terechte opmerking, we leren bij :-)

Een goeie diagnose begint inderdaad bij een correcte meting, en da's al een eerste stap.

Hierbij de printscreen van de differentiaalmeting, gewoon per kanaal met standaard probes.