584.812 aktive Mitglieder*
5.286 Besucher online*
Kostenfrei registrieren
Anmelden Registrieren
HEIDENHAIN Forum

Datei "Tabelle.tab" gesperrt nach Zugriff über SQL

Beitrag 31.08.2020, 14:24 Uhr
dev-hm
dev-hm
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 31.08.2020
Beiträge: 7

Moin,

Ich bin ein Software-Entwickler und komme somit nicht aus dem Umfeld (Nie eine echte CNC bedient, eben nur die verschiednen Simulatoren benutzt -> Siemens, Heidenhain)
Ich arbeite mich gerade in die Heidenhain NC-Programmierung ein. Also (.h) programme schreiben welche dann einen Anwendungsfall abdecken.
-> Jeder hier im Forum der NC-Programme für die Heidenhain schreiben muss für tut mir Leid, es ist ein reiner Krampf und das sagt ein Softwareentwickler biggrin.gif (#offtopic)

Vorab habe ich das was ich jetzt bei der Heidenhain vorhabe, bereits für die Fanuc bzw. Siemens über NC-Programme funktional umgesetzt..
Nun muss ich mich bei der Heidenhain TNC640 dranmachen..

Hier stoße ich aktuell auf das folgende Problem (wo ich hoffe, dass mir hier einer der Experten von euch helfen kann):
1. Ich habe ein Hauptprogramm welches mehrere Unterprogramm aufruft..
2. Eines der Unterprogramme liest Daten aus einer von mir zuvor definierten Tabelle "tabelle.tab" über SQL (TNC640)
2.1 Tabelle über den Config Bereich angelegt und beschrieben -> Tabelle funktioniert.
2.2 Lesen der Daten aus der Tabelle "TNC:\nc_prog\tabelle.tab" über SQL funktioniert.
3. Eines der anderen Unterprogramme schreibt nun Daten zurück in diese von mir zuvor definierten Tabelle "tabelle.tab" über SQL (TNC640)
3.1 Schreiben der Daten in die Tabelle "TNC:\nc_prog\tabelle.tab" über SQL funktioniert -> die neuen Daten sind nach dem Aufruf "SQL COMMIT" in der Datei "tabelle.tab" enthalten!
4. Diese Tabelle lade ich als Datei "tabelle.tab" direkt von der TNC "TNC:\nc_prog\tabelle.tab" runter (über die Heidenhain API "Interop.HeidenhainDNCLib") um diese abzuändern, und im Anschluss wieder unter dem selben Namen "tabelle.tab" auf die TNC "TNC:\nc_prog\tabelle.tab" rauf zu laden.
-> Hier habe ich jetzt das Problem, dass sich eben diese Datei nicht mehr auf die TNC zurückspielen lässt (nicht über die Heidenhain API und auch nicht über TNCremo), solange mein Hauptprogramm noch läuft! Stoppe ich mein Hauptprogramm ist die Datei freigegeben und ich darf sie auf der TNC überspielen. -> Das Lesen bzw. schreiben der Tabellen findet aber in einem Unterprogram statt, welches nach abarbeitung ja wieder geschlossen sein müsste (inklusive der Dateizugriffe ?)

Laut den Aussagen von einem Mitarbeiter welcher sich, im Vergleich zu mir mit den Maschinen auskennt, sollte genau dies aber möglich sein, da er sowas wohl genau so macht. Also eine Tabelle aus einem Programm raus beschreiben, diese vom PC runterladen -> abändern und im Anschluss wieder "hochladen" um diese dann vom Programm wieder auslesen zu können und das alles ohne das Program stoppen zu müssen.

Wenn ich mir seinen und meinen Ablauf anschaue, wie wir beide die Zugriffe über SQL auf Tabellen machen, finde ich keinen leider keinen Unterschied.

Hier mein program "tabelleschreiben.h" welches Daten in meine zuvor definierte die Tabelle schreibt:
CODE
BEGIN PGM TABELLESCHREIBEN MM
SQL QL51 "DROP SYNONYM TABELLE"; ggfs. vorhandenes Tabellen Synonym löschen.
SQL QL51 "CREATE SYNONYM TABELLE FOR 'TNC:\nc_prog\imc\tabelle.tab'"; Tabelle aus Dateisystem auf Synonym linken.
SQL QL52 "SELECT SPALTE1 FROM TABELLE";    Select abfrage für Spalte 1        

SQL BIND QL55 "TABELLE.SPALTE1"; Spalte 1 an lokale Variable QL55 binden

SQL FETCH QL51 HANDLE QL52 INDEX0; Daten aus Zeile 0 auslesen (es wird nur eine Zeile geben)
QL55 = Q1600; Wert aus Q1600 in Zeile 0 - "SPALTE1" schreiben

SQL UPDATE QL51 HANDLE QL52; Werte in Tabelle Updaten
SQL COMMIT QL51 HANDLE QL52; Änderung in Tabelle übernehmen

SQL BIND QL55; zuvor erzeugten link zu Spalte 1 entfernen
FN 20: WAIT FOR SYNC; Synchronisation der Daten
SQL QL51 "DROP SYNONYM IMCSTATE"; Benutztes Tabellen Synonym löschen.
END PGM TABELLESCHREIBEN MM


Ich habe zu dem Thema leider in der Doku nichts gefunden.

Mein aktueller Work-a-round ist die Tabelle über die DNC Schnittstelle von PC Seite über "DataAcess" zu beschreiben während mein NC-Programm läuft (dies führt zu keinem Fehler - da ja keine Datei mehr auf die TNC hochgeladen wird, sondern ich wohl direkt auf die Tabelle in der TNC schreibe) .. aber führt auf NC-Program Seite dazu, dass ich die "aktualisierten" Werte erst nach Mehrmaligem auslesen über SQL bekomme. -> Schau ich über TNCremo im Dateisystem auf der TNC in meine Tabelle "tabelle.tab" dann hält diese aber die neuen korrekten Werte! Wenn ich nun versuche parallel über SQL diese neuen Werte auszulesen, dann bekomme ich aktuelle nur die alten Werte. Erst nach mehrmaligem aufruf meines Unterprograms (welches die Daten über SQL liest), bekomme ich dann die neuen Daten.

Hoffe ihr könnt mir hier auf die Sprünge helfen wo mein Fehler liegt, da ich eben nicht vom Fach bin und diese Thematik ziemlich aufhält und Nerven frisst biggrin.gif

Danke & Gruß
Henrik

Der Beitrag wurde von dev-hm bearbeitet: 31.08.2020, 14:27 Uhr
TOP    
Beitrag 31.08.2020, 14:59 Uhr
dev-hm
dev-hm
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 31.08.2020
Beiträge: 7

Die Zusammenfassung für meine Frage(n):
1. Ist es möglich eine zuvor (über SQL-Zugriffe) gesperrte Datei auf der TNC explizit zu entsperren um diese vom PC aus überschreiben zu können ohne das ich mein Programablauf auf der Steuerung stoppen muss ?
2. Wie bekomme ich die Daten/Werte welche ich über die DNC schnittstelle direkt in die Tabelle schreibe mit meinem NC-Program Synchronisiert, das, wenn diese Daten erfolgreich geschrieben wurden ich auch die korrekten Daten/Werte beim nächsten zugriff über SQL ausgelesen bekomme ?
TOP    
Beitrag 31.08.2020, 19:03 Uhr
schwindl
schwindl
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 18.09.2008
Beiträge: 2.311

Hallo Henrik, eine solche Anfrage stellst Du am Besten direkt an HEIDENHAIN.
Hierzu die 08669313103 oder die [email protected] kontaktieren.


--------------------
Gruß
Schwindl
TOP    
Beitrag 31.08.2020, 20:13 Uhr
cgTNC
cgTNC
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 21.11.2010
Beiträge: 1.341

In den Beispielen im Handbuch seht BIND immer vor dem SELECT-Befehl.
Vielleicht hilft das.

FETCH ist im grunde überflüssig, weil der ausgelesene Wert in der nächsten Zeile überschrieben wird.Sollte aber auch nicht stören.

Gruß
cgTNC

Der Beitrag wurde von cgTNC bearbeitet: 31.08.2020, 20:17 Uhr
TOP    
Beitrag 01.09.2020, 08:20 Uhr
dev-hm
dev-hm
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 31.08.2020
Beiträge: 7

Moin,

Danke für Eure Antworten!
Ja die Themen sind ein wenig speziell und kommen so auch nicht im laufendem Betrieb bei euch vor..

@cgTNC: Ja ggfs. muss ich noch ne prüfung einbauen dafür zunächst das Fetch.

@schwindl: Ok schade, ja wird wohl mitunter eine der Letzten Möglichkeiten sein. Danke für den Kontakt!

Danke & Gruß
TOP    
Beitrag 01.09.2020, 14:15 Uhr
Wiesel
Wiesel
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 27.05.2019
Beiträge: 18

QUOTE (dev-hm @ 01.09.2020, 09:20 Uhr) *
Moin,

Danke für Eure Antworten!
Ja die Themen sind ein wenig speziell und kommen so auch nicht im laufendem Betrieb bei euch vor..

@cgTNC: Ja ggfs. muss ich noch ne prüfung einbauen dafür zunächst das Fetch.

@schwindl: Ok schade, ja wird wohl mitunter eine der Letzten Möglichkeiten sein. Danke für den Kontakt!

Danke & Gruß



Hallo,

handelt es sich bei dem beschrieben Fall um die gleiche Maschine?
Also bei der auf der du es versuchst und von dem Mitarbeiter bei dem es funktioniert?

Gruß
TOP    
Beitrag 01.09.2020, 20:06 Uhr
CRX
CRX
Level 3 = Community-Techniker
***
Gruppe: Mitglied
Mitglied seit: 29.11.2004
Beiträge: 206

Hallo zusammen

Dieses Problem ist schon speziell.
Warum habt ihr ein Tabellenformat in den Config Daten angelegt? Das *.tab Format ist ab 34059004 eine frei definierte Tabelle und muss nicht
in den Config Daten angelegt werden. Durch diese Definition können dann nur noch die in den Config definiertem Format angelegt werden.
Tipp von mir die Definition wieder löschen und eine neue Tabelle mit Tabelle.tab erstellen und mit Schlüsselzahl 555343 über Softkey zusätzliche Funktionen -Format editieren, das gewünschte Format erstellen.
Vieleicht ist damit das Problem schon gelöst.
Zudem würde ich die SQL Befehle aufs Minimum reduzieren. Also ohne bind, frech und comit.
Beispiel:
SQL SELECT QL55 "SELECT SPALTE1 FROM ' TNC:\TABELLE\TABELLE.TAB' WHERE NR == 0" ; Zeile 0 Spalte 1 lesen
SQL QL0 "UPDATE 'TNC:\TABELLE\TABELLE.TAB' SET SPALTE1 = ':Q1600' WHERE NR == 0"; Zeile 0 Spalte 1 schreiben mit Inhalt Q1600
Ist QL0 == 0, so war der Schreibvorgang erfolgreich.
Um das Ganze nun auch noch zu synconisieren, würde ich noch eine Spalte hinzufügen z.B SEM für Semaphor.
Das NC Programm schreibt eine 1 rein und die DNC Anwendung dann wieder auf 0. Nun kann das NC Programm auf Bearbeitung warten.
Beispiel:
LBL "LOOP"
CYCL DEF 9.0 VERWEILZEIT
CYCL DEF 9.1 V.ZEIT 0.5
SQL SELECT QL56 "SELECT SEM FROM ' TNC:\TABELLE\TABELLE.TAB' WHERE NR == 0"
FN 10: IF QL56 NE +0 GOTO LBL "LOOP"
....

Wenn das dann auch nicht funktioniert, so bleibt nur noch der Weg über die PLC.
Hier können dann Symbole definiert werden die von der NC beschrieben werden und per Subscribe von der DNC Komponetene ein Event in der DNC
Anwendung verarbeitet werden können
Hier wird es aber schwierig ab 34059009(Benutzverwaltung), da hier der Zugriff auf die PLC nur noch mit der PLC Schlüsselzahl funktioniert.
Heidenhain möchte eine Änderung von Q Parametern bzw. Aufgerufene NC Dateien nicht, um nicht während einem laufenden Programm eventuell
falschen Daten im Programm ein Crash gefahren wird.
Vieleicht kann man noch einen Anderen Weg ausprobieren. Über FN 38 kann ein String an die DNC Komponente geschickt werden, die dann die Tabelle
beschreibt und das Ergebnis aus der Tabelle im NC Programm gelesen werden.(über File Function testen ob Datei vorhanden)
Mal die Doku lesen. Ist auch ein Beispiel für FN 38 im SDK enthalten.

Siemens und Fanuc Steuerung lassen solch eine Änderung im laufenden NC Programm zu, was unter Umständen eben auch zu unerwünschten
Verfahrsätzen führen kann.

Gruß crx
TOP    
Beitrag 02.09.2020, 09:50 Uhr
dev-hm
dev-hm
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 31.08.2020
Beiträge: 7

Moinsn,

@Wiesel: Mein Kollege müsste auch eine TNC640 benutzen, der unterschied ist hier nur er arbeitet mit richtigen CNC Maschinen und ich hab eben nur den Simulator vor mir und keine echte Maschine. Ich hab sein Ablauf aber auch nie gesehen und gehe aktuell von aus, dass er eben irgendwann sein Ablauf stoppt, was dann die Möglich eröffnet für seinen Anwendungsfall Dateien austauschen zu können (anders kann ich es mir auch nicht erklären (Heidenhain hat mir am Telefon bestätigt das der Austausch von im NC-Program verwendeten Dateien nicht funktioniert während es ausgeführt wird)

@CRX: Moin und danke für deine lange Antwort. Ok das ".tab" ist hier vllt schlecht gewählt es sollte nur als Beispiel fungieren. Ich habe hier für meinen realen fall im Config Bereich eine ".state" Tabelle definiert mit eben verschiedenen Spalten. Dieser Weg wurde mir so gezeigt und von einem "freien" Format abgeraten.

Deine Idee mit der Semaphore klingt gut, aber kann ich hier leider nicht umsetzen, da ich mich an einen bereits für Fanuc und Siemens funktionierenden Ablauf anbinden muss. Hier kann ich vom Ablauf her nichts zusätzlich einbauen um solche "Checks" zu realisieren.. Könnte ich einfach Q-Parameter von außen beschreiben (so wie bei Fanuc bzw. Siemens) hätte ich die ganzen Probleme nicht biggrin.gif

Das mit dem SQL würde ich dann ggfs. dann als Optimierungs schritt angehen, wenn ich die Grundlegene von mir gewünschte Funktionalität abgebildet bekomme.

Das mit dem senden eines Strings von der Maschine aus über die DNC schnittstelle habe ich schon gesehn aber funktioniert glaube ich nur auf der TNC640 !? Da ich hier auch im Anschluss den gleichen Ablauf für die iTNC530 abbilden muss, macht es hier Sinn für beide Maschinen die gleiche Technik bzw. sehr ähnliche NC-Programme zu haben. Alleine wegen der Wartung falls sich etwas im Ablauf ändert.

Das man Q-Parameter bei Heidenhein nicht von außen abändern kann verstehe ich nicht wirklich (Ja ich kann die Gründe warum man es nicht will verstehen - Sicherheit) aber wer das nicht macht hat auch erstmal keine Probleme.. Ich möchte eben explizit Abläufe von außerhalb steuern oder ggfs eingreifen, damit ich eben Prozesse zur Laufzeit optimieren kann z.b.um die Qualität verbessern zu können smile.gif

Danke für eure Mühen smile.gif

Der Beitrag wurde von dev-hm bearbeitet: 02.09.2020, 09:50 Uhr
TOP    
Beitrag 02.09.2020, 17:38 Uhr
CRX
CRX
Level 3 = Community-Techniker
***
Gruppe: Mitglied
Mitglied seit: 29.11.2004
Beiträge: 206

Wenn du das ganze auch auf der iTNC530 umsetzen möchtest, muss ich von SQL Anweissungen abraten, da diese bei der iTNC530 einfach nicht gibt!
Warum man dir von den frei definierbaren Tabellen abgeraten hat, ist Unsinn. Diese gibt es eben auch auf der iTNC530.
Frei defininierbare Tabellen können auch ohne SQL gelesen und geschrieben werden.(TABOPEN, TABREAD, TABWRITE).
Diese sind wie auch die FN38 an der iTNC530 und TNC640 verfügbar.
Somit hättest du für beide die gleichen NC Programme.

Wenn ihr das mit Siemens und Fanuc ohne Synchronisation umgesetzt habt, stellt sich mir die Frage, woher die NC dann weiß, ob die Daten
schon bereitgestellt wurden?

Gruß crx
TOP    
Beitrag 03.09.2020, 09:20 Uhr
dev-hm
dev-hm
Level 1 = Community-Lehrling
*
Gruppe: Mitglied
Mitglied seit: 31.08.2020
Beiträge: 7

QUOTE (CRX @ 02.09.2020, 17:38 Uhr) *
Wenn du das ganze auch auf der iTNC530 umsetzen möchtest, muss ich von SQL Anweissungen abraten, da diese bei der iTNC530 einfach nicht gibt!

Das es SQL nicht gibt weiß ich. Hier werde ich dann eben mit TABOPEN etc arbeiten müssen. Es wird auch definitiv für die 640 und 530 jedweils eigene NC Programme geben. aber hier werden sich dann eben nur kleine Teile unterscheiden wie z.b. TABOPEN. sagen wir 90% der Programm werden weiterin gleich bleiben.

QUOTE (CRX @ 02.09.2020, 17:38 Uhr) *
Warum man dir von den frei definierbaren Tabellen abgeraten hat, ist Unsinn. Diese gibt es eben auch auf der iTNC530.
Frei defininierbare Tabellen können auch ohne SQL gelesen und geschrieben werden.(TABOPEN, TABREAD, TABWRITE).
Diese sind wie auch die FN38 an der iTNC530 und TNC640 verfügbar.
Somit hättest du für beide die gleichen NC Programme.

Die Frage kann ich dir nicht beantworten da ich nicht vom Fach bin und die Hintergründe nicht kenne warum die Kollegen das meinten -> mein erster Versuch war eben über die freien Tabellen..

QUOTE (CRX @ 02.09.2020, 17:38 Uhr) *
Wenn ihr das mit Siemens und Fanuc ohne Synchronisation umgesetzt habt, stellt sich mir die Frage, woher die NC dann weiß, ob die Daten
schon bereitgestellt wurden?

Bei der Siemens bzw. Fanuc ist mein NC Programm immer Synchron mit meinem externen Ablauf, da hier meine Daten/Werte welche ich von außerhalb in die Variable schreibe direkt ankommen, dies ist bei der Heidenhein bei mir leider nicht der Fall.

Gruß
TOP    



1 Besucher lesen dieses Thema (Gäste: 1)
0 Mitglieder: