Telnet mit CoDeSys V3.5 unter Windows XP.

[Ruess.Rainer]

Hallo zusammen,
CoDeSys V3.5 leider noch kein eigenes Forum.


Ich möchte die NETLIB121 benutzen um als Telnet-Client von einem Mess-Sensor (Telnet-Server) Daten abzufragen.


Derzeit wird der Sensor manuell über "Windows Telnet" des Steuerungsrechners bereits abgefragt. Abfrage muss leider wiederholt manuell erfolgen.

*DAT ?                                               Abfagen
*TIM ?
*C1C ?
*C2C ?
*VEL ?
*PRR ?
*ERR ?

*DAT ? :DAT 2014-07-12                               Antworten
*TIM ? :TIM 21:05:53
*C1C ? :C1C 133.05
*C2C ? :C2C 18.26
*VEL ? :VEL 1846.05
*PRR ? :PRR 0x00000000
*ERR ? :ERR 0x00000000


Jetzt möchte ich das ganze natürlich automatisch und direkt aus CoDeSys haraus durchführen. Ich nutze den IP_Control2. Ist laut Beschreibung auch für Telnet-Protokoll geeignet.

Der Verbindungsaufbau wird in der Variablen C_STATE mit 245-255 der Abbau mit 1-0 angezeigt.
Diese Auf und Abbau funktioniert in den C_MODE 1;3;5 (Typ UDP aktiv/passiv; TCP leider nicht).
Daten sind im Sendepuffer (NETWORK_BUFFER_SHORT) angezeigt und Sendedaten.SIZE geht zyklisch vom eingestellten Wert auf 0. Leider ist derzeit im Empfangsteil nichts zu sehen. Also auch keine Fehlermeldung als Antwort (wohl typisch für UDP).

Welcher Modus ist für TELNET-Client geeignet?
Habe bisher die Daten (inclusive CR) als Byte ASCII in den Sendepuffer geschrieben (ohne LOG_MSG).
Wie kann ich prüfen, ob die Daten richtig gesendet werden, da ich das selbe Verhalten auch bei einer falsche IP erhalte.

Gibt es die Demo-Programme in Dokumentenform?

Für Hinweise bzw. Lösungsvorschlag wäre ich dankbar.

Rainer

PS habe auch 23 & 2014 "TCP/IP-Kommunikation zwischen SPS und Server"  Mr. Hapflinger getestet. Gleiches Ergebnis.
Messsensor hat IP ...153 (Port 23 für Telnet). SPS hat IP ...152 kann hier das Problem verborgen sein?
Nochmals die Konstellation:

(Messsensor (IP...152))    - Switch -    (Rechner (Windows XP) - CoDeSys Control RTE V3 (IP...153))

[peewit]

hallo

also wenn du von klassischer Telnet-client verbindung sprichtst dann musst du als client aktiv eine tcp verbindung über port 23 zum Server aufbauen

die c_modes die du angegeben hast sind alls udp modi
die sind normalerweise falsch
da du udp verbindungen verwendest gibt es keine positive oder neagitive reaktion auf dein senden
normalerweise gibt es eine abweisende rückmeldung vom server-stack wenn auf einen gewissen port nichts ist.
ob das bei deinen gerät so ist kann ich nicht prüfen.

normalerweise kann nur c_mode 0 richtig sein.


schau dir das beispiel an, das musst du nur anpassen.....
http://www.oscat.de/community/index.php/topic,2172.msg11403.html#msg11403

[Ruess.Rainer]

Hallo peewit,

danke für deine schnelle Reaktion. Mit was sind diese EXP Dateien komprimiert? Bei unserem Server (mit Kaspersky) erklingen sämtliche Alarme (Viren). Gibt es diese Beispiele auch in Textform oder als PDF?

Habe übrigens an mein Orginal vor deiner Anwort noch was angehängt.

Nachmal:
PS habe auch 23 & 2014 "TCP/IP-Kommunikation zwischen SPS und Server"  Mr. Hapflinger getestet. Gleiches Ergebnis.
Messsensor hat IP ...153 (Port 23 für Telnet). SPS hat IP ...152 kann hier das Problem verborgen sein?
Nochmals die Konstellation:

(Messsensor (IP...152))    - Switch -    (Rechner (Windows XP) - CoDeSys Control RTE V3 (IP...153))

Gruss

Rainer

[peewit]

die beiden dateien mit der endung exp sind pure textdateien die du mit jeden texteditor 1:1 ansehen kannst
du solltest mal kaspersky zeigen wer der herr im haus ist :-)

abschalten und downloaden.....


Siehe Anhang
die texte musst du wieder in eine reine text datei kopieren mit endung exp und in dein projekt importieren


[gelöscht durch Administrator]

[Ruess.Rainer]

Hallo peewit,

vielen Dank für deinen Hinweis und die PDF's.
Da ich nur Remote am Server arbeite, habe ich natürlich keine Eingriffsmöglichkeit und muss mich auf den Admin verlassen.

Hab dein Beispiel übernommen. Durch deine Fehlerbehandlung habe ich jetzt eindeutige Fehleranzeigen.

(Modus 0   Timeout Fehler Verbindungsaufbau bzw. Timeout Fehler Daten senden.) Muss ich nochmals prüfen.

Komme derzeit nicht mehr an den Messsensor heran. Werde mich aber am Donnerstag nochmals damit beschäftigen und mich noch mal melden.

Ein manueller Reset (State := 0) wäre im Beispiel noch gut, da ich immer wieder den Zustand erreiche, dass "State" in 30
bleibt, keine Fehlermeldung und nie ein Empfang stattfindet. (Mach ich dann.)


Gruß

Rainer

[peewit]

hallo

nachdem im beispiel
IP_C.R_OBSERVE:= TRUE; (* Datenempfang überwachen *)

drinnen steht muss es normalerweise auch eine timeout fehlermeldung geben
ich fürchte da ist etwas groeberes nicht in ordnung

da nicht ich die portierung auf codesys 3.x gemacht habe kann ich dir hier wahrscheinlich nicht weiterhelfen

[Ruess.Rainer]

Hallo zusammen,

also so eine "Schnittstelle" ist eine tolle Sache, wenn sie funktioniert. Und sie funktioniert auch bei mir.
Meine Testphase hat etwas länger gedauert.

Zu dem "IP_C.R_OBSERVE:= TRUE; (* Datenempfang überwachen *)" kann ich noch nichts sagen, ich kam ja auch nur während der
Testphase in diesen Zustand.

Meine Probleme waren:

Zum einen kann mein Telnet Server nur zwei mal gleichzeitig angesprochen werden (zwei Kanäle). Also wenn ich durch meine
Versuche zwei mal Mißt gebaut habe war dieser nicht mehr anzusprechen bis dieser durch Neustart wieder zurückgesetzt wurde.
Es wird dann aber der Zustand mit den beiden belegten Partnern angezeigt (also bei Windows Telnet oder Fernsteuerprogramm
vom Hersteller).

In einem zweiten Zustand kann der Geber nicht mehr angesprochen werden. Dies wird nur im Programm vom Hersteller
(Fernsteuerung) mit einer sauberen Fehlermeldung angezeigt. Ist ebenfalls nach einem Reset wieder ok.

Da dieser Messgeber im Ausland eingesetzt ist kann dieser "reset" teilweise etwas länger dauern. (Im nächsten Projekt
kommt nach dem MSS ein eigenes Relais davor.)   

Mit der Eingabe und Ausgabe über STRING ist das "handling" toll, wenn man die Steuerzeichen für CR ($0D) und
LF ($0A) richtig eingibt. Der Eigabestring lautet  '*DAT ?$0D$0A*TIM ?$0D$0A*C1C ?$0D$0A ....'.


Nur noch Kleinigkeiten sind zu bewältigen:

Ich muss einen Kanal für die SPS Steuerung "reservieren" um die Werte für eine Regelung verwenden zu können. Aber wie?

Mein erster Gedanke war ich nehm das C_ENABLE Signal nur für sehr kurze Zeit weg. War ein Versuch Wert aber kann zu eben oben
beschriebenen Fehler führen, dass der Geber überhaupt nicht mehr ansprechbar ist, wenn ich nachträglich zweimalig
die Fernsteuerung starte.

Wie kann ich eine neue Übertragung anstoßen, wenn ich C_ENABLE nicht mehr (Ausnahme Fehlerfall) weg nehme,
also die Verbindung C_STATE := 255 dauernd aufrecht erhalte? 

Benötige ev. nur Gedankenanstoß.
Ansonsten besten Dank für die bisherige Hilfe!

Gruß Rainer

[peewit]

hi

zu eventuellen problemen bei der codesys 3.x portierung kann ich relativ wenig sagen.
aber ein bekannten problem bei codesys plattformes ist, wenn bei aktiven tcp verbindungen ein sps reset oder onlineändern bzw. downloadchances gemacht werden das die sps von der verbindung nichts mehr weiss und somit auch nicht korrekt beenden kann und aus betriebsystemebene diese eigentlich tote verbindung weiter gepflegt wird.

somit sollte man wenn möglich niemals bei aktiven verbindungen die oben genannten vorgänge durchführen
denn danach hilft meist nur ein sps warmstart.

die eventuellen probleme mit c_enable und c_state haben mit den obigen problem ziemlich sicher zu tun oder die umsetzung auf codesys 3.x ist nicht ganz fehlerfrei.

[Ruess.Rainer]

Hallo zusammen,

hallo peewit,

danke für deine Hinweise. Ich habe nun der Netzwerkverbindung eine eigene Task bzw. eine separate Kind-Applikation spendiert. Somit wird keine Unterbrechung verursacht, wenn die SPS, die HMI oder die Berechnungsprogramme geändert werden. In dieser Applikation werde ich einen Schalter einbauen, mit dem ich die Kommunikation deaktiviere und erst dann eine ev. Übertragung durchführen.

Da Kunde z.Z. Betriebsruhe hat, kann ich erst in zwei Wochen wieder fortfahren.

Gruß

Rainer