Step 7 DB-Bereich 16Byte auf größer 0 vergleichen

Zuviel Werbung?
-> Hier kostenlos registrieren
Dann ist eigentlich schon Post #2 die Antwort, nur nicht auf >0, sondern auf >32 abfragen (nach Deiner Logik W#16#20). Ich würde aber ja auf
> 47 und < 58 abfragen.
Der Code bricht aber ab, sobald nur ein Zeichen gefunden wurde. Es sollen aber in allen Bytes "Zeichen enthalten" sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn der Prägecode kopiert wurde, ist alles vorbei. Er wird in einer anderen DB eingetragen, wo eine Windowssoftware ihn ausliest und weiter verarbeitet. Deswegen ist es wichtig, dass Werte vorhanden sind.

Grüße Tommylik
sorry ... das verstehe ich nicht ... das mußt du mal erklären ... (also wie kommt hier was zustande ?)
 
Ich meine >0, muss ich bei ASCII-Zeichen das <>0 benutzen?
Hmmm, ein Vergleich mit >, >=, < oder <= sollte bei ASCII-Zeichen (CHAR) zulässig sein, um eine alphabetische Sortierung zu ermöglichen, aber möglicherweise nicht bei BYTE, wenn BYTE nämlich als ein halbes WORD verstanden wird!? Bei Word wird komischerweise unterstellt, dass die genannten VergleichsOperatoren keinen Sinn machen und man deshalb nur auf = oder <> vergleichen kann.
Bei SINT (short INT, WerteBereich: -128..127) und USINT (unsigned short INT: WerteBereich: 0..255) hingegen sind die Vergleiche jedoch allemal sinnvoll.
Diese Einschränkungen sind künstlich aufgepfropft, um den Compiler in die Lage zu versetzen, dem Programmierer auf die Finger zu klopfen.
Aber leider scheint dies nicht immer wirklich konsequent umgesetzt zu sein.
Ja, ich muss sicherstellen, dass alle Zeichen vorhanden sind.
Vorhanden? Ich schätze mal, dass hier eine "PlausibilitätsPrüfung" gemacht wird, ob die Daten irgendwie "beschädigt" sind.
Wenn es tatsächlich um druckbare Zeichen gegangen wäre (außer dem Leerzeichen), hätte man aber auch auf < 16#7F abfragen müssen.
Mit diesem Einwand hat Mario gar nicht so Unrecht. 127 alias 16#7F zählt "ursprünglich" nicht zu den druckbaren Zeichen.
Aber die Zeichen 128..255 gehörten anfangs auch nicht dazu ...
Sorry für meine ungenaue Erklärung. Ich hoffe, es ist jetzt verständlicher.
Sorry, aber Deine Erklärung ist leider unklar geblieben.
Ist denn irgendwo dokumentiert, welche Zeichen zulässig sind?
Ich meine >0, muss ich bei ASCII-Zeichen das <>0 benutzen?
Mittlerweile bin ich mir fast sicher, dass tatsächlich >32 gemeint ist, also >' '.
Vielleicht ist sogar >=32 gemeint, also >=' '.

Darf man denn mal fragen, zu welchen Konsequenzen das PrüfungsErgebnis führen kann/soll, wenn nicht alle Zeichen >32 sind? Vielleicht kann man daraus zurückschliessen, wozu die Prüfung dient.

Ich vermute mal, dass du deinen "Prägecode", wenn welcher dort eingetragen ist, als String weiter verwendest (oder ?).
Falls ja dann könntest du ihn in SCL auch einfach mit einem gleich langen Leerstring vergleichen. Das wäre dann auch deutlich schneller zu durchschauen was das soll ... (und du bauchst keine Schleife etc.)
Edit: Das sollte ohne Weiteres sehr gut funktionieren. Wenn mindestens ein beliebiges der Zeichen <=32 ist, dann ist der komplette String kleiner als ein String aus der entsprechenden Anzahl von LeerZeichen.
So gesehen sollten 2 Vergleiche genügen, um festzustellen, dass jedes Zeichen >='0' UND <='9' ist:
test := String >= "00000000000000" AND String <= "99999999999999" ;
 
Zuletzt bearbeitet:
@Heinileini : ich schließe aus dem DB-Dump des OP und der Bezeichnung des Ganzen, dass hier ein Zeitstempel an eine Prägemaschine (Nadelpräger ?) übertragen wird. Weiter denke ich, dass wenn da andere Zeichen drinstehen dann werden die sicher auch gedruckt - ist aber dann Quatsch auf dem Bauteil ...
 
Dann müsstest du jedes Byte prüfen, ob es ein zulässiges/erwartetes ASCII-Zeichen enthält, z.B. Ziffern '0' .. '9'
Vielen Dank für den Beispielcode.
Auch an DeltaMikeAir

Dann ist eigentlich schon Post #2 die Antwort, nur nicht auf >0, sondern auf >32 abfragen (nach Deiner Logik W#16#20). Ich würde aber ja auf
> 47 und < 58 abfragen.
Du hast recht, >32 wäre sinnvoller und so wie du es machen würdest, wäre es noch besser.
Vielen Dank

Meine Frage nach SCL war völlig blöde, der Baustein ist in KOP und teilweise in AWL geschrieben.
Ein Any der als IN-Parameter übergeben wird, muss erst auf die Lokaldaten übertragen werden, damit man mit den Werten arbeiten kann, oder?

Ich habe den Code im I-Net gefunden und für mich angepasst.

1707129054580.png

Und jetzt kommt das, was ich nicht verstehe.
Der Any ist jetzt in den Lokaldaten, aber wie greife ich darauf zu? Wo sind jetzt diese 16Byte?
Ich kann die Daten ja nicht sehen, (offline) so wie, wenn ich einen DB öffne.
Wer könnte mir das bitte erklären?

Oder sollte ich lieber ein UDT nehmen?


Grüße Tommylik
 

Anhänge

  • 1707126858454.png
    1707126858454.png
    25 KB · Aufrufe: 7
Zuviel Werbung?
-> Hier kostenlos registrieren
Vergiss das mit dem ANY in AWL, wenn du ANY und Pointer nicht genug verstehst. Besonders mit Code aus dem I-Net, der für irgendwas für einen FB geschrieben wurde und du willst ihn in einen FC einbauen.
Dann nimm besser 32 Vergleiche in KOP. Das versteht jeder, auch du selber noch in > halbes Jahr. Oder Prüf-Schleife in SCL (z.B. extra FC), das ist auch verständlich.
 
Meine Frage nach SCL war völlig blöde, der Baustein ist in KOP und teilweise in AWL geschrieben.
Ich sehe keinen Grund, warum die Frage nach SCL blöde gewesen sein soll.
Ich habe den Code im I-Net gefunden und für mich angepasst.
Hast Du den Kommentar in der letzten Zeile "gefunden und kopiert" oder "angepasst"?
Der Kommentar '// Byte 8 bis 10 ...' ist falsch/irreführend:
Byte 8 bis Byte 10 sind 3 Byte, aber LW sind nur 2 Byte.

Wo sind jetzt diese 16Byte?
16 Byte? 4 Byte + 4 Byte +2 Byte = 10 Byte!
 
Vergiss das mit dem ANY in AWL, wenn du ANY und Pointer nicht genug verstehst. Besonders mit Code aus dem I-Net, der für irgendwas für einen FB geschrieben wurde und du willst ihn in einen FC einbauen.
Dann nimm besser 32 Vergleiche in KOP. Das versteht jeder, auch du selber noch in > halbes Jahr. Oder Prüf-Schleife in SCL (z.B. extra FC), das ist auch verständlich.
Ja, das hast du wohl recht.
Aber einen Any der dem FC als In-Parameter übergeben wird und den dann an den nächsten FC weitergeben wird,
der dann in SCL geschrieben ist, macht das ganze auch nicht gerade übersichtlicher.

Ich sehe keinen Grund, warum die Frage nach SCL blöde gewesen sein soll.
Weil die Schleife in SCL ist, ich einen extra FC benötige und der aktuelle FC schon alle Daten mit sich bringt.

Hast Du den Kommentar in der letzten Zeile "gefunden und kopiert" oder "angepasst"?
Ja

16 Byte? 4 Byte + 4 Byte +2 Byte = 10 Byte!

Genau deswegen ist es für mich verwirrend. Und du haust noch einen obendrauf.

Ich habe einen ANY mit einer Zugriffsbreite von 16 Byte aber nur 10 Byte in den Lokaldaten.

1707132479588.png

Irgendetwas fehlt noch, wo die Daten hingeschrieben werden, wenn der Any geladen wird.

Code:
 L     P##i_PrgCode                // Eingang ist IN- Variable vom Typ ANY

Wir haben FC/FB, die haben ANY In-Parameter, die haben eine Zugriffsbreite von 300 Byte.

Vielen Dank für eure Hilfe, ohne die wäre ich aufgeschmissen.

Grüße Tommylik
 
Ich habe einen ANY mit einer Zugriffsbreite von 16 Byte aber nur 10 Byte in den Lokaldaten.
Der Datentyp ANY belegt 10 Byte. Wenn du in TEMP eine Variable vom TYP ANY anlegst, dann kannst du den ANY von IN nach TEMP kopieren. Das sind aber nicht die Daten auf die der ANY zeigt, sondern nur der Wert des ANY-Pointers. Die eigentlich übergebenen Daten (16 Byte) musst du in einem zweiten Schritt von der Adresse kopieren (oder gleich auswerten), auf die der ANY zeigt. z.B. mit BLKMOV oder eine Kopier-Schleife in AWL programmieren. Die IN-Adresse des FC darf für BLKMOV nicht auf Daten in TEMP des Aufrufers zeigen, sondern muss DB- oder E/A/M-Adressen erhalten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
"0123456789 ABC" erfüllt die Vergleiche (vermutlich) auch ... (und der String soll 16 Zeichen lang sein)
Der String soll 16 Zeichen lang sein? Oder die StringVariable inklusive der 2 Byte LängenAngabe?
Ich war von letzterem ausgegangen und habe deshalb mit "00000000000000" und "99999999999999", also je 14 Zeichen, verglichen.

Und ich hatte Unsinn geschrieben bezüglich der Vergleiche ganzer Strings. Von Ralfs Idee war ich sooo begeistert gewesen, dass ich mich total vergaloppiert hatte. Sorry vielstmals.
Der Vergleich zweier gleichlanger Strings ist natürlich bestimmt durch den ersten Unterschied der beiden Strings von links nach rechts gesehen.
Was weiter rechts noch passiert ist dann irrelevant für das VergleichsErgebnis.
 
ich schließe aus dem DB-Dump des OP und der Bezeichnung des Ganzen, dass hier ein Zeitstempel an eine Prägemaschine (Nadelpräger ?) übertragen wird. Weiter denke ich, dass wenn da andere Zeichen drinstehen dann werden die sicher auch gedruckt - ist aber dann Quatsch auf dem Bauteil ...
Wenn wir hier noch bei dem Punkt sind "ist der Inhalt korrekt ?" dann würde ICH, immer vorausgesetzt, dass hier wirklich ein Zeitstempel übertragen wird / werden soll, nicht nur die Zeichen vergleichen sondern ob es tatsächlich etwas sinnvolles ergibt - also wie im Beispiel des Dumps von Beitrag #10 ein Datum und eine lfd.Nummer (?).
 
Zurück
Oben