TIA S7-1200, Druckdatei (*.prn) in DB übertragen

Andreas1961

Level-2
Beiträge
23
Reaktionspunkte
4
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum,
ich hänge gerade an einem kleinen Problem fest, wo ich einfach keine Idee habe, wie es am einfachsten umzusetzen wäre.
Die Aufgabenstellung ist folgende:
Es gibt 25 Stationen mit je einer Waage, einem Drucker und einer CPU1211, welche allesamt über Ethernet miteinander verbunden sind.
Von der Waage lese ich alle paar Sekunden den Wägewert in die SPS ein.
Wenn der Bediener eine Taste drückt, soll am Drucker ein Etikett gedruckt werden, welches diverse variable Daten enthält.
So werden auf dem Etikett das "Datum", die "Uhrzeit", das "Gewicht" und eine "Chargennummer" ausgegeben.
Wie das Etikett aussehen soll, ist in der folgenden Abbildung zu sehen.

Test-Etikett.jpg

Da es nicht möglich ist, das "Grund-Layout" des Etiketts in dem Drucker zu hinterlegen und nur die variablen Daten an den Drucker zu übertragen, muss das komplette Etikett von der CPU an den Drucker übertragen werden.
Hierfür habe ich das Etikett nicht an den Drucker, sondern in eine Druck-Datei ausgegeben (*.prn), die in einem Text-Editor wie folgt aussieht:

Druckerdatei Test-Etikett.jpg
Die gelb markierten Bereiche sind die Variablen Werte.

Mit dem HEX-Editor sieht das (auszugsweise) so aus:

Druckerdatei Test-Etikett (HEX).jpg

Nun meine eigentliche Frage:
Ich stelle mir nun vor, dass ich die komplette prn-Datei Zeichen für Zeichen (einschließlich der unsichtbaren CR und LF) in einem Datenbaustein speichere und die gelb markierten Bereiche mit meinen Variablen überschreibe.

Hat irgendjemand eine Idee, wie ich die prn-Datei in einen DB bekomme, ohne dafür die Datei Zeichen für Zeichen abtippen zu müssen.
Und welches Format wäre hierfür das Sinnvollste.

Für jegliche Anregung wäre ich dankbar.

Gruß, Andreas
 
Womit erstellst du die Layout-Vorlage? Kann das Programm irgendwas exportieren oder konvertieren?
Ich würde wohl was mit MS Excel probieren. Ob man darüber den meisten Text schon so nach TIA kopieren kann, und nur wenige Zeichen manuell eingeben/bearbeiten.
Vielleicht brauchst du den Konverter öfters?
Zuerst in TIA anschauen, wie eine DB-Quelldatei (oder SCL?) aussieht, und dann in Excel (oder Word) eine VBA-Funktion programmieren, die die Vorlage-Textdatei öffnet und jedes Zeichen in die Form konvertiert, die TIA braucht. Und falls Bedarf, die variablen Textstellen mit Sonder/Steuerzeichen markieren, dass das S7-1200 SPS-Programm die Stellen dynamisch findet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
zb einen DB mit einem Array of String. Und dann jede Zeile per Copy and Paste in einen Array Index kopieren.

Steuerzeichen müsste man sicher manuell noch einfügen.

Man könnte auch mit DB quellen rumspielen

Aber du musst das ja nur einmal machen.
Oder ?
 
Hallo van,
ein Problem bei den Strings sehe ich darin, dass diese über zwei Header-Bytes verfügen, die mir u. U. das Druckergebnis verfälschen.
Daher wäre vielleicht ein Ansatz mit einem 'Array of Char' sinnvoller, wobei hier die Steuerzeichen problematisch wären.
Daher wäre ein Byte-Array vielleicht der bessere Ansatz, oder - ohne Array - einfach ein DB mit "x" Byte-Variablen.
Aber auch auf diese Weise müsste ich ja wirklich Zeichen für Zeichen in meinen DB kopieren :(
Es geht also darum, wie ich die Daten - so wie mit dem Hex-Editor dargestellt - in den DB hineinbekomme, ohne alles abtippen zu müssen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Volker,
ich habe eine ZIP-Datei angehängt, welche die Druckdatei "Test-Etikett.prn" enthält.
Wenn Du diese Datei mit dem Windows Texteditor öffnest, bekommst Du die Ansicht, wie ich sie in meinem Eröffnungs-Thread oben dargestellt habe (ohne die CR und LF).
Wenn Du diese Datei mit einem Hex-Editor öffnest, bekommst Du die Ansicht, wie ich sie in meinem Eröffnungs-Thread unten dargestellt habe.
Insgesamt handelt es sich um 715 Zeichen.

Gruß, Andreas
 

Anhänge

Hallo PN/DP,
sorry, aber ich hatte Deine Nachricht total übersehen.
Das Programm, mit welchem das Etikett erstellt wurde, heißt Bartender und ist in der Logistik-Branche fast ein Standard.
Exportieren kann das Programm leider nichts. Es besteht definitiv nur die Möglichkeit, das Etikett an einem angeschlossenen Drucker auszugeben - oder eben in eine Datei zu "drucken".
Ich habe zwischenzeitlich auch mal mit EXCEL rumgespielt und mir die Hex-Codes in eine EXCEL-Tabelle kopiert.
Da sie dort erst mal alle - als Elend lange Zeichenfolge - in einer Zelle gelandet sind, habe ich über die Funktion "Text in Spalten" die einzelnen Hex-Werte, die durch Leerzeichen getrennt waren, in einzelne Spalten reingeschafft. Anschließend die Tabelle transponiert und aus der Zeile eine Spalte gemacht.
Schlußendlich habe ich die Werte um die voranstehende Zeichenfolge "16#" ergänzt, die ganze Spalte markiert und direkt im TIA-Portal in einem DB in die Spalte "Startwert" eines "Array[1..715] of Byte" kopiert.
Ich habe damit zwar mein Ziel schon erreicht, aber das erscheint mir doch reichlich kompliziert.
Insbesondere im Hinblick darauf, dass der Kunde, der natürlich "nur das eine Etikett" fahren möchte, wahrscheinlich bald mit einem anderen Etikett (anderes Layout, andere Etikettengröße, etc. pp) auf der Matte steht und ich die ganze Prozedur wiederholen darf.
Ich hatte halt die Hoffnung, dass irgendjemand eine elegantere Idee hat...

Gruß, Andreas
 
hier mal ein vbscript welches eine externe quelle erzeugt.
die new_db_CHR.db erzeugt bei import fehler
z.B. weil dann im Char ''' steht. z.b. daten[22]
die new_db.db lässt sich ohne fehler importieren da die zeichen als byte (HEX) vorliegen
ich hab das jetzt nicht bis zur kleinigkeit getestet. probier einfach mal aus.
evtl musst du anpassen. bzw sag in welcher zeile(zeichen) es hapert. dann kann man das script anpassen

ich bekomme vom script aber nur 673 zeichen. nicht 715

EDIT
ich hab mal den new_db.db übersetzt und in eine cpu geladen und dann eine kopie vom baustein erzeugt der aber anstatt array of byte, array of char ist (mit blockmove). das sieht dann so aus
1730997609007.png

wenn man nun aus dem db_import_chr eine quelle erstellt sieht
daten[22] := '$''; z.b. so aus
 

Anhänge

Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi
Kannst du nicht den Inhalt vom File als String übergeben (inkl. Dateiendung). Müsstest dann WString nehmen, da String auf 254 Zeichen begrenzt ist.
Sprich String zusammenbauen aus Konstanten und Variablen Teile und diese dann an den Drucker senden (wie kannst du es senden?)
Also ich hab das vor langer Zeit mal so gemacht, dass ich die fixen Teile vom Text im Datenbaustein hinterlegt habe und die Variablen dazu gefügt habe. Also der Text von Start File bis vor die erste Variable als Konstante hinterlegt, in der zweiten Konstante kommt dann der fixe Text zwischen Variable 1 und 2, etc.
Dann das ganze mit Concat wenn, es gebraucht wird, zusammenbauen lassen und dann senden (TSEND?)
War damals aber Zebra oder Cab.
Gruss blimaa
 
Hallo van,
ein Problem bei den Strings sehe ich darin, dass diese über zwei Header-Bytes verfügen, die mir u. U. das Druckergebnis verfälschen.
Daher wäre vielleicht ein Ansatz mit einem 'Array of Char' sinnvoller, wobei hier die Steuerzeichen problematisch wären.
Daher wäre ein Byte-Array vielleicht der bessere Ansatz, oder - ohne Array - einfach ein DB mit "x" Byte-Variablen.
Aber auch auf diese Weise müsste ich ja wirklich Zeichen für Zeichen in meinen DB kopieren :(
Es geht also darum, wie ich die Daten - so wie mit dem Hex-Editor dargestellt - in den DB hineinbekomme, ohne alles abtippen zu müssen.

Header Bytes im String sind kein Problem.

Vor dem senden musst du den string mit Strg_TO_Chars in ein großes Char Array kopieren. Und dann das char array senden.



Ein Byte array ist nicht nötig. Und du willst auch keinen großen Hex dump in der sps haben. Arbeite mit String, oder Wstring.

Steuerzeichen kannst du folgendermaßen eingeben

TRF_CR := '$R'; // Carriage Return
TRF_LF := '$L'; // Line Feed


Man könnte das auch mit concat in scl zusammensetzen. Den variablen Inhalt musst du ja eh noch einfügen.
 
Es gibt 25 Stationen mit je einer Waage, einem Drucker und einer CPU1211,
Welcher Drucker wird verwendet? (Ich gehe mal nicht davon aus das beim Einkauf darauf geachtet wurde das es Drucker gibt bei dem das Layout im Drucker gespeichert wird und dann nur noch Begleitwerte und Druckbefehl angegeben werden müssen, Bsp: Zebra Drucker).
Vielleicht können die vorhandenen das ja dennoch?!
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen Forum,

also das ist der Wahnsinn, wie viele und schnelle Reaktionen hier im Forum auf eine Fragestellung erfolgen!

@volker
Vielen Dank für die Mühe, die Du Dir gemacht hast, um extra ein VB-Skript zu erstellen und das ganze dann auch noch zu testen.
Da ich von VB keine Ahnung habe, kommt diese Variante für mich aber nur in Betracht, wenn es keine andere, elegante Möglichkeit gibt.
Trotzdem vielen Dank für Deine Mühe.
Warum Du nur auf 673 Zeichen kommst, erschließt sich mir nicht. Wenn ich die Datei im Text-Editor öffne und alles markiere, wird in der Statuszeile "694 von 694 Zeichen" angezeigt - aber da fehlen ja auch die Steuerzeichen.
Markiere ich alles im Hex-Editor, wird mir die Blockgröße 2CBhex = 715 angezeigt.

@blimaa
Bei der Verwendung von WSTring scheitere ich bereits daran, den Inhalt der Druck-Datei (was meinst Du mit "inkl. Dateiendung") irgendwie in die WString-Variable einzufügen.
Markiere ich den Inhalt im Text-Editor und füge ihn im TIA-Portal als Startwert der WString-Variable ein, wird lediglich die erste Zeile aus dem Text-Editor eingefügt (wegen CR + LF). Dem könnte ich zwar begegnen, indem ich jede Zeile einzeln in den Startwert der WString-Variable kopiere und nach jeder Zeile ein $N (für 0A+0D/CR+LF) einfüge.
Aber in der Druck-Datei (das ist eine ASCII-Datei) sind auch Hochkommas (') enthalten, die von WString als Anfangs-/Endekennung interpretiert werden und zu einem Syntaxfehler führen.
Also komme ich an dieser Stelle mit WString nicht weiter.
Bei dem Drucker handelt es sich um das Modell TC200 von TSC.
Ich kommuniziere mit dem Drucker (und auch mit der Waage) über TSEND und TRCV.

@van
Strg_TO_Chars wandelt aber nur Strings mit einer Länge von max. 254 Zeichen.

@Escride-1
Ich habe mit dem Hersteller-Support des Druckerherstellers telefoniert und dort wurde mir geraten, das komplette Etikett (via Druck-Datei) in der SPS abzulegen und dort die Variablen Stellen anzupassen.


Bislang hat sich für mich herauskristallisiert, dass das Handling mit Strings zwar schön aussieht, aber auch mit Nachteilen behaftet ist.
Das Etikett in Form eines Hex-Dumps im DB zu hinterlegen finde ich nicht weiter tragisch. Das ist zwar optisch nicht so schön, aber ich sehe auf einen Blick wirklich ALLES, einschließlich aller Steuerzeichen.
Und mit ein paar Kommentaren im SPS-Programm kann das alles auch transparent und nachvollziehbar gestaltet werden.

Meine Grundfrage lautete ja, ob irgendjemand eine Idee hat, wie ich die prn-Datei in einen DB bekomme, ohne dafür die Datei Zeichen für Zeichen abtippen zu müssen.
In meiner Antwort an PN/DP (#7) habe ich ja schonmal eine mögliche Vorgehensweise umrissen, bei der ich als Ergebnis ein Byte-Array mit dem Hex-Dump des Etiketts erhalte.
Vor dem Ausdrucken des Etiketts (indem das komplette Byte-Array per TSEND an den Drucker geschickt wird) muss ich also nur die (fixen) Stellen des Byte-Arrays überschreiben, an denen die variablen Werte stehen.

Ich werde die Aufgabe nun so wie in #7 beschrieben umsetzen, auch wenn's erst Mal ein wenig umständlich ist - aber ich muss das ja nur ein Mal machen.

Ich danke allen beteiligten Forums-Mitgliedern für ihre Beiträge zu meiner Fragestellung und werde versuchen, mich durch eigene Beiträge in diesem Forum zu revanchieren.

Liebe Grüße, Andreas
 
so kompliziert ist das script ja auch wieder nicht.
ich hab mit die prn nochmal angeschaut. mein script hat am zeileende kein CR LF erzeugt.
Hab das angepasst das am zeileende CR LF auch in der datei steht.
sind jetzt 717 zeichen. 2 zuviele ganz am ende da in der prn in der letzen zeile kein cr lf ist.
die .db kannst du ganz einfach als externe quelle tia einbinden und übersetzen.
 

Anhänge

so kompliziert ist das script ja auch wieder nicht.
Ja, kompliziert ist der Code für so einen Konverter nicht, und schnell gemacht. Allerdings braucht der Anwender des VBS-Skriptes als Laufzeitumgebung das TIA-Portal (bzw. eine WinCC Advanced Runtime) und ein Test-HMI-Runtimeprojekt - was ein TIA-Programmierer aber immer hat. Oder wie/wo lässt du das Skript laufen? Irgendwie nativ unter Windows?

Wenn ich solche Konverter brauche, dann will das normalerweise jemand haben, der dann damit selbständig Dateien konvertieren will. Deshalb nehme ich da meistens Excel und ein VBA-Skript.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
das script startet man ganz normal aus der windowsumgebung. das einzige was man im script evtl anpassen muss ist der pfad zur quelldatei und die größe des arrays.
 
@van
Strg_TO_Chars wandelt aber nur Strings mit einer Länge von max. 254 Zeichen.

man braucht einen zwischenschritt

Code:
// wString to wChar Array
Strg_TO_Chars(Strg:=#IN_wstring,
              pChars:=0,
              Cnt=>#Cnt,
              Chars:=#tmpWchar);


// wCharArray in CharArray kopieren
FOR #i := 0 TO "DRUCKER_SEND_LEN" DO
    
    #OUT_char[#i] := WCHAR_TO_CHAR(#tmpWchar[#i]);

END_FOR;
 
so kompliziert ist das script ja auch wieder nicht.
ich hab mit die prn nochmal angeschaut. mein script hat am zeileende kein CR LF erzeugt.
Hab das angepasst das am zeileende CR LF auch in der datei steht.
sind jetzt 717 zeichen. 2 zuviele ganz am ende da in der prn in der letzen zeile kein cr lf ist.
Das hat mich jetzt interessiert, warum nach deiner Angabe da 2 Zeichen zu viel herauskommen.
Ich habe festgestellt, dass dein Konvertier-Skript von #13 nicht nur 2 Zeichen dazu erfindet, sondern generell die Zeilenschaltungs-Zeichen erfindet :rolleyes:
z.B.
Code:
daten[71] := 16#0A;
daten[72] := 16#0D;
Korrekt müsste aber herauskommen:
Code:
daten[71] := 16#0D;
daten[72] := 16#0A;

Für einen Datei-Konverter, der exakt Byte für Byte konvertieren soll, darf nicht die VBS-ReadLine-Methode verwendet werden, sondern es muss die Read-Methode verwendet werden, um wirklich jedes Zeichen der Datei einzulesen. (Notfalls geht auch ReadAll.)

So, jetzt kannst du mich wieder als Besserwisser beschimpfen ;)
 
Das tut der SPS nicht weh, wenn sie jede Sekunde ...zigmal Daten hin und her kopiert, nur weil der Programmierer keine Lust oder "keine Zeit" hatte, der SPS einmalig vor dem Compilieren die Daten "mundgerecht" zu servieren ;)
Hallo PN/DP,
ich hab' jetzt nicht so recht verstanden, was Du damit sagen willst.
Ich finde es toll, welche Mühe sich Volker gibt, mir zu helfen - aber von VB-Skript habe ich eben keine Ahnung und sehe auch nicht die Notwendigkeit, mich für eine einmalige Sache in dieses Thema reinzufuchsen.
Volkers Ergebnis sieht unter'm Strich doch genauso aus, wie das, was ich mit EXCEL und ein wenig hin und herkopieren - ganz ohne Skript - hinbekommen habe.

Als erstes habe ich die prn-Datei mit einem Hex-Editor geöffnet und alle Daten in die Zwischenablage kopiert.

01.jpg

Im zweiten Schritt habe ich EXCEL geöffnet und die Daten dort in die erste Zelle kopiert.
Anschließend mit "Text in Spalten" für jeden einzelnen Hex-Wert eine eigene Spalte erzeugt.
Schließlich mittels "Transponieren" aus der Zeile mit den 715 Spalten eine Spalte mit 715 erzeugt.
Die Spalte B mit dem Wert "16#" erstellt und in der Spalte C dann die "Summe" aus Spalte B und Spalte A eingetragen.
Das sieht dann so aus.

02.jpg

Im TIA-Portal ein Byte-Array mit 715 Feldern angelegt und die komplette Spalte C dort als Startwert hineinkopiert.

03.jpg


Die variablen Inhalte entsprechend kommentiert.

04.jpg
05.jpg

Fertig!

Damit sind alle Spatzen gefangen und es ist easy, die variablen Werte vor dem Senden mit "Leben" zu füllen.
Besten Dank nochmal an alle, die sich hier beteiligt haben.
Nehmt es mir bitte nicht krumm, dass ich auf den Lösungsvorschlag mit dem VB-Skript nicht so richtig angesprungen bin.
Für einen VB-Crack ist das sicher nur eine Fingerübung, aber für mich ist es Neuland. Und ich glaube, soooo viel langsamer bin ich mit meiner EXCEL-hin-und-herschieberei auch nicht...

Liebe Grüße an alle, Andreas
 
Zurück
Oben