DotNetSiemensPLCToolBoxLibrary (LibNoDave) Zugriff auf Dual-Port RAM / FB15

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich wollte Dir durchaus ein weinig auf die Füsse treten, Manuel.

Wenn Dich der Begriff IPO-Takt schon in Verlegenheit bringt, kann ich nicht ahnen, dass sich dahinter 10 Jahre Erfahrung in NC-Programmierung verstecken.
Erfahrung in NC-Programmierung vielleicht, aber evtl. Null Erfahrung mit dem Arbeiten an einer NC-gesteuerten Maschine/Anlage?
Ich bezweifele, dass Du mehr als nur den NC-ProgrammQuellCode lesen musst, um den NC-Programmierern dass Leben zu erleichtern.
Für jede Maschine/Anlage noch eine individuelle Liste der definierten Funktionen, AchsLängen, Geschwindigkeiten, KollisionsBedingungen, u.s.w. . . .

Das Mitlesen der Schnittstelle zwischen der PLC und der NC in Echtzeit ist dafür m.E. absolut nicht erforderlich und das HerumSchreiben in dieser Schnittstelle mehr als gefährlich.
Wenn Du erfahren willst, welche BetriebsArtenGruppen, Kanäle, M-Funktionen, H-Funktionen, welche R-Parameter, welche Achsen u.s.w. bei einer Maschine/Anlage definiert sind und welche Bedeutung/Wirkung sie haben, dann lies die Doku der Maschine/Anlage.

Durch das Studieren der Schnittstelle zwischen NC und PLC wirst Du einiges über die Komplexität der Maschine/Anlage erahnen können, aber nichts erfahren, das Dich in die Lage versetzt, Syntax- oder Plausibilitäts-Prüfungen oder ähnliches in einem NC-Programm-Editor zu realisieren.

Ganz offensichtlich haben 20 Jahre Erfahrung in HochsprachenProgrammierung Dich stärker geprägt, als 10 Jahre Erfahrung in NC-Programmierung.
Ich bin der letzte, der neue Ideen im Keim ersticken möchte - ganz im Gegenteil - aber ich fürchte, Du siehst vor lauter Bytes nicht mehr, wie leicht man vom entfernten Schreibtisch (oder unterwegs vom Handy) aus durch Umknippsen von einem oder mehreren Bits Tonnen von Material unkontrolliert in Bewegung setzen kann/könnte.
Ich bleibe deshalb ganz eisern bei meinem Einwand.

Wünsche Dir ein schönes WE - trotzdem, Heinileini

PS:
Du willst automatisch ZeilenNummern (sprich: SprungZiele) generieren/einfügen???
Sei auch damit bitte "übervorsichtig"!!! Du weisst, dass . . .
- es völlig "legal" ist, ein und dieselbe ZeilenNr in einem (Siemens-)NC-Programm mehrfach zu benutzen?
- dass u.a. die begrenzte Anzahl der zur Verfügung stehenden ZeilenNrn dazu zu verleiten kann, ganz absichtlich ZeilenNrn mehrfach zu vergeben?
- dass nicht nur aus "Performance-Gründen" die SprungBefehle unterscheiden, ob ab dem SprungBefehl oder ab ProgrammAnfang nach dem SprungZiel gesucht wird?
- dass man oft genug nicht nur sehenden Auges, sondern wohlüberlegt etlichen ProgrammZeilen keine ZeilenNr verpasst?

 

[Peter Gedöns]

ah Heinileini
lass ihn mal machen, er wird dadurch eine Menge lernen.
Was er beschrieben hat gibt es ja schon als SINUTRAIN / oder die richtig teure Variante VirtualNCK.

 

[Manuel_84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja ich weiß vielleicht nicht was ein IPO Takt ist, wenn mich das in deinen Augen zu einem schlechteren Programmierer oder was auch immer macht, dann ist es halt so. Aber ich sehe wie umständlich und Zeit raubend NC programmieren in der Automations Branche ist. Wenn das Programm in einer Zeile mit 20 Variablen steht und man jede einzelne per Hand im Diagnose Fenster eingeben muss, Array Variablen mit anderen Variablen in der Klammer gar nicht mitgerechnet. Da kommt mir jedes Mal das Grausen wenn ich daran denke wie viele Leute seit Jahren so umständlich arbeiten müssen, wenn ich das mit Visual Studio vergleiche wo man sich jeden Wert jeder Variable jederzeit anschauen kann im dem man mit der Maus drüber fährt, dann braucht es niemanden wundern warum ich damit nicht gerne arbeite.
Mein Tool analysiert und evaluiert alle Variablen die im Programm verwendet werden, macht daraus eine Tabelle in der man alle Werte lesen und schreiben kann ohne vorher eine halbe Stunde lang Variablen rauszusuchen und einzutragen. Man kann damit auch auf einen Blick sehen warum es in einer Zeile steht weil alle Variablen bzw Bedingungen berechnet und farbig angezeigt werden damit man sofort sieht woran es liegt. Ist es zb eine M Funktion oder eine adbb Variable kann man automatisch mit einem Klick zum entsprechenden Netzwerk im PLC Programm springen.
Wegen der Zeilennummern, man muss sie ja nicht neu generieren und ob man eine oder mehrere einfügen will ist auch jedem selbst überlassen. Außerdem kann man einstellen in welchen Abständen und in welchem Format die Nummern wahlweise auch automatisch vorm Programm übertragen generiert werden.
Wenn es fertig ist soll man einfach nur seine Programme testen können bevor man sie auf eine Maschine übertragt und dann erst feststellen muss, dass man irgendwo eine Klammer vergessen oder einen Denkfehler hatte oder man sich bei einer Variable verschrieben hat. Eben genau darum weil es gefährlich ist in Nc Programmen Fehler einzubauen.
Wie gesagt es soll eine Hilfe und Erleichterung für Nc Programmierer sein. Nachdem ich selbst schon damit arbeite, weiß ich wie viel einfacher meine Arbeit damit geworden ist und noch werden wird.

Schöne Grüße
Manuel

 

[Heinileini]

Da kommt mir jedes Mal das Grausen wenn ich daran denke wie viele Leute seit Jahren so umständlich arbeiten müssen, wenn ich das mit Visual Studio vergleiche wo man sich jeden Wert jeder Variable jederzeit anschauen kann im dem man mit der Maus drüber fährt, dann braucht es niemanden wundern warum ich damit nicht gerne arbeite.

Das kann ich sehr, sehr gut nachvollziehen, Manuel!
Das, was häufig als G-Code bezeichnet wird, kann man eigentlich nur verstehen und akzeptieren und lässt sich eigentlich nur dann erklären und verzeihen, wenn man an die Zeiten zurückdenkt, als die NC-Programme noch die Form eines zu einem Ring zusammengeklebten Lochstreifens hatten.
ProgrammSpeicher gab's noch nicht bzw. sie waren so winzig und teuer, dass man nicht lange überlegen musste, ob man lieber M00 oder M0 oder einfach nur M eintippt.
Aber Dein Bestreben mit der automatisierten ZeilenNummernVergabe erinnert mich ebenfalls an eine Zeitreise zurück zum Commodore PET.

Ja, diese Sprache ist für Hochsprachen-, Assemblersprachen- und auch PLC-Programmierer gleichermassen sehr gewöhnungs- aber auch sehr "entwöhnungsbedürftig" - keine Frage.
Darauf aufgesetzte Sprachen, wie z.B. "CL800", haben versucht, dem G-Code eine etwas freundlichere Maske aufzusetzen. Mit dem Erfolg, dass das Erstellen von NC-Programmen noch umständlicher, aufwendiger und praxisfremder wurde und man sich für das Testen der Programme dennoch auf die Ebene des G-Code begeben, sich also im EndEffekt mit 2 Programmiersprachen herumschlagen musste.
SimulationsMöglichkeiten bieten die Steuerungen normalerweise - schlimmstenfalls nur per "SatzVorlauf" mit Berechnung.

Du hast absolut Recht, dass man sich zahlreiche Verbesserungen und Arbeitserleichterungen einfallen lassen kann und einfallen lassen sollte.
Dass man aber beim Überstreichen z.B. einer M-Funktion mit dem Cursor automatisch ein "passendes" Netzwerk des PLC-Programms angezeigt bekommt, halte ich für schwachsinnig.
Derjenige, der in der PLC die M-Funktion programmiert hat und sie testen will, weiss, wo er nachsehen muss. Alle anderen interessiert es nicht und hat es auch nicht zu interessieren.
Wenn ich bei einem Taschenrechner die Taste für Quadratwurzel drücke, will ich auch nicht angezeigt bekommen, wie der ProgrammSchnipsel aussieht, der die Berechnung ausführen soll.
Wer vom NC-Programm aus in der PLC, sprich in einem Teil des BetriebsSystems der Maschine/Anlage herumbohrt, gehört erschossen. Maschinen-/Anlagen-Hersteller, die dies vom Anwender erwarten, ebenso.
Einerseits wird nach SicherheitsFunktionen und z.B. Kapselung geschrien und andererseits soll die Nahtstelle zwischen PLC und NC nicht nur freimütig gelesen, sondern auch beschrieben werden können?
Ich denke nicht, dass man überhaupt die Nahtstelle von aussen "sinnvoll" beschreiben und damit reproduzierbar irgendwelche sinnvollen Dinge bewirken kann.
Aber ein "sinnloses" Stochern an der Nahtstelle ist nicht harmloser. Die Nahtstelle ist sehr zeitkritisch und auch allerkleinste Störungen müssen unbedingt vermieden werden.
Ich sehe nach wie vor nicht, wie Dir diese Nahtstelle bei der Realisierung Deiner Funktionalitäten helfen soll oder könnte.
Eine Editor-ähnliche Einrichtung, einen ProgrammGenerator, eine Simulation (die nicht auf der NC läuft) kannst und musst Du ohne diese Realisieren.

Gruss, Heinileini

PS:
Wenn Du Excel statt eines TextEditors zum Erstellen/Pflegen/Analysieren von NC-Programmen verwendest, kannst Du damit schon einige Deiner Ideen umsetzen . . .

 

[Hans54216]

Hallo Manuel,

du hast dir da auf jeden Fall eine Anspruchsvolle und zeitaufwändige Aufgabe ausgesucht, bei der du viel Über die Steuerung lernen kannst.

Wenn dir schon der IPO (Interpolation Takt) nichts sagt, wie sieht es dann mit Vorlauf/Hauptlauf, Alias (DEFINE AS), Endian (Byte Drehung zwischen PLC und NC) aus?

Bei einem Editor, welcher die Definitionen der Maschine aufsammelt und einen einfachen Syntax-check durchführt, sowie bei online Verbindung durch mouse over den Wert der Variable (wie in der Ansicht für GUDs/LUDs oder Plc/Nc Variablen) anzeigt, wirst du noch erfolg haben. Dann wird es aber schon recht kompliziert.

1. s7comm ist nicht echtzeitfähig (Zyklus treu)
2. Vorlauf/Hauptlauf
3. DualPortRam: Dieser kann vom Maschinenhersteller selbst eingeteilt werden und von der NC per ($A_DBB, $A_DBD, $A_DBR) mit verschiedenen Datentypen beschrieben und gelesen werden (Auch per Bit Kodierung per B_AND und B_OR). In der PLC wird er per FC21 gelesen und beschrieben und dort kann wieder ein ganzer Bereich mit unterschiedlichen Datentypen beschrieben werden.
3. PLC: Du müsstest in Echtzeit das kompletten Programm simulieren um alle Eventualitäten (Sprünge,...) zu berücksichtigen, und das ohne Daten da diese nicht so schnell zur Verfügung stehen.

Hallo Hans,
das mit dem NC Var Selektor klappt hervorragend. Du hattest gesagt das du einen Bereich für M-Funktionen kennst aber der nur einen IPO Takt geht. Wie heißt den der Bereich, leider finde ich ihn nicht und was meinst du mit einem Takt. Wenn man ihn öfter liest, wird er nicht mehr aktualisiert oder wie?

public static readonly NC_Var SSYNAC_Madr = new NC_Var(0x82, 0x40, 0xE, 0x0, 0x78, 0x1, 0x4, 0x2);
public static readonly NC_Var SSYNAC_Mval = new NC_Var(0x82, 0x40, 0x7, 0x0, 0x78, 0x1, 0x7, 0x4);

Auf der Variable steht für einen IPO Takt (1ms * Faktor -> bei uns typisch 2ms oder 4ms) der Wert. Da die NC pro IPO maximal einmal antwortet und das auch nur, wenn sie noch zeit hat ist das kein gangbarer Weg per s7comm. Nur der Trace erfasst die Daten mehr oder weniger sicher per IPO, dafür jedoch nur eine sehr begrenzte Anzahl.

Bei M-Funktionen musst du auch beachten, dass man diese unterschiedlich programmieren kann:

M60
M1=60

DEFINE M_ABC AS M60
DEFINE ABCD AS M1=60

M_ABC,
ABCD

Nachdem mein Programm alle Variablen abdecken soll ist das jetzt ein extremer Aufwand für mich, nachdem ich gesehen habe wie viele Variablen es gibt im Var Selektor, darum versuche ich am Wochenende mal die Datenbank die hinter dem Programm steckt selbst zu verwenden und im DotNetLib eine Klasse zu machen mit der man dann eine Variable in die benötigten Daten umwandeln kann um sie auszulesen. Falls das klappt köntet ihr das ja eventuell zu eurer Bibliothek hinzufügen, dann braucht niemand mehr den Var Selektor zu verwenden, der ist ja echt ziemlich umständlich.

Umständlich ja, aber enthält auch ne kleine Beschreibung sowie die Anomalien der Siemens Variablen welche mal 0 und mal 1 basiert sind.

Ich finde darin auch keinen Bereich für selbst angelegte GUDs, weil ich die auch schreiben möchte. Das Auslesen Über Datei ist ja super, aber damit kann man leider nicht schreiben.

Das hab ich zu einem früheren Zeitpunkt hier in diesem Beitrag schon erklärt wie das funktioniert.

Habe Übrigens probiert eine Schreibfunktion für die PlcNckVars dazu zu machen, das klappt gut. Warum fehlte eigentlich die Schreibfunktion?

Weiß nicht was du meinst. Die Schreibfunktion hab ich von Anfang an mit integriert.

In der Firma für die ich gerade arbeite, haben sie in der PLC ein Programm geschrieben, das der man eine GUD Variable angeben kann und aus dieser wird dann der Bereich und die anderen Daten gelesen, damit schreiben sie sie dann auch wieder.
Gibt es in der LibNoDave eine Möglichkeit Gud zu schreiben?

Siemens liefert für die PLC den FB5 (lesen/schreiben von GUDs). Es wird sicher dieser verwendet und kein selbst programmierter.

LibNoDave ist rein senden und empfangen von S7comm. Wenn du also die Adresse der GUD weißt, kannst du diese lesen und auch beschreiben. Wie oben schon geschrieben hab ich das hier im Beitrag schon erklärt.

 

[Manuel_84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Lol, manchmal kommt es mir echt so vor als ob NC nicht viel mehr als ein erweiterter Lochstreifen ist.

Bei den M-Funktionen wird nicht das Netzwerk angezeigt sondern im Simatic Manager aufgemacht und dort hingesprungen. Natürlich nur wenn man das Projekt und den Manager hat. Die die ihn nicht haben brauchen ihn auch nicht die die ihn haben und sehen wollen warum das Nc Programm bei einer M-Funktion hängen bleibt können dann etwas weniger umständlich. Das ist alles.
Nach dem ich selbst gerade Dreh-, Fräsmaschinen und Schweißmaschinen mit kleinen Automationen Grund und Auto in Betrieb nehme, brauche ich das sogar relativ oft. Aber ich weiß was du meinst, die meisten Programmierer machen entweder NC oder PLC, nur die wenigsten beides. Aber für die Leute die damit nichts anzufangen wissen, verwenden es halt einfach nicht.

 

[Manuel_84]

Hallo Hans,

hoffe das deine Quotes richtig angezeigt werden,...

Das hab ich zu einem früheren Zeitpunkt hier in diesem Beitrag schon erklärt wie das funktioniert.

Hättest du dazu villeicht einen Link?

Weiß nicht was du meinst. Die Schreibfunktion hab ich von Anfang an mit integriert.

Es gibt ein ReadValue(NC_Var) aber kein WriteValue(NC_Var, Value), habe später eh gesehen das es PlcNckVar abgeleitet von PlcVar gibt. Vielleicht liegt das an einer Inkompatibilität zwischen C++ und C#, aber ich konnte meine List<PlcNckVar> nicht an WriteValues übergeben. Musste da noch eine eigene Funktion dafür machen die dann in der Dll deine WriteValues Aufruft.

Bei M-Funktionen musst du auch beachten, dass man diese unterschiedlich programmieren kann

Danke für den Tipp, ich kannte zwar M=60 und M60 aber M1=60 hatte ich noch nie gesehen. Vermutlich für Kanal 1 M60. und das mit den DEFINES ist generell noch ein Thema das ich erst noch einbauen muss. Man kann das ja auch für R-Parameter und viele andere Sachen verwenden.

Ich habe nicht vor die PLC zu simulieren, das einzige wofür ich die PLC brauche ist um gewisse Variablen daraus zu lesen und in der Variablentabelle darauf zuzugreifen. Mein Programm soll aber im keine M-Funktionen an die PLC schicken und sie dazu bewegen irgendwelche Ausgänge zu setzen und womöglich irgendetwas dabei zerstören. Das wäre viel zu gefährlich. Ausser man simuliert die PLC mit PLCSim dann wäre das zum Testen im Büro durchaus praktisch.
Ich muss nur wissen welche M-Funktionen auf True sind damit ich anzeigen kann wo das Programm hängt.
Es soll so sein, das man zu einer Maschine kommt und sieht das sie irgendwo im Programm hängt.
Dann macht man mein Tool auf, ließt alle verwendeten Parameter ein, setzt ggf. noch einen Parameter der an das Unterprogramm übergeben wurde (PROC).
jetzt kann mein Programm anzeigen wo die NC im Unterprogramm steht, welche Variablen welche Werte haben, welche Bedingungen erfüllt sind...
Neben bei hat man noch einen Ersatz für die Nc Diagnosetabelle und spart sich das mühsame und zeitraubende raussuchen der Variablen, wenn man dessen Werte sehen oder ändern möchte, kann man das dann ganz bequem machen.
Man könnte theoretisch wenn alles fertig ist NC Programme und Unterprogramme simulieren, aber wenn dann auch nur um sie zu testen, nicht um eine Nc in irgendeiner Art und Weise zu ersetzen. Es macht ja auch wenig Sinn. Wenn sich keine Achsen bewegen kommen bestimmte Eingänge nicht und das Programm würde früher oder später sowieso stehen bleiben. Nur um vielleicht zu sehen in Welcher Zeile welche Achse wo steht. Das kann man sich natürlich anzeigen lassen.
Es wird auch die Funktion geben M-Funktionen einfach zu ignorieren oder einen Brekpoint zu setzen wenn True den man dann manuell überspringen muss.
Man soll z.B eine Unterprogramm damit testen können das einem Werte errechnet und zurückgibt. Damit man im Büro bereits sehen kann das man sich nicht vertippt hat und sich alles gut überlegt hat. Dafür kann man das Programm dann auch Zeile für Zeile debuggen. Die Werte kann man sich einmal Online holen und später wieder Offline damit weiterarbeiten.
Also ist Echtzeit und PLC Simulieren, für mich nicht ausschlaggebend.

Schöne Grüße

Manuel

 

[Hans54216]

Hättest du dazu villeicht einen Link?

Schau mal auf Seite 23 und 24.

Es gibt ein ReadValue(NC_Var) aber kein WriteValue(NC_Var, Value), habe später eh gesehen das es PlcNckVar abgeleitet von PlcVar gibt.

Die DotNet lib sowie LibNoDave sind ja für die PLC programmiert worden. Der PlcNckTag erbt vom PlcTag und dieser enthält auch die gemeinsamen Methoden. Die Klasse NC_Var hab ich für die bekannte Stuktur des NC-VAR-Selector (PLC FB2/FB3) hinzugefügten. Diese Klasse verwende ich eher um die Null Basierte Variable anzulegen und per GetNckTag() bekomme ich dann das exakte Ziel.

Danke für den Tipp, ich kannte zwar M=60 und M60 aber M1=60 hatte ich noch nie gesehen. Vermutlich für Kanal 1 M60. und das mit den DEFINES ist generell noch ein Thema das ich erst noch einbauen muss. Man kann das ja auch für R-Parameter und viele andere Sachen verwenden.

Siemens hat 5 Extention für die M-Funktionen. Diese können z.B. für die Spindeln verwendet werde. M1=3, M2=3
Das hat aber nichts mit dem Kanal zu tun. Für jeden Kanal hast du ja unabhängig voneinander die gesamte Pallette der M-Funktionen.

Du solltest dich in diesem Zusammenhang erst mal mit der PLC in Kombination mit der 840 befassen.

Auch ist es so, das die NC zwar die M-Funktion ausgibt und einen FB2 (entspricht normal OB1) Zyklus wartet ob die PLC eine Einlesesperre ausgibt, diese ist jedoch allgemein und hat nur bedingt mit der M-Funktion zu tun.
Sprich gibt die NC z.B. ein M7 (HDK ein) aus wird nicht diese die NC aufhalten, sondern die DB2 Einlesesperre im Kühlmittelbaustein welcher durch die M7 gestartet wird.

 

[Hans54216]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss nur wissen welche M-Funktionen auf True sind damit ich anzeigen kann wo das Programm hängt.
Es soll so sein, das man zu einer Maschine kommt und sieht das sie irgendwo im Programm hängt.
Dann macht man mein Tool auf, ließt alle verwendeten Parameter ein, setzt ggf. noch einen Parameter der an das Unterprogramm übergeben wurde (PROC).
jetzt kann mein Programm anzeigen wo die NC im Unterprogramm steht, welche Variablen welche Werte haben, welche Bedingungen erfüllt sind...
Neben bei hat man noch einen Ersatz für die Nc Diagnosetabelle und spart sich das mühsame und zeitraubende raussuchen der Variablen, wenn man dessen Werte sehen oder ändern möchte, kann man das dann ganz bequem machen.

Durch die Variable ActBlock siehst du wo der Programmzeiger gerade steht. (Aktueller NC Satz)
Bei den Variablen kommt der Vorlauf ins Spiel. Diese zeigen teilweise schon Werte an, welche sie erst in der Zukunft besitzen, aber diurch den Kode im Vorlauf bestimmt ist.

Es gibt Variablen welche im Vorlauf und welche im Hauptlauf gelesen und beschrieben werden. Wenn du Zeitkritisch oder G64 programmierst solltest du das auch im G-Kode beachten. Zu dem Thema gehört auch daß STOPRE.

 

[Manuel_84]

Danke das mit dem ActBlock kann ich sehr gut gebrauchen.
Mit dem Vorlauf und Hauptlauf hatte ich auch schon ein paar mal was zu tun, wie jeder wahrscheinlich, wenn das Programm nicht das tut was man will. Da hilft oft STOPRE um den Vorlauf zu stoppen.
Wie und ob ich das in meinem Programm berücksichtigen kann muss ich mir noch überlegen. Ich könnte schon immer 5 Zeilen im voraus lesen außer es kommt STOPRE, aber ob das beim Fehlersuchen hilfreich sein würde oder die Leute nur verwirren würde ist schwer zu sagen.
Vielleicht mach ich das optional.

Habe mir heute nochmal eure ganze Unterhaltung durchgelesen. Soweit ich das gesehen habe ist auf Seite 24 das erste mal davon geredet Adressen von Guds aus der gud acx zu bestimmen.
Auf Seite 37 bedankt sich KES_CK bei dir für das super Code snippet zum interpretieren von acx.
Leider konnte ich das snippet weder im Forum noch in der Bibliothek finden.
Habt ihr das schon eingebunden?

SG Manuel

 

[Hans54216]

Mit dem Vorlauf und Hauptlauf hatte ich auch schon ein paar mal was zu tun, wie jeder wahrscheinlich, wenn das Programm nicht das tut was man will. Da hilft oft STOPRE um den Vorlauf zu stoppen.
Wie und ob ich das in meinem Programm berücksichtigen kann muss ich mir noch überlegen. Ich könnte schon immer 5 Zeilen im voraus lesen außer es kommt STOPRE, aber ob das beim Fehlersuchen hilfreich sein würde oder die Leute nur verwirren würde ist schwer zu sagen.
Vielleicht mach ich das optional.

Du brauchst keine Zeilen im Vorlauf lesen, sondern die NC macht das und wenn keine Einlesesperre oder STOPRE für deinen Satz hast, zeigst du eventuell die faschen Werte an.
Dafür müsstest du in so einem Fall den Vorlauf selber zurück rechnen.

Habe mir heute nochmal eure ganze Unterhaltung durchgelesen. Soweit ich das gesehen habe ist auf Seite 24 das erste mal davon geredet Adressen von Guds aus der gud acx zu bestimmen.
Auf Seite 37 bedankt sich KES_CK bei dir für das super Code snippet zum interpretieren von acx.
Leider konnte ich das snippet weder im Forum noch in der Bibliothek finden.

Seite 24:
DotNetSiemensPLCToolBoxLibrary (LibNoDave) Zugriff auf Dual-Port RAM / FB15

 

[Manuel_84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Hans,
das Programm auf der Seite kenn ich, ich dachte das ihr daran inzwischen noch was gemacht hattet. Alles klar.

 

[KES_CK]

Gibt es eigentlich auch eine Möglichkeit per DotNetSiemensPLCToolBoxLibrary ein NC / PLC Archiv zu machen? bzw. hat sich schon jemand mit den Thema beschäftigt?

 

[Thomas_v2.1]

Mit welcher Software erstellst du denn üblicherweise so ein Archiv, und wo läuft diese?
Wenn die Daten über Netzwerk ausgelesen werden, dann erstellst du am besten mit Wireshark eine Aufzeichnung davon, und dann kann man sehen ob und wie man dieses nachbilden kann.

 

[KES_CK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mit welcher Software erstellst du denn üblicherweise so ein Archiv, und wo läuft diese?
Wenn die Daten über Netzwerk ausgelesen werden, dann erstellst du am besten mit Wireshark eine Aufzeichnung davon, und dann kann man sehen ob und wie man dieses nachbilden kann.

Hallo Thomas,
die Archive werden üblicherweise mit der Software der Bedienoberfläche (Sinumerik Operate) erzeugt. Ich habe die Software auch bei mir auf dem Laptop und
habe von Beiden Varianten eine Aufzeichnung gemacht.
Die Capture-Files sind aber relativ groß (>25MB) und bekomme ich nicht hochgeladen. Kann ich Dir das auch irgendwie anders zukommen lassen?

Gruß Christian

 

[Hans54216]

Das Archiv ist ja im ACX Format, was einem Siemens Binärformat entspricht. Somit bringt dir der Wireshark recht wenig.

Archiv erstellen läuft in der HMI. Du kannst zwar noch aufzeichnen welche Daten alles angefordert werden, das siehst du aber auch wenn du das Archiv öffnest (Siemens Tool oder Notepad).
Entscheidend ist wie du die Dateien verschachtelst. Ich hab mir das mal angesehen, es aber dann sein lassen und auf die fertige Siemens Lösung gesetzt.

 

[Hans54216]

Hallo Thomas,
Die Capture-Files sind aber relativ groß (>25MB) und bekomme ich nicht hochgeladen. Kann ich Dir das auch irgendwie anders zukommen lassen?

Per 7z zippen

 

[KES_CK]

Zuviel Werbung?
-> Hier kostenlos registrieren

Per 7z zippen

War auch mein erster Gedanke, wird aber nur minimal kleiner.

Das Archiv ist ja im ACX Format, was einem Siemens Binärformat entspricht. Somit bringt dir der Wireshark recht wenig.

Archiv erstellen läuft in der HMI. Du kannst zwar noch aufzeichnen welche Daten alles angefordert werden, das siehst du aber auch wenn du das Archiv öffnest (Siemens Tool oder Notepad).
Entscheidend ist wie du die Dateien verschachtelst. Ich hab mir das mal angesehen, es aber dann sein lassen und auf die fertige Siemens Lösung gesetzt.

Wenn ich mir die Captures anschaue sieht es so aus als wenn erst eine Datei mit einer einer Liste des jeweiligen Bereichs angefordert wird und dann jede Datei einzeln hochgeladen wird.
Ist vermutlich zu aufwendig, da was selber zu machen und vor allen dingen je nach NC-Softwarestand noch Anpassungen zu machen.

Gruß Christian

 

[Thomas_v2.1]

Deine Logfiles sind so groß weil dort noch eine SSH-Session mit aufgezeichnet wurde. Vermutlich gehören diese Daten aber nicht mit zur Sicherung.
Wenn du in der Filterzeile tcp.port == 102 eingibst, dann hast du nur die Kommunikation über den TCP-Port 102, über den hier vermutlich vollständig die Sicherung abgewickelt wird.
Wenn du dann wählst "Spezielle Pakete exportieren" und dann nur Displayed anwählst, dann ist die Datei nur noch 1MB groß (gezippt unter 200 kB).

Ich würde sagen, dass prinzipiell alle Funktionen die ich dort sehe auch in der Bibliothek vorhanden sind, für die S7 Bausteine sowieso, für den NC Teil müsste man sehen woher die ganzen Dateinamen stammen die dort ausgelesen werden. Soweit ich weiß lassen sich ja auch Verzeichnisinhalte auslesen an denen man sich dann entlang hangeln könnte. So funktioniert es beim SPS Teil ja auch, es wird erst eine Bausteinliste abgefragt und dann die jeweiligen vorhandenen Bausteine heruntergeladen.

 

[Hans54216]

Ich würde sagen, dass prinzipiell alle Funktionen die ich dort sehe auch in der Bibliothek vorhanden sind, für die S7 Bausteine sowieso, für den NC Teil müsste man sehen woher die ganzen Dateinamen stammen die dort ausgelesen werden. Soweit ich weiß lassen sich ja auch Verzeichnisinhalte auslesen an denen man sich dann entlang hangeln könnte. So funktioniert es beim SPS Teil ja auch, es wird erst eine Bausteinliste abgefragt und dann die jeweiligen vorhandenen Bausteine heruntergeladen.

Wie oben geschrieben funktioniert das reine laden/lesen der Dateien noch recht einfach. Um alle Dateien zu sichern musst du zunächst einen Leseauftrag auf den Hauptordner machen, welcher immer Vorhanden ist. Als Antwort bekommt du ein File welches die Dateien/Ordner direkt unter dem Ordner enthält. Dann gehst du halt alle Ordner durch bis diese keine weiteren enthalten.

Die Schwierigkeit ist dann aber das ganze als Archiv zu verpacken. Wie geschrieben handelt es sich um ein Binär Format welches schon einen erhöhten Aufwand zur folge hat um die Füllbytes und Checksummen raus zu finden. Ich hab das mal für die GUDs gemacht.

Das Binär Archiv ist sowie so nicht zukunftsweisend, da Siemens mit der Evo Line/One auf ein Zip File setzt. Dann wird es recht einfach, da dieses mit den zipper öffnen und packen kannst.