Werkzeugdaten mit Delphi von Sinumerik auslesen

Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Peter,
ich benutze die Variable edgeData, die sollte cuttEdgeParam ersetzen.

Aktuell bekomme ich alle Schneidendaten des ersten Werkzeugs mit der Adressierung "/Tool/Compensation/edgeData[u1,i]".
CodeSchnipsel:


sprintf(cItemName, "/Tool/Compensation/edgeData[u%i,%i]",1,iNum);
RetVal = AGL_NCK_GetNCKDataRWByNCDDEItem(cItemName, &m_nckDatarwitem, &m_iErrorPos);
RetVal = AGL_NCK_CheckVarSize(tmpConnNr, &m_nckDatarwitem, 1, 1, m_lUserVal);
// iNumber = AGL_GetErrorMsg(RetVal, Fehler, sizeof(Fehler));
m_nckDatarwitem.Buff = &diStatus;
RetVal = AGL_NCK_ReadMixEx(tmpConnNr, &m_nckDatarwitem, 1, 1, m_lUserVal);
printf("Wert des Schneidendatums %i ist : %d\n\n",iNum, diStatus);


Accon macht daraus Area 4 ,Unit 1,Block 20,RowCount 1,Column 1, Row 1 für WZ-TYP $TC_DP1.
Das stimmt soweit und bringt auch gute Werte.

Damit bekomme ich alle sinnvollen Werte für die Werkzeug- und Schneidendaten des ersten Werkzeugs.
Bei den Schneiden muss man noch für die weiteren Schneiden den Index i um 35 inkrementieren (maxnumCuttEdges_Tool).
Ob die Schneide existiert, kann ich ab Index 316 lesen, da ein Datensatz 315 Werte umfasst.

Leider weiss ich nicht, wie die weiteren Schneiden in dem Array verteilt sind.
Ich hoffe im Moment , dass ich diese Info irgendwo von Siemens bekomme.
 
Hallo Heinileini,
ich wollte nicht die Daten in der NC auswerten, sondern extern über C-Code auf die Werte zugreifen.
Da sind mir die Adressierung der Systemvariablen etwas rätselhaft. Vom extern kann ich nicht direkt $TC_DP1..n adressieren, sondern muss über die Variable edgeData zugreifen.
Hier liegt mein Problem
 
Zuviel Werbung?
-> Hier kostenlos registrieren
hilft das ?


edgeData (T, TUE) $TC_DPCx[y,z] x=ParamNo,y=ToolNo z=EdgeNo


Wichtig:2-dimensionale Variable, der Spaltenindex ist die T-Nummer.
Der Datentyp im NCK wird durch das MD18097 $MN_MM_TYPE_CC_TOA_PARAM festgelegt und kann aus dem File
_N_COMPLETE_TOA_ACX ermittelt werden.
Der Datentyp wird für die BTSS in den Datentyp TYPE_DOUBLE gewandelt
und muss durch die Anwendung wieder in den Datentyp des NCKs zurückgewandelt werden.
Einheiten und Wertebereiche
Physikalische Einheit: Datentyp:- TYPE_DOUBLE
Adressierung
Zeilenindex: Max. Zeilenindex: (SchneidenNr - 1) * $$numCuttEdgeParams_tu + ParameterNr $$numCuttEdgeParams_tu * $$maxnumCuttEdges_Tool
 
leider nein, die Beschreibung habe ich auch. Fuer $TC_DPCx[y,z] ist y die ToolNo und waere auch bei edgeData der Parameter T.
Wenn ich aber fuer T 2 eingebe, kommt Fehlermeldung ungültige Werte.
Habs auch auf der Steuerung im Diagnose NC-Variablen mit gleichem Ergebnis : edgeData[1,x] ist ok, abb 2 geht´s schief.
 
ich wollte nicht die Daten in der NC auswerten, sondern extern über C-Code auf die Werte zugreifen.
Da sind mir die Adressierung der Systemvariablen etwas rätselhaft. Vom extern kann ich nicht direkt $TC_DP1..n adressieren, sondern muss über die Variable edgeData zugreifen.
Hier liegt mein Problem
Das war mir wohl klar, dass Du die Daten extern auswerten möchtest.
So, wie ich es kenne (das muss nicht mehr der aktuelle Stand sein), sind die Daten in der TOA-Tabelle ganz simpel und klar strukturiert. Das einzig etwas kompliziertere ist die "Verkettung" der KorrekturDatenSätze beim VorhandenSein von mehreren Schneiden.
Was sich hinter Index "um 35 inkrementieren" und "ab 316" verbirgt, kann ich nur vermuten: das dürfte sich auf die ByteAdresse innerhalb einer Zeile der TOA beziehen bzw. innerhalb des AntwortTelegramms. Vermutlich steht ab Adresse 35 die D-Nr der FolgeSchneide und ab 316 dürften die KorrekturDaten für die FolgeSchneide stehen (entweder der komplette KorrekturDatenSatz oder der Teil davon, der nicht sowieso identisch ist mit dem Satz für Schneide 1).
Anscheinend stellt Dir Deine LeseFunktion bereits die Daten aller DatenSätze zu einem WZ zusammen. Werden denn die Bedeutungen der Daten (z.B. die SpaltenÜberschriften) mitgeliefert oder kannst Du diese abfragen?
Gibst Du mit "maxnumCuttEdges_Tool" vor, für wie viele Schneiden Du maximal die KorrekturDaten haben möchtest oder wirst Du damit darüber informiert, wie viele Schneiden für das WZ angelegt sind?
Wenn ich Dich richtig verstanden habe, kannst Du nicht Zeile für Zeile (D-Nr) die TOA-Tabelle auslesen, sondern nur WZ für WZ (T-Nr & Duplo-Nr) die Daten abfragen - wobei sich der Umfang der Daten aus der Anzahl angelegter Schneiden ergibt?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Welche daten ich genau benötige: Ich brauche die Daten von jedem sich in der Maschine befindenden Werkzeuges. Also auch in der Spindel sowie Wechselarm.
Länge, Radius, Standzeit usw. Das benötige ich weil ein Abgleich mit der Solllänge bzw Sollradius des Werkzeuges passieren soll.

OK, also entnehme ich jetzt den letzten Beiträgen das es möglich ist! Das sind schon mal gute Nachrichten. Aber dennoch bleibt bei mir das Problem bestehen dass ich keine Testumgebung habe.
Einfach so an der Maschine testen, kommt glaube ich nicht so gut. Ich denke da kann man dann auch einiges falsch machen und im schlimmsten Falle die Maschien stillegen! Ist das so?

Ich hatte jetzt Kontakt mit einem Anwendugstechniker von Siemens.
Dieser hatte mir als einen Weg den "OPC AU Server" der Sinumerik genannt. letztendlich ist mir auch egal welcher weg zu Ziel führt.
Wäre "OPC" eine Alternative oder würdet Ihr davon abraten?
Wichtig ist mir eben das es sicher ist und man keinen Schaden an den Maschien verursachen kann.
Davon mal abgesehen, weiß ich nicht ob der OPC-Server auch bei unseren Maschinen auch integriert ist. Das müsste ich als nächstes mal rausbekommen, sonnst wäre der weg ja sinnlos. Die neueren Maschinen sollten ja nicht das Problem sein.
Vorteil bei OPC wäre für mich eben das ich da warscheinlich eher an eine Testumgebung komme. Es gibt ja diverse OPC-Server-Simulationen. Somit wäre ich auch zum testen nicht an eine Maschie gebunden!



Hat einer das auslesen der Werkzeugdaten in Kombination Delphi mit Libnodave schon mal realesiert?


@Burkhard6 du schreibst dein Programm in C?
 
Ich fürchte. die TOA-Tabelle ist nicht mehr so einfach strukturiert.
DIe variable edgeData ist eine sogenannte BTSS-Variable, mit der ein Zugriff auf die NC-Datenstruktur möglich ist.
Diese Variablen werden benutzt, wenn man z.B. mit dem OEM-Paket oder "EASY Screen" eigene Masken auf der PCU realisiert. Auf der PLC wird der Zugriff über den NC_VAR-Selektor realisiert, mit dem die entsprechende interne Adressierung Area, Unit, Block, Row ermittelt werden. ACCON AG-Link nutzt die gleiche Syntax, um die entsprechenden Werte für Area.... zu ermitteln, mit denen dann der eigentliche Read-Befehl abgesetzt wird. DIe Variable numCuttEdgeParams gibt an, wieviel Parameter pro Schneide existieren (35). Daraus ergibt sich, dass die Werte der zweiten Schneide bei Offest 35 beginnen. Bei Offset 315 (9 Schneiden * 35 Werte) beginnt ein Array von 9 Werten, wo man sieht, ob die entsprechende Scheide existiert.

Damit endet jetzt mein Wissen. Ich bekomme jetzt nicht mehr heraus, wo hier in dem Gebilde die Daten des zweiten Werkzeugs beginnen.
 
Opc wird wohl auch funktionieren. Ich habe Montag zum Thema OPC Siemens im Haus. Da werde ich mal ebenfalls nachhaken, wie die WZ-Daten ausgelesen werden können.
Die Sinumerik Solution Line hat OPC eigentlich im Bauch. Ob das nur gilt, wenn ich einen PCU bzw. IPC habe, weiss ich aber nicht. Es wird über eine Option aktiviert, der Preis sollte deutlich unter 1000€ liegen.
Zu Deiner Frage: Ich schreibe die Programme in C++ mit Visual Studio. ACCON sollte auch mit Delphi funktionieren. Wie die Syntax bei Libnodave aussieht, kann ich so nicht beantworten.
Ich glaube, die Adressierung erfolgt über Area, Unit, Block, Row. Das sollte aber kein Problem sein, die Werte kann man mitdem NCVAR-Selektor ermitteln.
Vielleicht hat ja jemand auch für Libnodave schon die Werte ermittelt und irgendwo abgelegt.
Bis auf die Geometriewerte komme ich an alle WZ-Werte inkl Standzeit, Ist-Ort etc. heran.
Ich denke,die Geo-werte werde ich auch demnächst im Griff haben.
Dann könnte ich Dir die Codeschnipsel in C geben und Du müsstest entsprechend in Delphi umschreiben. Ob Libnodave oder ACCON sollte dann vom Budget abhängen :)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
lHabs auch auf der Steuerung im Diagnose NC-Variablen mit gleichem Ergebnis : edgeData[1,x] ist ok, abb 2 geht´s schief.

auf welcher Steuerung fragst du das so ab ? edgeData hat mehr als 2 Parameter
ich kann mit /Tool/Compensation/edgeData[u1,c1,1] oder [u1,cX,1] den Werkzeugtyp aller Werkzeuge abfragen auf der Steuerung.
 
Steuerung ist eine 840Dsl SW Stand4.8
Danke, hab´s gerade ausprobiert. Blöd ist, wenn man den Parameter cX nicht einfügt, rutscht der letzte Parameter an die zweite Stelle und aus /Tool/Compensation/edgeData[u1,cX,Y] wird
/Tool/Compensation/edgeData[u1,Y] und er bringt immer den Parameter Y des 1. Werkzeugs, weil er default c1 annimmt. :-(
Werde gleich mal versuchen,die Werte aller Werkzeuge zu lesen.
AUs welcher Beschreibung hast Du denn die Info. DokOnCD liefert mir die nicht, oder ich hab sie nicht gefunden.
 
Ich fürchte. die TOA-Tabelle ist nicht mehr so einfach strukturiert.
... interne Adressierung Area, Unit, Block, Row ...
Unit? Block? Und ich fürchte, meine Kenntnisse sind nicht mehr up to date.
Sie stammen noch aus einer Zeit, als der Platz für die TOA-Tabelle knapp bemessen war und man deshalb so wenig wie möglich Spalten belegt hat, um noch ein paar mehr Zeilen (D-Nrn) herauszuschinden. Unverzichtbar in der NC waren die Infos zur Identifizierung des WZs (T-Nr, Duplo-Nr), die GeometrieDaten (WZ-Typ, Länge, Radius, VerschleissLänge, VerschleissRadius) und die D-Nr der Folgeschneide.
WZ-StatusBits (z.B. gesperrt, gebrochen, verschlissen, ...), AufenthaltsOrt des WZs (Spindel, Greifer, MagazinPatz), GeometrieDaten (die nur für KollisionsBetrachtungen bei der Suche nach einem geeigneten MagazinPlatz relevant sind), Typ des WZ-Kegels, StandZeit, RestZeit und ggfs weitere Daten, die nicht pro Schneide, sondern pro WZ anfallen, standen nicht in der TOA-Tabelle, sondern in der PLC.

Welche daten ich genau benötige: Ich brauche die Daten von jedem sich in der Maschine befindenden Werkzeuges. Also auch in der Spindel sowie Wechselarm.
Länge, Radius, Standzeit usw. Das benötige ich weil ein Abgleich mit der Solllänge bzw Sollradius des Werkzeuges passieren soll.
Abgleich von SollLänge und SollRadius? Und die VerschleissWerte? RestZeiten? Status gebrochen? ...
Frage aus reiner Neugier: wozu der Abgleich? Sollen die WZ-EinstellPlätze mit den beim bzw. nach dem Einsatz ermittelten aktuellen Erkenntnissen versorgt werden? Will man ermitteln, ob z.B. die StandZeiten realistisch genug vorgegeben wurden?
In der TOA-Tabelle können auch noch Daten von WZen stehen, die sich noch nicht, nicht mehr bzw. nicht ständig in der Maschine befinden, z.B. weil sie "nur" manuell eingewechselt werden.
 
Opc wird wohl auch funktionieren. Ich habe Montag zum Thema OPC Siemens im Haus. Da werde ich mal ebenfalls nachhaken, wie die WZ-Daten ausgelesen werden können.
Die Sinumerik Solution Line hat OPC eigentlich im Bauch. Ob das nur gilt, wenn ich einen PCU bzw. IPC habe, weiss ich aber nicht. Es wird über eine Option aktiviert, der Preis sollte deutlich unter 1000€ liegen.
Zu Deiner Frage: Ich schreibe die Programme in C++ mit Visual Studio. ACCON sollte auch mit Delphi funktionieren. Wie die Syntax bei Libnodave aussieht, kann ich so nicht beantworten.
Ich glaube, die Adressierung erfolgt über Area, Unit, Block, Row. Das sollte aber kein Problem sein, die Werte kann man mitdem NCVAR-Selektor ermitteln.
Vielleicht hat ja jemand auch für Libnodave schon die Werte ermittelt und irgendwo abgelegt.
Bis auf die Geometriewerte komme ich an alle WZ-Werte inkl Standzeit, Ist-Ort etc. heran.
Ich denke,die Geo-werte werde ich auch demnächst im Griff haben.
Dann könnte ich Dir die Codeschnipsel in C geben und Du müsstest entsprechend in Delphi umschreiben. Ob Libnodave oder ACCON sollte dann vom Budget abhängen :)

Das wäre natürlich richtig toll wenn du mir die Codeschnipsel zur Verfügung stellen würdest.

So, leider hat sich der Weg über OPC bei mir erledigt. Wie du schon erwähnt hast beinhaltet die 840D SL nur den OPC-Server. Damit fallen über 2/3 unserer Maschinen durch das Raster!
Also bleibt mir jetzt nur noch der Weg mit LibNoDave. Tja, aber genau hier habe ich ja nach wie vor das Problem, dass ich keine Testumgebung habe.
Burkhard?? Wie testest du denn deinen Code?

Ich habe mich jetzt nochmal mit Simulationssoftware beschäftigt. Dabei sind mir 2 "Kostenlose" Varianten aufgefallen.

CodeSysV3:



TwinCAT3:


Das was ich jetzt nicht wirklich rausfinden konnte, könnte ich jetzt so ohne weiteres Libnodave damit testen?
Im besten Fall wäre es sogar möglich ein PLC Backup einzuspielen. Dann könnte ich unter fast realen Bedinungen testen.
Habt Ihr Erfahrungen oder weitere Infos für mich?

Achso.
Wenn ich jetzt an einer realen Steuerung testen würde. Wie sicher ist die ganze Geschichte. Wie groß ist die Warscheinlichkeit das man einen Schaden verurchsen kann? ( Ich will nur lesend zugreifen)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
mit verlaub
Wenn ich lese das Du Codesys oder Twincat führ eine nutzbare Testumgebung im Zusammenhang mit Werkzeugverwaltung und Siemens 840Dsl hältst
Zweifle ich an deinen Kenntnissen bezüglich Sinumerik Steuerung.

Nochmal mit Sinutrain kannst du viel testen aber halt keine Kommunikation mit dem NCK per Libnodave weil die PLC nicht vorhanden ist.
Mit dem VNCK kann man eine Schnittstelle zur PLC simulieren damit müsste man auch eine Verbindung per Libnodave zusammen basteln können.
mit dem Programmierpacket HMI OA kann man auf alle NC Variablen zugreifen (ohne Libnodave) testen ist ohne reale Hardware oder VNCK aber auch nicht möglich.
Mit der neuen SimulationsSoftware für die Sinumerik ONE könntest du das Testen da dort alles vorhanden ist PLC NCK HMI . aber kostet Geld und passt auch nicht für 840D PL oder alte 840Dsl
 
Ich teste hier mit einer Teststeuerung, die bei uns im Betrieb für einen Probelaufstand zuständig ist und somit in der Regel nicht aktiv läuft.
Die Verbindung erfolgt mit der PLC der Teststeuerung über ACCON AGLink. Ohne eine reale Steuerung wird es wohl nicht möglich sein, da Du nur dort auch die entsprechenden Werkzeug- und Magazindaten hast. PLC-Simulationen oder Fremdsysteme wie Twincat bringen da nichts, weil Du ja Daten einer CNC brauchst. Ausserdem sind die Funktion bei Twincat mit ADS-Befehlen ganz unterschiedlich zu Sinumerik.
Wenn Du nur Daten der NC liest und keine Daten schreibst, sollte es wenig Probleme mit der Steuerung geben. Man sollte allerdings im Kopf behalten, daß man auf der gleiche Nahtstelle rumturnt, die auch die Kommunikation zwischen CNC,PCU(IPC) und PLC benutzt.

Warum ist die OPC-Variante erledigt? Hast Du noch alte Steuerungen (Sinumerik Powerline) im Verbund?
 
Hallo Peter,
ich hatte mit dem OA-Paket in der Vergangenheit immer eine Verbindug zu einer realen NC aufgebaut, die mir aber nicht immer zur Verfügung stand.
Könnte man den VNCK bei der Entwicklung mit dem OA-Paket benutzen, um sowohl Werte aus der CNC und PLC über die CAP-Schnittstelle zu bekommen?
 
mit verlaub
Wenn ich lese das Du Codesys oder Twincat führ eine nutzbare Testumgebung im Zusammenhang mit Werkzeugverwaltung und Siemens 840Dsl hältst
Zweifle ich an deinen Kenntnissen bezüglich Sinumerik Steuerung.

Peter, ganz so falsch liegst du da nicht. Aber ich bin hier um genau das zu ändern. Deswegen dauert es auch immer wieder bis ich hier mal antworte, denn ich mache mich in der Zeit weiter schlau.

Programmierpacket HMI OA: Danke für den Vorschlag. Problem was ich hierdabei aber sehe, ist das ich das auch nur auf 840D SL anwenden könnte. Somit würde ich nicht alle Maschinen erreichen können. Und eigentlich will ich keinerlei Änderungen an der Steuerung vornehmen müssen.

Warum ist die OPC-Variante erledigt? Hast Du noch alte Steuerungen (Sinumerik Powerline) im Verbund?

Ja OPC ist leider gestorben, weil ich ältere Maschinen dabei habe die keinen Server integriert haben. Des weiteren... Der OPC-Server ist zwar bei der 840D SL integriert, aber eben auch nicht kostenlos.

OPC wäre glaube meine erste Wahl gewesen, aber aufgrund der kosten und der Verfügbarkeit an unseren Maschinen kein Weg mehr für mich.



Mittlerweile gibt es Neuigkeiten.
Ich konnte mir eine Maschine in der Firma zum testen sichern. Ist aktuell keine Produzierende Maschine. Sie steht quasi schon eine ganze Weile rum und ich darf sie nutzen.

Also wäre erstmal das Problem Testumgebung gelöst.

Da ich mich ja nun für LibNoDave entschieden habe, habe ich es natürlich in meinem Delphi Installiert. Beim Durchstöbern ist mir die Demo aufgefallen.

Also würde ich gerne erstmal mit der NoDaveDemo(TNODave Test-Utility) eine Verbindung erstellen.

LibNoDave bietet ja einige Protokolle an.

MPI-Protocol
MPI-Protocol(Andrew´s Version without STX)
MPI-Protocol(Step7 Version)
MPI-Protocol(Andrew´s Version with STX)
PPI-Protocol
ISO over TCP
ISO over TCP (CP-243)
IBH-Link
IBH-Link (PPI)
S7Onlinx.dll
AS-511
Deltalogic NetLink PRO

Da ich ja wie gesagt noch einiges zu lernen habe bevor ich in die vollen gehen kann, wollte ich euch fragen ob es irgendwo eine gute Beschreibung der Protokolle gibt.
Wo die Unterschiede liegen und noch wichtiger, welche Protokolle für mich relevant sind.
 
Herik, wenn Du auch auf ältere Maschinen zugreifen musst, weiss ich nicht, wie Du an die notwendigen Daten kommen kannst. Die Verbindung zwischen NC (wo die WZ-Daten liegen) und PLC könnte bei der Powerline anders organisiert sein. (Vielleicht kann Peter da mal ein Statement zu geben..) Du greifst ja immer über die PLC auf die CNC zu und die PLC müsste auf die Bereiche sauber hinkommen. Allerdings scheint es ja bei Produkten wie "HMI auf PC" ja auch zu funktionieren.
ES gibt in der Libnodave ein Beispiel für Werkzeugdaten. Vielleicht probierst Du das mal das Beispiel an einer Powerline.
 
Zurück
Oben