Inoffizielles deutsches Xbase-Forum

Hallo

ich hätte ein Project in dessen Mittelpunkt die Abfrage von einigen 100 Word Registern und mehrern 100 Coils aus mehreren Slaves über mehrere Ports RS232 und TCP/IP mit dem Modbus-Protokoll steht.

Hat sich schon jemand mit Modbus befasst bezw. kennt API-Funktionen oder Class Bibliotheken die sich direkt in xbase verwenden lassen.

Benötigt werden: Coils lesen, HoldingRegisters lesen/schreiben

Gruss Carlo

Hi

Modbus ist ein Weltweit eingesetztes Protokoll für die Datenverbindung zwischen PC's und SPS-Steuermodulen in Schaltschränken und Maschinen. Dies läuft über RS232 oder TCP/UP
zur Datensicherheit wird CRC16 und verschiedeneTimeout's verwendet. übertragen werden nur wenige Bytes, Zustände und Messwerte, dies aber in Sekundenabständen.

Hat sich noch niemand damit rumgeschlagen, bezw. kennt das niemand?

Cu Carlo

Es gibt verschiedene Bibliotheken, die RS232 und TCPIP unterstützen, ich kannte jemand der mit den Clipper Tools und der RS232 Daten über das Telefon ausgetauscht hat.
XbToolsIII (RS232) und ASINET (TCPIP) von Alaska (Prof. Sub) oder Marshallsoft (alles

http://marshallsoft.com/) fallen mir dazu ein.
Gemacht habe ich damit aber noch nichts.

Hallo Hubert

erwähnten Bibliotheken sind leider alle für diesen Zweck unbrauchbar. Im Mittelpunkt steht die kommunikation über RS232. Da es eine Punkt Mehrpunkt verbindung ist(RX=TX), also mehrere Geräte am selben Bus(Drähte) angeschlossen sind gibt es verschiedene Timouts die eingehalten werden müssen: Vor dem Senden muss z.B. 3.5 Byte Zeit Ruhe sein oder ein Abstand zwischen Bytes von mehr als 1.5 Byte Zeit markiert ein Fehler usw. usw. Bei 38400 Baud sind dies werte unter 1/1000 Sek die beachtet werdem müssen was jenseits der Xbase möglichkeiten liegt. Diese Timouts sind die Herausforderung nicht die Datenpakete selbst deren Aufbau ist sehr gut dokumentiert.

CU Carlo

1.5 Byte Zeit ?

was ist das für eine Einheit

Kennst du eine Programmiersprache die das kann ?

Wenn ja, dann nimm diese (oder beauftrage jemand der das kann) und erstelle eine DLL/EXE die das Handling übernimmt.
Von Xbase++ aus kannst du dann entweder diese Steuern oder die Daten austauschen, je nach Anforderung.

oder diese benutzen
ftp://ftp.alaska-software.com/PhilIde/hrtimer.zip

Byte-Zeit = Gemeint ist die Zeit welche das übertragen eines Bytes = 11 Bits mit der eingestellten Baudrate benötigt.

es ist meine Kurze übersetzung von "character times" siehe:

The entire message frame must be transmitted as a continuous stream of characters.
If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and
should be discarded by the receiver

Käuflich zu erwebende DLL's gibt es einige, auch Demos dazu, leider benötigen die meisten das .NET Framework, welches Tabu ist (Verwendung verboten), diejenige die Infrage kommen würde ist leider in einer Funktion fehlerhaft, oder aber Sie (die DLL's) benötigen einen "Erpressungs/Nötigungs Dongle" was nicht, unter keinen Umständen in Frage kommen würde.

Ich habe mir jetzt einige SPS besorgt zusammengeschaltet und bin am testen, ohne Fehlerbehebung (Timeout Erkennung) würde es mit den xBaseTools schon laufen .....

die eigene Anwendung kann keinesfalls so genau sein, dass 1/1000 Sekunden genau zur rechten Zeit rausgehen.
Wenn dann müssen die 1.5 Byte ... 8 * 1.5 Bits, also 12 Bits mit nichts (chr(0)) gefüllt in den Datenstrom eingebaut und alles auf einmal übergeben werden.

Die Pufferung müsste bei RS232 der CHIP und bei TCPIP die Netzwerkkarte übernehmen. Zumindest kann ich mir nichts anderes vorstellen.

Windows ist nunmal KEIN realtime system, bei dem man tatsächlich den Ablauf so fein steuern könnte.
Ich persönlich fand die timing Problme mit meinem alten RS232 Drucker schon nervig genug

Hallo Hubert

nein nein, nicht so, das senden ist nicht das Problem das bringt der 16500 Baustein der Schnittstelle dank FIFO perfekt hin.

wenn beim Empfang zwischen 2 Bytes mehr Zeit vergeht als für das senden von 1.5 Bytes benötigt wird muss alles verworfenen werden bis mindestens für 3.5 Byte Zeit nichts mehr ankommt.

Wenns Interessiert eine gute Dok ist unter: http://modbus.org/docs/Modbus_over_seri ... _V1_02.pdf zu finden. Punkt: 2.5.1.1 MODBUS Message RTU Framing

Cu Carlo

sorry, ich verstehe nicht mal das Problem ...

Das Problem ist: Man muss die PAUSEN zwischen 2 übertragenen Bytes(Character) auswerten. Dies im Bereich von 0.4ms! Das ist genau das was bei einer Punkt-Punkt Verbindung z.B. zu einem Strichcodeleser usw. niemand interessiert. Da bei Modbus viele Geräte am selben Bus sind ist dies eine der wichtigsten Grundlagen.

Aber genau diese 1/1000 Sek. Pausen dürften vom Cache bzw. Chips ausgeglichen werden, da man im normalfall keine haben will.

Hier ist der wichtige Teil

2.5.1.1 MODBUS Message RTU Framing
A MODBUS message is placed by the transmitting device into a frame that has a known beginning and ending point. This allows
devices that receive a new frame to begin at the start of the message, and to know when the message is completed. Partial
messages must be detected and errors must be set as a result.
In RTU mode, message frames are separated by a silent interval of at least 3.5 character times. In the following sections, this time
interval is called t3,5.

RTU Message Frame
The entire message frame must be transmitted as a continuous stream of characters.
If a silent interval of more than 1.5 character times occurs between two characters, the message frame is declared incomplete and
should be discarded by the receiver.

In meinem Testaufbau funktioniert die Kommunikation mit den XBTools jetzt, blos ohne diese Fehlererkennung ist das Risiko einer Fehlfunktion wegen Störung usw. sehr hoch ...

Ich bin mir nicht sicher, ob ich das Problem richtig verstehe:
geht es inzwischen nur noch darum, Zeiten im Millisekundenbereich mit xBase++ messen zu können?

Uli

So wie ich das verstehe muss er "Lücken" zwischen den Bytes im Bereich von 1/1000 Sekunden entdecken,
aber nach meiner Meinung (ich kann mich irren

) gleicht doch der UART CHIP der RS232 gerade diese aus und liefert konstante Datenströme an Windowsprogramme.

https://de.wikipedia.org/wiki/Universal ... ransmitter

Er meint es gäbe DLLs die das handlen können, die müssten dann tiefer ansetzen und direkt mit der Hardware verhandeln, aber in dem Zeitrahmen

Ja, beim Empfang eines Telegramms muss die Zeit zwischen den Bytes ausgewertet werden, ist diese ausserhalb den Bedingungen ist das Telegramm ungültig. Je nach Baudrate ist dies tatsächlich im Bereich von 1/1000 Sekunden.

Für die Messung von Zeiten im Millisekundenbereich (und kleiner) benutze ich die Klasse HRTime, die ursprünglich von Phil Ide stammt:

Code: Alles auswählen

*****************
* CLASS HRTimer: Für Zeiten mit höchstmöglicher Genauigkeit
* 31-Aug-2012    Klasse ursprünglich von Phil Ide, modizifiziert von Uli Tscharntke
*****************
DLLFUNCTION QueryPerformanceCounter(@cBuffer8)   USING STDCALL FROM Kernel32.dll
DLLFUNCTION QueryPerformanceFrequency(@cBuffer8) USING STDCALL FROM Kernel32.dll

CLASS HRTimer              // Für Zeiten mit höchstmöglicher Genauigkeit
  HIDDEN:
    CLASS VAR granule      // Anzahl Zeiteinheiten, die pro Sekunde gemessen werden können
    VAR iStart
    VAR isRunning
    VAR duration
  EXPORTED:
    CLASS METHOD InitClass()
    METHOD Init()
    METHOD Start()         // Zeitmessung starten
    METHOD Stop()          // Zeitmessung stoppen / unterbrechen
    METHOD Continue()      // Zeitmessung fortsetzen
    METHOD Duration()      // Zeitdauer
    METHOD isRunning()
    METHOD Precision()     // Kleinste messbare Einheit in Sekunden
ENDCLASS

CLASS METHOD HRTimer:InitClass()
  QueryPerformanceFrequency64( @::granule )
RETURN( self )

METHOD HRTimer:Init()
  ::isRunning := FALSE
  ::iStart    := 0
  ::duration  := 0
RETURN( self )

METHOD HRTimer:Start()
  ::isRunning := FALSE
  ::duration  := 0
  ::Continue()
RETURN( self )

METHOD HRTimer:Stop()
LOCAL i := 0
  IF ::isRunning
    QueryPerformanceCounter64( @i )
    ::isRunning := FALSE
    ::duration  += (i - ::iStart)/::granule
  ENDIF
RETURN( ::duration )

METHOD HRTimer:Continue()
  IF .NOT. ::isRunning
    QueryPerformanceCounter64( @::iStart )
    ::isRunning := TRUE
  ENDIF
RETURN( self )

METHOD HRTimer:Duration()
LOCAL nResult,i := 0
  nResult := ::duration
  IF ::isRunning
    QueryPerformanceCounter64( @i )
    nResult += (i - ::iStart)/::granule
  ENDIF
RETURN( nResult )

METHOD HRTimer:isRunning()
RETURN( ::isRunning )

METHOD HRTimer:Precision()
RETURN( 1/::granule )

STATIC FUNCTION Bin2U64( cBuffer )
LOCAL nResult,nLow,nHigh
  nHigh := (Bin2U(Right(cBuffer,4)))
  nLow  := Bin2U(cBuffer)
  nResult := (2**32)*nHigh+nLow
RETURN( nResult )
//RETURN( (2**32)*(Bin2U(Right(cBuffer,4)))+Bin2U(cBuffer) )

FUNCTION QueryPerformanceCounter64( n )
LOCAL nResult,cBuffer8 := space(8)
  nResult := QueryPerformanceCounter(@cBuffer8)
  n := Bin2U64(@cBuffer8)
RETURN( nResult )

FUNCTION QueryPerformanceFrequency64( n )
LOCAL nResult,cBuffer8 := space(8)
  nResult := QueryPerformanceFrequency(@cBuffer8)
  n := Bin2U64(@cBuffer8)
RETURN( nResult )

Hilft Dir das weiter?

Uli

Uli,

den Link dazu hatte ich oben schon geposted.

Hi

danke für die Tips betr. HRTimer. Zwischenzeitlich habe ich mich mehrere (lange) Tage mit dem Problem befasst. Dabei sind einige Versuchs-Programme entstanden, die leider, in meiner Testumgebung nicht allzu überzeugend Funktionierten........

Per Zufall bin ich heute im Web auf eine DLL gestossen welche die Aufgabe sowas von perfekt erledigt. Und dies über RS232, TCP/IP und USB->RS232 (FTDI) und auch noch Multi-Threadfähig ist.
Dies mit gutem Handbuch ohne "Erpressungs-Dongle" und zudem Kostenlos ...... Oh Wunder! Mein Komunikationsmodul war damit in 2 Stunden fertig.

Dennoch danke für eure Tips.

Cu Carlo

Könntest Du uns noch sagen wo es die DLL gibt ?
Eine Kennzeichnung des Themas als erledigt wäre auch nicht schlecht

Koverhage hat geschrieben:den Link dazu hatte ich oben schon geposted.

Stimmt. Die ursprüngliche Quelle habe ich übersehen

. Aber ich finde, die abgewandelte Klasse ist intuitiver zu benutzen

.
Uli

Inoffizielles deutsches Xbase-Forum

Modbus

Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus

Re: Modbus