Cicli di tastatura e probing

[safe60]

Buongiorno. Come sviluppatore di postprocessor devo affrontare un nuiovo compito. La prossima revisione del programma per il quale scrivo i post avra' funzioni specifiche per i cicli di tastatura.

Va da se' che bisognera' conoscere molto bene i cicli di tastatura di tutti i controlli (posto che li abbiano) e quindi sto iniziando a leggere chili di documentazione partendo da Heidenhain che, per quanto riguarda il mio lavoro, e' il controllo piu' diffuso. Quello che non mi e' ancora chiaro e che non potro' appurare sul campo visto che non ho accesso pratico a macchine e' questo :
Una volta che il ciclo di tastatura viene eseguito, il controllo generara' un errore in caso di mancato contatto o di contatto al di fuori delle tolleranze impostate.
Alcuni vecchi cicli aggiornano anche delle variabili interne al controllo con il risultato eventualmente rilevato dal ciclo. I cicli moderni invece, pare non aggiornino nessuna variabile del controllo : vanno.. oppure danno errore. Questo sarebbe un bel problema.

C'e' qualcuno che ha esperienza pratica di uso dei cicli di tastatura Heidenhain tipo il ciclo 400 o 427 ? (ma anche tutti gli altri) .

Sandro

[nl2000sy]

Ciao, io utilizzo Heidenhain 530 e sonda Blum sia per azzerare i pezzi che per il controllo delle misure in macchina.
Se serve basta che chiedi, se un ciclo non l'ho mai utilizzato fare una prova non mi costa nulla.
Fabrizio

[safe60]

Intanto, grazie per la disponibilita'. In realta' quello che vorrei conoscere e' il comportamento del ciclo in caso di errori o mancato contatto. Spiego il perche'.
Nel cam potrei definire una lavorazione e, subito dopo, un ciclo di tastatura che veriifchi alcuni punti per controllare se effettivamente il pezzo e' stato lavorato con le tolleranze richieste.

Nel caso il ciclo di tastatura rilevi che si e' fuori tolleranza, il CAM mi consente di scatenare varie azioni di contromisura : ad esempio, rieseguire la procedura di lavorazione magari con un altro utensile piu nuovo , oppure con parametri differenti. Poi ci sono anche altre cose che si potrebbero fare ma limitiamoci a questo.

Ora, e' chiaro che in fase di CAM non e' possibile sapere se il pezzo verra' lavorato entro le tolleranze oppure no. Quindi il post dovra' generare un programma che preveda, nell'esempio citato sopra, di eseguire o meno una certa azione a seconda dell'esito del ciclo di tastatura. Se il ciclo di tastatura rleva che le tolleranze del pezzo sono quelle richiete, prosegue con il resto del lavoro, altrimenti prende le opportune decisioni come, appunto, rieseguire la lavorazione o altro ancora.

Il linguaggio di programmazione di Heidenhain o di altri controlli consente di eseguire o meno salti o richiami di sottoprogrammi. Fin qui e' abbastabza semplice. Il problema consiste nel capire quale tipo di controllo eseguire a valle del ciclo di tastatura.

Dalla manualistica heidenhain si evince che i cicli di tastatura in caso di errore o di rilevamento pezzo fuori dalle tolleranze impostate, danno un messaggio di errore a video. Questo va bene per l'operatore a bordo macchina ma per chi deve scrivere il post non ha alcun valore. Quello che mi serve sapere e' se il ciclo di tastatura imposta delle variabili del controllo con l'esito del ciclo stesso.

Sandro

[nl2000sy]

Io non ce l'ho il CAM quindi non saprei.
Nel ciclo di tastatura si può decidere una tolleranza tramite due parametri e inserire il numero dell'utensile in un terzo parametro. Il TNC provvederà a correggere automaticamente il raggio in tabella utensili, ovviamente si deve lavorare utilizzando la compensazione utensile (RL/RR ) altrimenti non serve a nulla.
Prova a vedere qui http://content.heidenhain.de/doku/tnc_g ... 388-40.pdf a pagina 390 .
Spero di essere stato utile.

[safe60]

Molte grazie per questa informazione. Ho gia' scaricato quel manuale e ora leggero' con calma. Grazie ancora.

[gino]

safe60, mi sa che avrai lavoro a non finire ,
da come capisco vorresti usare i cicli di tastatura per un controllo 3D
in diretta su macchina.
quindi per sicurezza dovresti prima di usare i cicli rifare e controllare sempre
la cinematica macchina sulla sfera di riscontro ,(...e vedere dove viene piazzata, su quale origine).
e poi chi ti da la sicurezza ,se la macchina sta lavorando a temperature ambienti elevate.
anche da noi inseriamo nei programmi tastature automatiche di pezzi precisi.
pero` solo nella presa degli zeri.
il risultato finale e`sempre poi dato dal controllo 3D.
da esperienza posso dire solo che la fresatura finale di finitura deve
andare a fresare solo qualche centesimo (con fresa buona) e caso mai passare per il percorso 2 volte.
..hai esperienza in PP programmation ,
avrei domande da farti,ho rigenerato un PPtable e PProcessor sotto Rhino per 5 Assi
che funziona con macchina professionale.
ma non riesco ancora a configurare la macchina hobbistica privata per percorsi in continuo.
credo che il problema e nel controllo stesso che non mi lascia configurare un asse C ( ma solo A e B)
dove B va da -90 a 90 e A -360 360 (senza possibilita di cambiare nome Asse )

... ma lasciamo perdere..

buon lavoro

[safe60]

Spero proprio che il lavoro non sia infinito invece. Quello che devo fare e scrivere dei post che riproducano fedelmente il percorso utensile che si definisce nel cam. Non essendo un utente finale, tutti i problemi di regolazione della macchina, precisione legata alla temperatura ambiente di officina o condizioni degli utensili non sono collegati al post processor. Capisco che possano essere importanti, questo si, ma si tratta di problemi al di fuori della mia sfera di competenza.

Per quanto riguarda la parte dei problemi che stai incontrando nel post, temo di non essere di grande aiuto. Ogni programma di CAM, ha una sua tecnologia di sviluppo legata a vari aspetti come il linguaggio di programmazione e metodo per eseguire i calcoli. Quello che voglio dire e' che chi e' in grado di scrivere post per il programma di CAM "A" non e' in grado di farlo per il programma di CAM "B" di un altro produttore anche se va detto che probabilmente farebbe meno fatica ad imparare di uno che parta da zero visto che tutto sommato i problemi da risolvere sono gli stessi e cambia solo il modo in cui ciascun programma li gestisce. Il programma per il quale scrivo i post non e' Rhino e quindi non sono in grado di darti delle dritte pratiche.

Detto questo, dal tipo di informazioni che hai dato (il programma generato dal post funziona bene su macchina professionale) azzarderei questo : i controlli professionali nelle lavorazioni a 5 assi in continuo usano comandi di controllo della punta utensile. Questa caratteristica e' indicata da vari acronimi e il piu diffiuso e' RTCP. Si tratta di comandi che una volta attivati rendono la programmazione a 5 assi continui molto piu' semplice. Non entro troppo sul tecnico perche' l'argomento e' molto complesso.

I controlli hobbistici non hanno in genere questi comandi evoluti. Questo significa che deve essere il post processor stesso ad eseguire i calcoli che su macchine professionali sono a carico del controllo. Penso che questa sia una possibile causa dei problemi. E' solo un' ipotesi ovviamente ma trattandosi di lavorazioni 5 assi continui secondo me non siamo molto distanti dalla verita'.