CNC-Programm über seriellen Port übertragen

[Darie]

Ich hab das gerade nochmal bei mir getestet. Du hattest Recht, das RTS/CTS-Signal wird automatisch gesetzt, wenn man den COM-Port
mit #PB_SerialPort_RtsCtsHandshake öffnet. Wie du bereits gesagt hast, man lernt nie aus

[Falko]

Das ist interessant. Somit braucht man sich nicht darum kümmern und
man prüft eben nur , wenn Daten gesendet werden dürfen. Das erspart uns
einige Programmzeilen.
Danke für das Testen.
Ich habe mir bei Reichelt diverse Adapter und Kabel bestellt.
Dafür lohnt sich das Löten und Aufwand wohl kaum.

Gruß,
Falko

[Falko]

Ich habe nun die Adapter von Reichelt bekommen. Nun werden mir die Signale auch korrekt am Check Tester angezeigt.
Nun sieht das so aus:
TD, RTS und DTR zeigen beim Einstecken des USB2Seriell-Adapter grün an. Der die restlichen LEDS bleiben aus.
Grün bedeutet, das die Signale auf inaktiv gesetzt sind. Sobald ich das nachfolgende Programm laufen lasse, wobei zuerst 10mal
das RTS ein-, (rote LED) und dann wieder ausgeschaltet (grüne LED). Dabei wird das DTR dann auf Rot gesetzt. Nach der ersten Messagebox folgt das 10x Schalten der DTR-Leitung. Diese wird dann abwechselnd von Rot auf Grün geschaltet. Also bei mir lassen sich so
dann beide Signale manuell schalten, ohne Com beenden zu müssen. Also müsste in erster Erkenntnis die Steuerung manuell verlaufen.
da ich mir auch die Adapter für die Gegenseite dazu bestellt hatte, will ich nachher mein Programm auf beide Seiten testen, indem ich eine weiteren USB2Seriel-Adapter verbinde. Dazwischen werde ich dann das Nullmodemkabel was ich bei den letzteren Tests probiert hatte verbinden. Dann bin ich mal gespannt, ob die Steuerung automatisch funktioniert oder nicht.

Hier nochmal die etwas abgeänderte Version aus den vorherigen Einträgen. Dabei habe ich nun Daniel einen schönen Code bekommen, der
das OpenSerialPort() für Stopbit mappt, womit man wie in der Api als auch in anderen Hochsprachen diesen als Integer und nicht wie in PB als Float verwenden kann. Mir ist dieses lieber, da ich diese viel einfacher über Combobox und PreferenceWrite als auch Read nutzen kann, ohne zusätzlich die Floats, 1, 1.5 und 2 speichern zu müssen. Ich habe bei mir die PreferenzesLongs benutzt und kann somit alle Indexierungen der Combobox nutzen. Also keine Umwandlung etc.

Gruß,
Falko

Testprogramm für das Ansteuern von RTS und DTR

Code: Alles auswählen

Enumeration 
  #StopBits_One 
  #StopBits_OneAndHalf 
  #StopBits_Two 
EndEnumeration 
;Procedure von DarkDragon womit das StopBit nun als Integer gemappt wird. Dank an Daniel.
Procedure.i OpenSerialPortEx(SerialPort.i, PortName.s, Bauds.i, Parity.i, DataBits.i, StopBits.i, HandshakeMode.i, InputBufferSize.i, OutputBufferSize.i) 
  Protected FloatStopBits.f = PeekF(?FloatByIntStopBit + StopBits * SizeOf(Float)) 
  ProcedureReturn OpenSerialPort(SerialPort, PortName, Bauds, Parity, DataBits, FloatStopBits, HandshakeMode, InputBufferSize, OutputBufferSize) 
   
  DataSection 
    FloatByIntStopBit: 
      Data.f 1.0 
      Data.f 1.5 
      Data.f 2.0 
  EndDataSection 
EndProcedure 

Macro OpenSerialPort(SerialPort, PortName, Bauds, Parity, DataBits, StopBits, HandshakeMode, InputBufferSize, OutputBufferSize) 
  OpenSerialPortEx(SerialPort, PortName, Bauds, Parity, DataBits, StopBits, HandshakeMode, InputBufferSize, OutputBufferSize) 
EndMacro

Port$="COM4"
#SerialPort=0
;Handshake.l=#PB_SerialPort_NoHandshake
;Handshake.l=#PB_SerialPort_RtsCtsHandshake 
Handshake.l=#PB_SerialPort_RtsHandshake
;Handshake.l=#PB_SerialPort_XonXoffHandshake

Parity.l=#PB_SerialPort_NoParity;   #PB_SerialPort_EvenParity;
If OpenSerialPortEx(#SerialPort, Port$, 9600, Parity , 8, #StopBits_One , Handshake , 1024, 1024)
  
  Schalter = 1
  For i = 1 To 10
    SetSerialPortStatus(#SerialPort, #PB_SerialPort_RTS, Schalter)
    Delay(1000)
    ;Compilereinstellungen den inlineAsembler einschalten nicht vergessen!
  	Schalter=Schalter Not Schalter
  	Debug Schalter
  Next i
  MessageRequester("Error", "serial port is ok: "+Port$)
    For i = 1 To 10
    SetSerialPortStatus(#SerialPort, #PB_SerialPort_DTR, Schalter)
    Delay(1000)
    ;Compilereinstellungen den inlineAsembler einschalten nicht vergessen!
  	Schalter=Schalter Not Schalter
  	Debug Schalter
  Next i
  MessageRequester("Error", "serial port is ok: "+Port$)
  Else
  	MessageRequester("Error", "Can't open the serial port: "+Port$)
  EndIf
  ;CloseSerialPort(#SerialPort); Der Debugger wird hiermit nur gestört, warum auch im PB-Beispiel
  ;dieser Befehl nicht vorhanden ist. Scheint ein Bug des Debuggers zu sein.
   

[Edit]
So wie es aussieht funktioniert die Datenübertragung ohne CTS-Abfrage usw. auch mit RTS/CTS-Handshake
automatisch. Zumindesten schalten die LEDS der jeweiligen Leitung CTS als auch RTS automatisch auf aktiv (rote LED)
Nach Überprüfen mit PSPAD TEXTDiff, musst ich doch feststellen, das zwei Zeilen bei einem 1000-zeiligen Programm einmal Ziffern versechsfach wurden oder der Text um einen Buchstaben mehrfach erweitert wurde.
Also muss ich die Abfrage von CTS usw. wohl besser mit einbinden.

[/Edit]

Gruß,
Falko

[Falko]

Ich habe heute soweit alles über die direkte Hardwareverbindung
von COM4 nach Com5 per Check Tester ausprobiert.

Also bei mir reicht es, wenn ich das mit oder ohne Handshake wähle.
So wie es aussieht, (Testweise ein Delay(50) eingebaut) wird
die RS232 völlig automatisch vom PC gesteuert. Man kann an den LEDs sehr
schön sehen, wie sich die CTS und RTS sich händeln.

Ich hatte gestern noch ein Problem mit dem Puffer.
Bei einer hohen Baudrate wie 128000 wurden in ca. 4 Programmzeilen
entweder eine Ziffer oder ein Buchstabe mehrfach dazu geschrieben.
Nun lösche ich diesen Puffer nach einem jedem Senden und Schreiben in die
Datei. Der Fehler ist nun weg.

Ich habe nun keine Abfrage mit
Ergebnis=GetSerialPortStatus(#SerialPort, Attribut)
eingebaut.
Und 1000 Programmzeilen werden bei max. 128000Baud ohne Fehler
gesendet bzw. empfangen.

Ok, XON und XOFF habe ich bei mir offen gelassen. Diese müsste man
wohl vermutlich selbst händeln, wie ich gelesen habe.

Gruß,
Falko

[Darie]

Schön, dass alles klappt, wie es sein soll. Was hast du denn mit der seriellen Schnittstelle vor ? Nur zum Testen oder hast du irgendwas
zusammengelötet ?

[Falko]

Also gelötet habe ich jetzt nichts, da es sich für den Preis, wofür man
bei www.Reichelt.de diese Adapter von 9 auf 25 Pin und Verbindungskabel als 1:1-Leitung
sowie Nullmodemkabel bekommen kann, nicht lohnt.

In erster Linie mache ich das dafür, um mit meinem Programm dann Datensicherung als auch
Daten zurückschreiben auf einer Heidenhain TNC131 Bahnsteuerung mit einem Laptop
nutzen zu können.

Diese Maschine soll man auch mit einem Nullmodemkabel benutzen können, sodass man statt der
einfachen RS232-Anbindung auch vermutlich mit Handshake die max. 1000 Zeilen aus der Box
laden kann.

Natürlich ist das nicht das ein zigste, was man damit in unserer Firma verwenden kann.

Privat mache ich auch hier und da einiges ums per seriellen IC was ein und auszuschalten. Nur braucht man dafür kein Handshake. Deswegen habe ich die Versuche usw. gemacht, um zu sehen, wie das ganze funktioniert, ob automatisch, oder manuell gesteuert. Bei einfachen IC-Schaltungen werden die Leitungen einfach für manuelles Steuern zweckentfremdet. Aber bei
einer Nullmodemverbindung usw., damit habe ich mich erst seit einigen Wochen näher mit beschäftigt .

Gruß,
Falko

[Falko]

Hier habe ich noch ein interessantes Terminalprogramm gefunden, mit dem man
quasi das eigene Programm überprüfen kann.
http://www.elektronik-labor.de/RS232/2010Terminal.html
Auch diese Homepage bietet eine interessante Beschreibung über die RS232 etc.

Einfach in com0com die beiden Ports umschreiben uns Apply ausführen. Bei mir
fängt die erste freie COM mit 7 und 8 an, die ich somit gepaart habe.

Dann im TerminalProgramm eine Adresse davon auf 7 oder 8 händisch ändern und damit Daten
angenommen werden können das Häkchen unten links bei RTS setzen. So kann man schön sehen
wie die Daten dort ankommen. Natürlich müssen die Parameter auch stimmen.

Das funktioniert schon recht gut. Nun hatte ich bei mir noch die Errorabfrage eingebaut, die ich im
dem englischen Forum gefunden habe. Wobei ich die Procedure mit einem Rückgabestring umgeschrieben habe
als auch die Messagebox kommentiert habe.

Code: Alles auswählen

Procedure.s DisplayComError()
  ComErrorText.s = ""
  If IsSerialPort(comID)
     ComError.l = SerialPortError(comID)
     If ComError & #PB_SerialPort_RxOver : ComErrorText + "An input buffer overflow has occurred"+#CR$ : EndIf
     If ComError & #PB_SerialPort_OverRun : ComErrorText + "A character-buffer overrun has occurred"+#CR$ : EndIf
     If ComError & #PB_SerialPort_RxParity : ComErrorText + "The hardware detected a parity error"+#CR$ : EndIf
     If ComError & #PB_SerialPort_Frame : ComErrorText + "The hardware detected a framing error"+#CR$ : EndIf
     If ComError & #PB_SerialPort_Break : ComErrorText + "The hardware detected a break condition"+#CR$ : EndIf
     If ComError & #PB_SerialPort_TxFull : ComErrorText + "The output buffer was full"+#CR$ : EndIf
     If ComError & #PB_SerialPort_IOE : ComErrorText + "An I/O error occurred during communications with the device"+#CR$ : EndIf
     If ComError & #PB_SerialPort_WaitingCTS : ComErrorText + "Waiting  CTS"+#CR$ : EndIf
     If ComError & #PB_SerialPort_WaitingDSR : ComErrorText + "Waiting  DSR"+#CR$ : EndIf
     If ComError & #PB_SerialPort_WaitingRLSD : ComErrorText + "Waiting  RLSD"+#CR$ : EndIf
     If ComError & #PB_SerialPort_XoffReceived : ComErrorText + "Waiting  because the XOFF character was received"+#CR$ : EndIf
     If ComError & #PB_SerialPort_XoffSent : ComErrorText + "Waiting  because the XOFF character was transmitted"+#CR$ : EndIf
     If ComError & #PB_SerialPort_EOFSent : ComErrorText + "EOF character has been received"+#CR$ : EndIf
     If Right(ComErrorText,1)=#CR$:ComErrorText=Left(ComErrorText,Len(ComErrorText)-1):EndIf
      ; MessageRequester("PBX Interface","Communication error occured :"+#CR$+ComErrorText)
   EndIf
   ProcedureReturn ComErrorText 
EndProcedure

Obwohl bei mir die Daten korrekt übertragen werden werden mir Parity-Fehler angezeigt. Vielleicht liegt das
daran, das ich bei mir das Xon/Xoff nicht berücksichtigt habe. Bin mir jetzt aber nicht sicher, da soweit alles
funktioniert.

[Edit]
sry, das sind sogar drei Hardwarefehler, die angezeigt werden.

---------------------------
PBX Interface
---------------------------
Communication error occured :

The hardware detected a parity error

The hardware detected a framing error

The hardware detected a break condition
---------------------------
OK
---------------------------

[/Edit]

Gruß,
Falko

[Darie]

Das hört sich eher nach TimeOut-Problemen an, wahrscheinlich musst du die TimeOutwerte für die Verbindung etwas lockern....

[Falko]

Zu hohe Baudrate kann ich jetzt ausschließen. Die habe ich mal testweise
ganz nach unten gesetzt. Erst nur die Sendeseite und dann auch beide.

Ich muss wohl oder übel, wohl doch die Signalleitungen RTS/CTS DCD und DSR
bei den Übertragungen noch einfügen. Zwar werden die Daten übertragen und
ich habe keine Fehler bei den 1000 Zeilen mit PSPAD-Text-Vergleich finden können.
Aber die Fehlermeldungen zeigen, das die Hardware damit nicht einverstanden ist.
Zwar sieht das mit dem Adapter aus, als ob die Freigaben der Leitungen aktiv sind,
muss aber wohl doch vom Programm zusätzlich gesteuert werden.

Gruß,
Falko

[Darie]

Das Problem hatte ich auch, es liegt an den Einstellungen für die TimeOuts. Wenn du die anpasst, dann gibts nachher auch keine Fehlermeldungen mehr.

Gruss
Alexander