TIA Rezeptur-Datensatzelemente im Script auslesen

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Draco,

die Werte eines Datensatzes werden in die Rezeptvariablen geschrieben, richtig. Die in einer Rezeptur projektierten Variablen sind jedoch quasi temporär von der Steuerung abgeklemmt, d.h. die Werte werden NICHT DIREKT zur Steuerung übertragen. Du kannst also die Rezeptvariablen beliebig manipulieren (Werte ändern), erst mit dem Befehl "SchreibeDatensatzvariablenInSteuerung" (Beachte: nicht "SchreibeDatensatzInSteuerung"!!) bekommt die Steuerung die neuen Werte mit.

Für die Anzeige von Rezepturvariablen kannst du auch alle verfügbaren Controls verwenden, erst mit den entsprechenden Systemfunktionen (siehe oben) gibt es dann quasi ein "Go live" auf der Steuerung.


Gruß, Fred


PS: Gerade noch eingefallen -> Such mal nach Schlagwörtern wie "Rezepturanzeige" und "Rezepturbild" (auch in Siemens-Doku)
 
Also mein Ansatz funktioniert(e) bisher auf einem 677 IPC und FlexibleRuntime folgendermaßen: Es gibt ein Script "ReadPage" der 10x das Script "ReadLine" aufruft. ReadLine greift wiederum auf die CSV-Datei anhand vom Index, der mitgeschickt wird, und liest die relevanten Daten aus die dann in Lokalvariablen kopiert werden. ReadPage setzt daraus dann die aktuelle Anzeige zusammen.
Funktioniert das so wie Du es jetzt auch auf dem Comfort Panel willst? Dann brauchst Du die Skripte doch nur an die Runtime-Hardware anpassen, sprich die Datei-Operationen durch die Pendants von Windows CE ersetzen. (und hoffen daß das Panel nicht zu langsam ist) Siehe die VBScript_WinCE.pdf im Anhang von Beitrag #1 der FAQ

Ich schreibe meine Skripte so, daß sie über eine Variable umschaltbar auf Windows-PC und WinCE-Panel funktionieren, weil ich will die Skripte ja auch mal auf den Engineering PC testen (also das WinCE-Panel auf dem Windows-PC simulieren). Wie ich das mache ist in der genannten FAQ in Beitrag #2 beschrieben.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Draco,

die Werte eines Datensatzes werden in die Rezeptvariablen geschrieben, richtig. Die in einer Rezeptur projektierten Variablen sind jedoch quasi temporär von der Steuerung abgeklemmt, d.h. die Werte werden NICHT DIREKT zur Steuerung übertragen. Du kannst also die Rezeptvariablen beliebig manipulieren (Werte ändern), erst mit dem Befehl "SchreibeDatensatzvariablenInSteuerung" (Beachte: nicht "SchreibeDatensatzInSteuerung"!!) bekommt die Steuerung die neuen Werte mit.

Für die Anzeige von Rezepturvariablen kannst du auch alle verfügbaren Controls verwenden, erst mit den entsprechenden Systemfunktionen (siehe oben) gibt es dann quasi ein "Go live" auf der Steuerung.


Gruß, Fred

Hi Fred

Damit wir uns nicht missverstehen - wenn ich einen Befehl "LadeDatensaz" absetze. Wo liegen dann meine Daten ?
Wenn ich zum Beispiel in der Rezeptur ein Daum "Werkzeugbezeichnung" habe. Und dieses guckt in der Projektierung der Rezeptur auf die Variable "Rezeptur\Werkzeugbezeichnung", die aber als Steuerungsvariable angelegt ist (DBxxx.DBWyyy). Wenn ich dann mit dem Befehl SmarTags ("Rezeptur\Werkzeugbezeichnung") den Wert dieser Variablen auslese - bekomme ich dann das geliefert was in der CPU liegt, oder das, was im Rezepturdatensatz steht den ich soeben geladen habe ?

Funktioniert das so wie Du es jetzt auch auf dem Comfort Panel willst? Dann brauchst Du die Skripte doch nur an die Runtime-Hardware anpassen, sprich die Datei-Operationen durch die Pendants von Windows CE ersetzen. (und hoffen daß das Panel nicht zu langsam ist) Siehe die VBScript_WinCE.pdf im Anhang von Beitrag #1 der FAQ

Nein Harald, s. oben. Das kann ja auf einem Comfort Panel unter TIA gar mehr nicht funktionieren. Denn auf dem Panel im TIA liegt die Rezeptur nicht in Form einer CSV Datei vor, auf die ich mittels "CreateObject" zugreifen könnte. Selbst auf einem IPC nach der Migration auf TIA wird es nicht mehr funktionieren weil das Ablageformat sich gravierend geändert hat.

Das Script zerlegt ursprungs die .CSV Datei und sucht sich dort die charakteristischen Variablen (Werkzeugbezeichnung, Werkzeugnummer etc.) zusammen.
 
...
Damit wir uns nicht missverstehen - wenn ich einen Befehl "LadeDatensaz" absetze. Wo liegen dann meine Daten ?
Wenn ich zum Beispiel in der Rezeptur ein Daum "Werkzeugbezeichnung" habe. Und dieses guckt in der Projektierung der Rezeptur auf die Variable "Rezeptur\Werkzeugbezeichnung", die aber als Steuerungsvariable angelegt ist (DBxxx.DBWyyy). Wenn ich dann mit dem Befehl SmarTags ("Rezeptur\Werkzeugbezeichnung") den Wert dieser Variablen auslese - bekomme ich dann das geliefert was in der CPU liegt, oder das, was im Rezepturdatensatz steht den ich soeben geladen habe ?
...

Hi Draco,

die Werte des geladenen Datensatzes liegen IMMER in den projektierten Rezepturvariablen, unabhängig davon, ob diese Variablen eine Anbindung zur Steuerung haben oder nicht.
Und dann die Unterscheidung:
1. Wenn deine Rezeptur offline ist (ist die AKTIVIERTE Einstellung "Synchronisation - Manuelle Übertragung einzelner geänderter Werte (Teach-In-Betrieb)"), dann würdest du mit Smarttags... den gerade geladenen Wert erhalten. Erst mit "SchreibeDatensatzvariablenInSteuerung" wird dieser Wert dann zur Steuerung transferiert.
2. Wenn deine Rezeptur online ist, dann würdest du mit Smarttags... ebenfalls den geladenen Wert erhalten. Gleichzeitig mit dem Ladevorgang wird dieser Wert sofort zur Steuerung transferiert.



Gruß, Fred
 
@Ferd: Vielen Dank.

Mal sehen, ob mir das weiter hilft. Die Voraussetzung dafür wäre, daß der Befehl "Rezeptur laden" ohne Schreiben in die Steuerung ehrblich schneller ist, als mit Schreiben in die Steuerung.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nein Harald, s. oben. Das kann ja auf einem Comfort Panel unter TIA gar mehr nicht funktionieren. Denn auf dem Panel im TIA liegt die Rezeptur nicht in Form einer CSV Datei vor, auf die ich mittels "CreateObject" zugreifen könnte.
Mit der Systemfunktion ExportDataRecords kann man Rezepturen/Datensätze ins csv-Format exportieren/speichern. Hatte ich schon in #2 erwähnt, aber wohl nicht prominent genug.

Harald
 
Mit der Systemfunktion ExportDataRecords kann man Rezepturen/Datensätze ins csv-Format exportieren/speichern. Hatte ich schon in #2 erwähnt, aber wohl nicht prominent genug.

Harald

Harald, nicht wahr :)

Ich habe es wohl gelesen und auch ausprobiert. Ist aber sinnfrei weil elend langsam. Ich kann nicht darauf warten bis er mir 10 Datensätze bei jedem Bildwechsel lädt, das ist zu langsam und wenn man das parallel machen will dann unterbindet das System weitere Versuche wenn 1x Export schon läuft und bricht ab. Das Problem ist, daß die Rezeptur an sich nicht im .CSV gelagert wird. Man könnte wohl die Rezepte beim Anlegen exportieren und direkt mit den Exporten arbeiten. Dann würde ich beim Versuch ein Rezept zu laden so zusagen erst Import machen und dann in die CPU laden. Das wäre möglicherweise ein Ansatz.
 
Zuletzt bearbeitet:
Nächste Frage: diese Unterschiede, zwischen Datenzugriff unter CE und unter richtig Windows.

Wenn ich eine Simulationsumgebung aufmache, sprich mein Panel simuliere. Wird der Datenzugriff dort auch simuliert oder erwartet die Simulation daß die Befehlssyntax wie unter unter richtig Windows aussieht ? Also CreateObject("Scripting.FileSystemObject") dürfte dann eigentlich nicht laufen, oder doch ?

Kann das vielleicht mal jemand ausprobieren ? Bin mir gerade nicht ganz sicher ob ich möglicherweise genau da dran stolpere. Thx.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ist aber sinnfrei weil elend langsam.
Ach, sind die Comfort Panels wirklich sooo schwach auf der Brust?:confused: Oder sind Deine Rezepturen so riesig? Wie lange ist "elend langsam"?

Um aus 10 Datensätzen jeweils ein paar interessierende Werte auszulesen braucht man gar nicht (den Umweg über) csv, man muß das Datei/Speicherformat auch gar nicht kennen, man braucht nur die 10 Datensätze nacheinander vom Speicher in die Rezepturvariablen einlesen und die interessierenden Werte auf andere HMI-Variablen umspeichern. Wie lange dauert das? (dabei werden die Datensätze nicht in die SPS geladen)

Ansonsten: so ein Comfort Panel ist nicht für Massendatenverarbeitung ala Excel ausgelegt. Kannst Du das Rezeptur-Inhaltsverzeichnis/Index nicht zu einer anderen Zeit erstellen, und evtl. nur aktualisieren beim Speichern von Datensätzen? Um wie viele Datensätze von wie großen Rezepturen geht es bei Dir?

Harald
 
Die Panel-Simulation läuft unter Windows, es müssen die Befehle für die PC-Runtime verwendet werden. Auf das Panel geladen laufen die Skripte unter WinCE und es müssen die Befehle für WinCE verwendet werden.
Es empfiehlt sich eine Meldeanzeige für die Meldungsklasse "System" in einem Bild zu haben, um die Runtime-Errors lesen zu können.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@draco,
hast du nicht die Möglichkeit, deine Anforderungen an die Rezeptur Verwaltung an einem
richtigen Panel zu testen. Die Rezepturverwaltung von Siemens wird oft verflucht (auch
von mir), aber Sie funktioniert in den aktuellen Versionen von WinCCflex und TIA wirklich gut
und zuverlässig.

Der Vorteil von der Rezepturverwaltung von Siemens ist das es ausstehende nachvollziehen
können was da passiert, bei der Scripterei ist das schon etwas anderes.

Ich nutze diese sehr ausgiebig, allerdings auf PCs mit Soft SPS und WinCC Runtime, diese
hat nicht den Flachenhals Hardware-Bus, da geht es über den Softbus und ist entsprechend
schnell.

Das ist meines Erachtens das bzw. Dein Problem, wenn das Panel die Daten durch grüne
oder violette Leitungen Jagd, beschäftigt dieses das Panel.
 
Die Panel-Simulation läuft unter Windows, es müssen die Befehle für die PC-Runtime verwendet werden.

Ich bin mir irgendwie bei diesem Punkt nicht sicher. Ich habe gerade eine Panel-Simulation laufen, und dort funktioniert scheinbar die Syntax nicht, die unter Panel PC ansonsten lief. Könnte das vielleicht mal einer ausprobieren um eine definitive dritte Meinung zu haben ? Wir reden von TIA V15.1. Thx
 
Ich habe gerade eine Panel-Simulation laufen, und dort funktioniert scheinbar die Syntax nicht, die unter Panel PC ansonsten lief. Könnte das vielleicht mal einer ausprobieren um eine definitive dritte Meinung zu haben ? Wir reden von TIA V15.1. Thx
Hast Du mal ein Beispiel, welcher Code unter V15.1 evtl. anders funktioniert? (ich habe allerdings kein V15.1)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast Du mal ein Beispiel, welcher Code unter V15.1 evtl. anders funktioniert? (ich habe allerdings kein V15.1)

Harald

Code:
Set RecFileSystemObjekt = CreateObject("Scripting.FileSystemObject")

    If    RecFileSystemObjekt.DriveExists(Drive)Then
        
        Set DriveName = RecFileSystemObjekt.GetDrive(Drive)
        
        If    RecFileSystemObjekt.FileExists(SourceFile) = True Then
            
            Set RecFileObjekt = RecFileSystemObjekt.GetFile(SourceFile)
             Set RecFileName   = RecFileObjekt.OpenAsTextStream(ForReading,TristateASCII) 'Openfile

            For i =1 To 14
                
                Value    = RecFileName.ReadLine            'Inhal steht im Value
                
                Select Case Left(Value, InStr(Value, ";") - 1)

               [... diese Stelle musste leider zensiert werden ... ]
                
            Next
            
            RecFileName.Close
            
        End If
        
    End If
 
Code:
Set RecFileSystemObjekt = CreateObject("Scripting.FileSystemObject")
    If    RecFileSystemObjekt.DriveExists(Drive)Then
        Set DriveName = RecFileSystemObjekt.GetDrive(Drive)
        If    RecFileSystemObjekt.FileExists(SourceFile) = True Then
            Set RecFileObjekt = RecFileSystemObjekt.GetFile(SourceFile)
             Set RecFileName   = RecFileObjekt.OpenAsTextStream(ForReading,TristateASCII) 'Openfile
            For i =1 To 14
                Value    = RecFileName.ReadLine            'Inhal steht im Value
                Select Case Left(Value, InStr(Value, ";") - 1)
               [... diese Stelle musste leider zensiert werden ... ]
            Next
            RecFileName.Close
        End If
    End If

Hallo Draco,

mehrere Fragen:
1. Was verbirgt sich hinter "Drive"?
2. Warum die Funktion "...GetDrive"? Verwendest du den DriveName irgendwo anders? Für das Einlesen der Datei wäre dies nämlich nicht notwendig.
3. Warum die Funktion "...GetFile"? Für das Einlesen der Datei wäre dies nämlich nicht notwendig.
4. Bezüglich der Schleife: Weißt du genau, dass IMMER mindestens 14 Zeilen in der Datei enthalten sind?


Ich hänge mal ein Script an, wie ich das Einlesen einer Textdatei in meinen Projekten behandle (funktioniert auf Panels und PCs), hilft vielleicht ein wenig weiter:
Code:
Function Utils_FIO_readFile(ByVal path)
' ####################################################################################################
' Liest eine Textdatei ein. Der Dateiinhalt wird inklusive Zeilenumbrüche zurückgegeben.
'
' @param 'path'    -> Pfad und Name der einzulesenden Datei als STRING
' @return 'result' -> Inhalt der eingelesenen Datei als STRING
'
'
' -------------------------------------------------------------------------------------------
' |   Version  | Autor | Änderung                                                           
' -------------------------------------------------------------------------------------------
' | 2016_01_21 |  fk   | Neuerstellung
'
' ####################################################################################################

    
    ' ##################################################
    ' Variablenreferenzen holen, Funktion initialisieren
    ' ##################################################
    Dim fso
    Dim file
    Dim textLine
    Dim fctStatus
    Dim result
    
    Const FOR_READING = 1
    Const EId_END_OF_FILE = 62
    
    fctStatus = EId_NO_ERROR
    result = ""

    On Error Resume Next




    ' ##############
    ' Funktionslogik
    ' ##############
    
    If SmartTags("osIsWinCe") _
    Then
        Set file = CreateObject("FileCtl.File")
        file.Open path, FOR_READING
        If Err.Number = EId_NO_ERROR _
        Then
            Do Until file.EOF
                textLine = file.LineInputString
                If textLine <> "" _
                Then
                    result = result & textLine & vbCrLf
                End If
                If Err.Number > EId_NO_ERROR _
                Then
                    fctStatus = EId_FILE_READING_FAILED
                End If
            Loop
        Else
            fctStatus = EId_FILE_OPENING_FAILED
        End If
        file.Close
    Else
        Set fso = CreateObject("Scripting.FileSystemObject")
        Set file = fso.OpenTextFile(path, FOR_READING)
        If Err.Number = EId_NO_ERROR _
        Then
            Do Until file.AtEndOfStream
                textLine = file.ReadLine
                If textLine <> "" _
                Then
                    result = result & textLine & vbCrLf
                End If
                If Err.Number > EId_NO_ERROR And Err.Number <> EId_END_OF_FILE _
                Then
                    fctStatus = EId_FILE_READING_FAILED
                End If
            Loop
        Else
            fctStatus = EId_FILE_OPENING_FAILED
        End If
        file.Close
    End If
    
    
    
    
    ' ################
    ' Funktionsausgang
    ' ################

    ' Rückgabewert übergeben
    Utils_FIO_readFile = result


    ' Funktionsstatus global bekanntmachen
    SmartTags("fctStatus_global") = fctStatus
    
    result = Null
    Set file = Nothing
    Set fso = Nothing
    
    
End Function


Gruß, Fred
 
Hallo Draco,

mehrere Fragen:
1. Was verbirgt sich hinter "Drive"?

Gruß, Fred

Huch! Olalala. Danke für den Hinweis.... Das Problem saß, wie so häufig, vor dem Monitor. Unter "Drive" waren wieder irgendwelche Pfade vergeben, die es unter Simulation nicht gibt (wäre mal interessant obs die auf nem echten Panel gibt). Deswegen ist diese Abarbeitung gar nicht bis in die IF Abfrage reigegangen.

2. Warum die Funktion "...GetDrive"? Verwendest du den DriveName irgendwo anders? Für das Einlesen der Datei wäre dies nämlich nicht notwendig.

Nein, an sich nicht. War nur zum Überprüfen der Existenz des Laufwerks gedacht. Sicherungspfade kann der Benutzer nämlich z.T. selber eingeben.

3. Warum die Funktion "...GetFile"? Für das Einlesen der Datei wäre dies nämlich nicht notwendig.

War mir nicht bewussst... Dachte, man macht es immer so.
 
Zurück
Oben