TIA Barcodescanner Daten empfangen TIA Portal

[ibo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich habe folgendes Problem und ich hoffe das ihr mir helfen könnt.
Ich will einfach ein 1D Barcode scannen (0123456789) und diese dann in der SPS in einen Array speichern.
Folgende Komponenten habe ich.
Scanner -> Sick IDM140-300S
Phoenix -> GW PN/ASCII 1E/1DB9
Siemens -> CPU 1214C DC/DC/DC
Es gibt eine PDF von Phoenix welche genau auf meinen Fall zutrifft, nur funktioniert das bei mir nicht.
Ich kriege einfach keine Daten in meinen Input Array
Könnt ihr mir bitte helfen?

 

[MFreiberger]

Moin ibo,

also zur Beschaltung des DPRD_DAT:
An LADDR steht im Dokument (Seite 18) 279, bei Dir steht 278.

Natürlich ist der Screenshot auf Seite 17 etwas doof abgeschnitten...

VG

MFreiberger

 

[ibo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin MFreiberger,

bei mir ist die HW-Kennung vom Input die 278, wie in dem Bild "Unbenannt"

 

[MFreiberger]

Was ich so noch nicht gesehen habe, ist das Bild der nicht gesteckten Baugruppe in "Unbenannt"

Gibts bei dem GW PN/ASCII irgendwelche Diagnosemöglichkeiten (WebServer o.ä.)?
Ist die Hardware "grün"?
Funktioniert die Kommunikation zwischen dem Handscanner und dem GW PN/ASCII?

VG

 

[ibo]

Danke für den Tipp. Ich sehe gerade auf dem WebServer das der gescannte Barcode fallengelassen wird.
Jetzt ist die Frage warum?
Die Hardware ist grün.

 

[ibo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier noch die Einstellungen vom Port

 

[Per]

Hallo ibo,

empfängt der Phönix Gateway den Daten vom Handscanner ?

Selbst beim Einsatz der Sick Sanner, mit dem Gateway von Sick CDF600-2, muss man den Handscanner auf das passende Datenformat einstellen.

Dieses ist entweder mit dem IDM Set UP Tool oder durch einscannen von Barcodes möglich.



Gruß Guido

 

[ibo]

Hallo Guido,
vielen Dank für deine Nachricht.
Habe das Problem jetzt gefunden.
Ich musste bei den Einstellungen die End Transmission ausschalten

 

[Hexmex]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Guido,
vielen Dank für deine Nachricht.
Habe das Problem jetzt gefunden.
Ich musste bei den Einstellungen die End Transmission ausschalten

Hallo ibo,
welche "End Transmission" war das genau? Fürchte, ich habe ein ähnliches Problem mit dem GW PN/ASCII und nem seriellen Partner....
Vielen Dank!

 

[R4m80]

Um welchen Scanner handelt es sich denn?
Der vom TE genannte Sick Scanner hat ab Werk kein Prefix und als Sufix ein CarriageReturn.
Der Gateway kommt aber mit der Einstellung CarriageReturn + LineFeed.

Du könntest am Gateway hier das Sufix (oder Endübertragung) auf 1 Byte Stellen und nur 0D (CR) übertragen. (Kann aber bei anderen Scanner ein anderes Symbol sein.)


Oder du parametrierst den Scanner darauf, dass er CRLF überträgt. (Barcodes sind von Hersteller zu Hersteller unterschiedliche.)


Nachtrag:
Falls der Barcode ein CR (oder auch ein CRLF) enthält und dieser nicht die Übertragung beenden soll, könntest du auch das "STX/ETX Control" aktivieren und den Record Suffix ausschalten.
Auf der Gateway-Seite brauchst du dann als "Übertragung starten (STX)" 1 Byte mit 02 und "Endübertragung (ETX)" 1 Byte mit 03.

 

[Hexmex]

Hallo R4m80,

danke für die schnelle Antwort!

Ich habe keinen Scanner, sondern müsste eine PC-Software ansprechen, welchen über den COM1 Port über den PHOENIX Schnittstellenwandler (GW PN/ASCII) mit einer SPS kommuniziert. Leider habe ich (noch) keine detaillierten Infos über die Abschlüsse des PC-Telegramms (also ob mit CRLF oder CR beendet wird)....

Wenn ich aber mal versuchsweise ein Telegramm an den Wandler sende (mache ich aktuell gemäß PHOENX Anleitung per DPWR_DAT) und dann in dessen Web-Interface das Telegramm kontrollieren möchte, ist mir aufgefallen, dass da schon mal gar nichts ankommt. Daher vermute ich noch einen Parametrierfehler von der SPS.

Hätte vielleicht jemand ein SPS Programmbeispiel (Screenshots) von der Hardwarekonfiguration des Wandlers bzw. auch ein Beispiel, wie der Wandler programmseitig angesprochen wird?

 

[R4m80]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine Anleitung würdest du im ersten Post finden.

Versuchst du jetzt vom PC zur SPS zu senden, oder von der SPS zum PC?
Bei zweiterem sollte dir zwischen SPS und Gateway das Pre- und Sufix egal sein.

Hast du in dem Fall auch die Sequenznummer erhöht und die Datenlänge angegeben?

 

[Hexmex]

Hallo,
@R4m80 du hattest recht mit deiner Annahme, ich hatte die Sequenznummer nicht (ordentlich) erhöht - Danke für den Tipp!

Zudem war allerdings auch noch das Kabel defekt, das dauerte dann leider etwas, bis die Kommunikation stand.
Prinzipiell bin ich nun soweit, mit dem Partnergerät Daten auszutauschen, allerdings beschäftigt mich die ganze Zeit noch eine prinzipielle Frage zum Protocoll.
Die Sequenzen zum Senden/Empfangen müssen ja wie auf dem angefügten Screenshot ablaufen.
Ich habe für die Abfolge eine Schrittkette geschrieben, in der das Protokoll sequenziell abgearbeitet wird - das funktioniert soweit auch.

Meine Frage ist nun, muss man das immer so "zu Fuss" programmieren, oder gäbe es dafür auch eine fertige SIEMENS Funktion?
Also vielleicht einen SFB, den ich mit Puffer-DBs fürs Senden und Empfangen füttere und der dann den Datenaustausch (inkl. Fehlerhandling) ordentlich erledigt?


Danke nochmals

 

[Hexmex]

Also vielleicht einen SFB, den ich mit Puffer-DBs fürs Senden und Empfangen füttere und der dann den Datenaustausch (inkl. Fehlerhandling) ordentlich erledigt?

Ich denke da z.B. an einen FB ähnlich den Receive_P2P/Send_P2P Bausteinen, mit welchen man die serielle Kommunikation via SIEMENS CM PtP Modulen umsetzt....

 

[R4m80]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Kommunikation von SPS zu Gateway ist doch über Profinet aufgebaut, oder nicht?
Hier wird kein serielles Protokoll benötigt.

Zum Lesen mit DPRD_DAT die Schnittstelle des Gateways auslesen.
Falls sich die Sequenznummer geändert hat, sind neue Daten in der angegebenen Länge im Array Data verfügbar.

Zum Schreiben das Array Data befüllen, die Länge angeben, die Sequenznummer erhöhen und mit DPWR_DAT and die Schnittstelle schicken.

Zum Lesen und Schreiben dürfen aber nicht die selben Datenbereiche verwendet werden, sonst überschreibt dir das DPRD_DAT immer die letzte gültige Sequenznummer, und was der Gateway mit diesem Sachverhalt anfängt, kann ich nicht sagen.