584.826 aktive Mitglieder*
5.070 Besucher online*
Kostenfrei registrieren
Anmelden Registrieren
DMG MORI Forum

Global One - Integration. Innovation. Quality.

CTX beta 1250 TC mit 840D SL Renishaw Problem???, Fehler 14756 Kanal 1: Satz Bewegungssynchronaktion: falscher Wert

Beitrag 16.11.2018, 10:42 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Hallo zusammen,

seit 4 Jahren nutze ich einen Renishaw RMP60 Taster in HSK 63 Aufnahme an der oben genannten Maschine.

Seit gestern gibt es in Verbindung mit Messungen diesen oben erwähnten Fehler 14756. Wenn der Fehler ansteht (und das passiert jetzt immer nach 1-4 Messoperationen), dann können alle Achsen noch im Jog bewegt werden, jedoch kann ich weder irgendein Programm starten, noch einen WKZ Wechsel (Kette) durchführen. Einzig ein aus und einschalten der Maschine behebt den Fehler zunächst. Dann kann ich wieder einen Messprozess starten und nach 3-4 Messungen steht der Fehler wieder an.

Hat da irgendjemand eine Ahnung, was das Problem sein könnte? An dem Messprozess unter DIN/ISO wird es nicht liegen, da auch ältere und ungeänderte Messprogramme diesen Fehler auslösen. Die Kugel des Tasters läuft gut. Kein Schlag. Hat hier jemand eine Idee, was immer wieder zu diesem Fehler führt? Lässt sich das Fehler irgendwie durch eine M-Funktion quittieren? Manchmal, wenn ich im T,S,M erst M120 (Taster aktiv) setze, dann mit Jog einen Schaltweg auslöse, und wieder mit M121 (Taster inaktiv) abwähle, kann ich ein Messprogramm starten. Aber auch nicht immer. Kurios!!!

Der Beitrag wurde von ingo1974 bearbeitet: 16.11.2018, 10:43 Uhr
TOP    
Beitrag 16.11.2018, 12:53 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Nachtrag:

Ich habe einen Messprozess, der ein Spannmitteldurchmesser erfasst als eine Art "Kalibriermessung". Es sind allerdings andere Richtungen, in die der Taster dabei ausgelenkt wird. Dieser Prozess lief in Schleife eben etliche Male sauber durch. Jedoch der andere Messprozess nicht, obwohl ich den gestern den ganzen Tag hab erfolgreich laufen lassen. Vielleicht ist eine Messflanken-Richtung defekt an dem Renishaw?

Kann mir jemand die genaue Funktionsweise von dem Befehl TC_BC_POS nennen? Ich habe mir alle PDF-Anleitungen zu der Maschine angeschaut und nach dem Befehl gesucht. Nirgendwo erscheint er per STRG+F Suche. Das Internet hat mir auch keine Antwort geliefert. Vielleicht mache ich da ja einen grundsätzlichen Fehler bei der Programmierung? Jedoch seltsam, dass der Prozess erst den ganzen Tag funktionierte und dann auf einmal nicht mehr.
TOP    
Beitrag 16.11.2018, 13:11 Uhr
Micha1405
Micha1405
Level 6 = Community-Doktor
******
Gruppe: Mitglied
Mitglied seit: 14.07.2008
Beiträge: 920

Hallo Ingo
Falls die Batterie des Meßtasters i.O. ist würde einfach bei DMG anrufen. Sollte der schnellste Weg sein.
Gruß
Michael
TOP    
Beitrag 16.11.2018, 13:13 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

QUOTE (Micha1405 @ 16.11.2018, 12:11 Uhr) *
Hallo Ingo
Falls die Batterie des Meßtasters i.O. ist würde einfach bei DMG anrufen. Sollte der schnellste Weg sein.
Gruß
Michael


Habe ich schon dort gemeldet das Problem. Rückruf kommt jeden Moment. Batterien habe ich gewechselt.
TOP    
Beitrag 16.11.2018, 13:35 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

So. Kollege aus Hilden hat gerade angerufen. Er wollte mit mir gemeinsam etwas versuchen, um den Fehler oder die Meldung zu beheben oder der Sache auf den Grund zu gehen. Er bat mich in Automatikbetrieb zu gehen und mit dem Softkey ">" nach rechts zu erweitern (weitere Menüoptionen/Softkeys) und dort sollte ich dann Ausschau halten nach SK "Synchronaktionen". Gibt es bei mir aber nicht. Auch nicht, wenn ich auf Stufe 6 der Freigabe stehe (durch Eingabe von DMG Passwort). Also konnte er mir jetzt nicht weiterhelfen und wird das Problem an andere Kollegen weiter geben, die sich dann bei mir melden wollen. Tja ... leider kommt das häufig vor, dass bei gewissen Problemen einfach nicht weitergeholfen werden kann.
TOP    
Beitrag 16.11.2018, 14:46 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Ich poste jetzt mal hier meinen Programmcode vom Messprozess. Vielleicht fällt ja jemandem eine unzulässige Bewegung auf oder eine Aktion, die zu dem Fehler eventuell führen könnte.

QUOTE
N100 DEF INT COUNT=1 ; Einstich Zaehler
N101 DEF REAL MESS[30,2] ; Messtabelle definieren

N102 DEF INT ERROR ; Definition fuer WRITE-Befehl
N103 DEF INT SCHLEIFE ; Schleifenzaehler
N104 DEF STRING[30] PFAD ; Verzeichnis-Pfad
N105 DEF STRING[10] NAME ; Zeichnungsnummer/Sachnummer
N106 DEF STRING[7] SERIE ; Zeichnungsnummer/Sachnummer

N107 DEF REAL ENGRAVE[10,10]
N108 DEF STRING[90] ENGRAVETXT[5]
N109 DEF REAL GROOVE[10,5]


;======= Einstichtabelle auslesen ========
N110 EXTERN _N_ARRAY_GROOVE_MPF(VAR REAL[,5])
N111 EXTERN _N_ARRAY_ENGRAVETXT_MPF(VAR STRING[90] [])
N112 EXTERN _N_ARRAY_ENGRAVE_MPF(VAR REAL[,5])
N113 _N_ARRAY_GROOVE_MPF(GROOVE)
N114 _N_ARRAY_ENGRAVETXT_MPF(ENGRAVETXT)
N115 _N_ARRAY_ENGRAVE_MPF(ENGRAVE)

N116 IF($P_SIM OR $P_SEARCH OR $P_ISTEST) GOTOF NN9999
N117 $P_UIFR[1,Z,FI]=RG950 ; Feinverschiebung setzen!

;NCG#TAILINIT#gm_eqc75.com#TAILINIT#*NCG;*RO*;*HD*
;#"Reitstock Initialisierung"#1#1#1#1#2#3#0#*NCG;*RO*;*HD*
N118 TAILINIT(1,0,0,0,10,500)
;#END#*NCG;*RO*;*HD*


;=============================================================
N119 R1=5.05 ;Kugeldurchmesser
N120 R2=90 ;B1-Lage
N121 R3=0 ;C4-Lage
N122 R4=0.02 ;Korrektur linke Schulter
N123 R5=0.14 ;Korrektur rechte Schulter
;Diese Werte nicht veraendern!
;=============================================================

N124 G18 M814 ; Arbeitsebene + ???
N125 DIAMON ; Durchmesser Programmierung X
N126 G54 ; NP 1 aktivieren
N127 TOWSTD ; WKZ-Verrechnung bei B1-Achs Schraeglage
N128 T="RENISHAW" ; WKZ Voranwahl
N129 TC(2,0,0,2,R2,0)

N130 L707(0) ; C4-Einschalten
N131 SETMS(4) ; S4=Masterspindel
N132 g90 g0 B1=R2 M1=5 M109 ; B-Achse in Position und Spindel aus

N133 R500=GROOVE[COUNT,0] ; Bauteildurchmesser uebergeben

;NCG#tails75x#gm_eqc75.com#move_ride#*NCG;*RO*;*HD*
;#"Reitstock vor und Abst?zen,ZP=10,F=250"#1#1#241.8#1#2#2#2#3#1#"L?ette"#1#1#1#1#1#"Achtung: Eingabewert zu klein !"#"Bitte Betriebsanleitung beachten!"#0#0#3#0#2#250#600#860.1#*NCG;*RO*;*HD*
N134 TAILSTOK(,,,,4,1,1,10,250,0,0,0,0,30,20,0,0)
;#END#*NCG;*RO*;*HD*

N135 g0 z5 y0 c4=R3 ; Messposition anfahren
N136 g0 x=R500+20 z=5 g94 f1500

N137 g1 x=R500-3

N138 m120 ; Messtaster einschalten

;===============================================
; Stirnflaeche antasten und Position speichern
;===============================================
N139 L770("Z",5,-20,0) ; Messung Z-Achse
N140 R520=R50 ; Stirnmass umspeichern
N141 M121 ; Messtaster ausschalten
N142 g0 x=R500+20 ; vom Bauteil abheben

N143 R520=ROUND(R520*1000)/1000 ; Messergebnis auf 3 Nachkommastellen kuerzen

;==============================================
;= S t e u e r k a n t e n m e s s e n
;==============================================
N144 MESSUNGEN:
N145 R521=GROOVE[COUNT,1] ; Position linke Kante
N146 R522=GROOVE[COUNT,2] ; Position rechte Kante
N147 R523=GROOVE[COUNT,3] ; Radius im Grund
N148 R524=GROOVE[COUNT,4] ; Einstichdurchmesser

;=== Messposition anfahren
N149 TC_BC_POS(2,0,0,2,R2,0) ; C1=0 ohne WKZ-Wechsel
N150 g0 z=(R521+R522)/2
N151 g1 x=R524+R1+1.5+R523

N152 m120 ; Messtaster einschalten
N153 L770("Z",R521+4,R521-5,0) ; Messung linke Flanke
N154 R540=R50 ; Schultermass umspeichern
N155 M121 ; Messtaster ausschalten

N156 R540=ROUND(R540*1000)/1000 ; Messergebnis auf 3 Nachkommastellen kuerzen

;=====gemessene Position verrechnen und schreiben
N157 MESS[COUNT,0]=(((R540)-(R520))+R4)*(-1)


N158 TC_BC_POS(2,0,0,2,R2,180) ; C1=180 ohne WKZ-Wechsel

N159 m120 ; Messtaster einschalten
N160 L770("Z",R522-4,R522+5,0) ; Messung rechte Flanke
N161 R542=R50 ; Schultermass umspeichern
N162 M121 ; Messtaster ausschalten
N163 g0 x=R500+50 ; vom Bauteil abheben

N164 R542=ROUND(R542*1000)/1000 ; Messergebnis auf 3 Nachkommastellen kuerzen

;=====gemessene Position verrechnen und schreiben
N165 MESS[COUNT,1]=(((R542)-(R520)+R1)-R5)*(-1)


N166 COUNT=COUNT+1
N167 if GROOVE[COUNT,0]<>0
N168 gotob MESSUNGEN
N169 endif


Den Reitstock habe ich für den Testzweck und aus Zeitgründen auskommentiert.
TOP    
Beitrag 16.11.2018, 15:25 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Seltsame Erkenntnis: wenn ich in dem Programm alle G0-Eilgangbewegungen mit G1 (und großem Vorschub ähnlich Eilgang) programmiere, läuft es durch (!!!!!!!!!)

Hat irgendjemand eine Erklärung dafür???
TOP    
Beitrag 19.11.2018, 09:33 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Hier mal Screenshots für den Zustand, während dieser Fehler ansteht. Es ist dann keine g0 Bewegung mit der B-Achse mehr möglich. G1 fährt er aber. Hat jemand eine Idee?

Angehängte Datei  IMG_8156.jpg ( 546.9KB ) Anzahl der Downloads: 35


Angehängte Datei  IMG_8157.jpg ( 951.86KB ) Anzahl der Downloads: 22
TOP    
Beitrag 27.11.2018, 15:08 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

Soooooooo! Auflösung!

Ich Hornochse habe versehentlich mit diversen Parametern im R600er Bereich reservierte Maschinenparameter überschrieben, die dann letztendlich zu dem beschrieben Fehler führten. Asche auf mein Haupt!

Ich hoffe, dass der eine oder andere mit diesem Thread was anfangen kann.
TOP    
Beitrag 27.11.2018, 16:02 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922

QUOTE (ingo1974 @ 27.11.2018, 16:08 Uhr) *
Soooooooo! Auflösung!

Ich Hornochse habe versehentlich mit diversen Parametern im R600er Bereich reservierte Maschinenparameter überschrieben, die dann letztendlich zu dem beschrieben Fehler führten. Asche auf mein Haupt!

Ich hoffe, dass der eine oder andere mit diesem Thread was anfangen kann.

Darauf gibt es eine einfache und eindeutige Antwort: Man verwendet keine R-Parameter.
TOP    
Beitrag 27.11.2018, 16:41 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

QUOTE (CNCFr @ 27.11.2018, 15:02 Uhr) *
Darauf gibt es eine einfache und eindeutige Antwort: Man verwendet keine R-Parameter.


Hm? Ich verstehe deine Aussage nicht. Wie meinst du das? Ich habe jetzt für ein Bauteil (verschiedene Variationen) ein Baukasten/Modulares System programmiert. Insgesamt verwende ich ca. 100 Parameter. Komplett flexibel alle Bearbeitungen.

Edit: Oder beziehst du es auf Messprozesse und würdest da ausschließlich zu RG-Parametern raten?

Der Beitrag wurde von ingo1974 bearbeitet: 27.11.2018, 16:51 Uhr
TOP    
Beitrag 27.11.2018, 19:02 Uhr
CNCFr
CNCFr
Level 7 = Community-Professor
*******
Gruppe: Mitglied
Mitglied seit: 15.09.2002
Beiträge: 1.922

Wenn man R-Parameter "reserviert" ist durch nichts gesichert, dass die von niemandem sonst verwendet oder überschreiben werden. Das kann einem anderen Nutzer der Steuerung passieren, weil er von der Reservierung nichts weiß oder auch dem Autor selbst, weil er einfach vergessen hat, dass er da etwas reserviert hat.
Die Fehlersuche in solchen Fällen ist immer mühsam und zeitaufwendig.
Beliebt ist auch, in komplexeren Programmen mit vielen Unterprogrammen Daten zwischen den Programmteilen über R-Parameter auszutauschen, statt - wie es sich gehört - über Unterprogrammparameter. Das ist zwar schnell hingeschrieben, führt aber genauso schnell zu undurchsichtigen Programmen, bei denen man leicht den Überblick verliert.
Dazu kommt natürlich, dass man R-Parametern nicht ansieht, was sie bedeuten sollen. Variablen sollten immer aussagekräftige Namen haben, d.h. man sollte statt R-Paraemter lokal zu verwenden LUDs definieren. Du kennst deine R-Parameter wahrscheinlich im Moment auswendig. Aber lass das Programm mal zwei Jahre liegen und versuche dann zu verstehen, was da abläuft, oder denke an den armen Kollegen, der das irgendwann mal ändern soll.

In Programmen, die keine Daten benötigen, die auch über das Programmende hinaus erhalten bleiben müssen, braucht man grundsätzlich keine R-Parameter.
Wenn man Daten hat, die auch außerhalb des Programmablaufs erhalten bleiben müssen, sollte man besser GUDs verwenden.
Um Daten dieser Art scheint es sich ja bei den von dir sogenannten Maschinendaten ab R600 gehandelt zu haben (wenn es echte Maschinendaten sind, weshalb muss man die dann in R-Parametern duplizieren?).

Die Siemens-Zyklen haben wohl früher - so habe ich mir erzählen lassen - auch R-Parameter-Bereiche für ihre internen Abläufe "reserviert". Das ist aus guten Gründen seit Jahrzehnten nicht mehr der Fall, und dabei werden nur Programmiertechniken verwendet, die auch jedem Anwendungsprogrammierer zur Verfügung stehen.
TOP    
Beitrag 28.11.2018, 12:56 Uhr
ingo1974
ingo1974
Level 2 = Community-Facharbeiter
**
Gruppe: Mitglied
Mitglied seit: 10.11.2013
Beiträge: 116

QUOTE (CNCFr @ 27.11.2018, 18:02 Uhr) *
Wenn man R-Parameter "reserviert" ist durch nichts gesichert, dass die von niemandem sonst verwendet oder überschreiben werden. Das kann einem anderen Nutzer der Steuerung passieren, weil er von der Reservierung nichts weiß oder auch dem Autor selbst, weil er einfach vergessen hat, dass er da etwas reserviert hat.
Die Fehlersuche in solchen Fällen ist immer mühsam und zeitaufwendig.
Beliebt ist auch, in komplexeren Programmen mit vielen Unterprogrammen Daten zwischen den Programmteilen über R-Parameter auszutauschen, statt - wie es sich gehört - über Unterprogrammparameter. Das ist zwar schnell hingeschrieben, führt aber genauso schnell zu undurchsichtigen Programmen, bei denen man leicht den Überblick verliert.
Dazu kommt natürlich, dass man R-Parametern nicht ansieht, was sie bedeuten sollen. Variablen sollten immer aussagekräftige Namen haben, d.h. man sollte statt R-Paraemter lokal zu verwenden LUDs definieren. Du kennst deine R-Parameter wahrscheinlich im Moment auswendig. Aber lass das Programm mal zwei Jahre liegen und versuche dann zu verstehen, was da abläuft, oder denke an den armen Kollegen, der das irgendwann mal ändern soll.

In Programmen, die keine Daten benötigen, die auch über das Programmende hinaus erhalten bleiben müssen, braucht man grundsätzlich keine R-Parameter.
Wenn man Daten hat, die auch außerhalb des Programmablaufs erhalten bleiben müssen, sollte man besser GUDs verwenden.
Um Daten dieser Art scheint es sich ja bei den von dir sogenannten Maschinendaten ab R600 gehandelt zu haben (wenn es echte Maschinendaten sind, weshalb muss man die dann in R-Parametern duplizieren?).

Die Siemens-Zyklen haben wohl früher - so habe ich mir erzählen lassen - auch R-Parameter-Bereiche für ihre internen Abläufe "reserviert". Das ist aus guten Gründen seit Jahrzehnten nicht mehr der Fall, und dabei werden nur Programmiertechniken verwendet, die auch jedem Anwendungsprogrammierer zur Verfügung stehen.


Grundsätzlich gebe ich dir recht. Wenn da mehrere Mitarbeiter am Werke sind, dann kann das heikel werden, weil unerwünschte Effekte auftreten können. Da ich aber alleine an der Maschine arbeite, passt das schon. Zudem dokumentiere ich die wichtigsten DIN/ISO Programme. Nötigenfalls auch mit Skizzen. Zudem ist meistens fast jede wichtige Zeile dokumentiert. Und hinter jedem R-Parameter steht grundsätzlich auch erläutert, worum es sich handelt.

Damit mir aber oben geschildertes Problem künftig nicht mehr passiert werde ich dazu übergehen, während der Programmierung fortlaufend R-Parameter zu vergeben, die ich parallel auf einen Zettel schreibe. So hat man alles im Überblick und verwendet keine R-Parameter mehrfach.

"Globale" Parameter benutze ich auch Programmintern. Im Hauptprogramm werden einige Parameter definiert, die dann in den dazugehörigen Unterprogrammen abgerufen werden. Diese globalen Parameter versuche ich aber mengenmäßig auf ein Minimum zu reduzieren.
TOP    



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