Perchè le parametriche sono importanti?

[claugo]

Torn: ma non volevo mica fare una gara

No, nessuna gara. Io volevo solo parlare del fatto di quanto sia importante imparare a programmare in parametriche(variabili) perchè spesso questo ci porta a risolvere importanti condizioni di lavoro. Se ti va e se hai tempo, prova a trasformarlo in Fanuc e vedrai la semplicità con cui si effettua questa operazione. Anche in heidenhain o altro controllo che non sia solo un posizionatore. Tra l'altro l'heidenhain rilascia un software per pc della sua consolle totalmente gratis fino a 100 righe di istruzioni, con grafica 3d. E' molto carino per chi volesse esercitarsi con questo controllo.

[torn24]

Allora il programma l'idea era buona, la abilitazione utensili o salto lavorazione funziona, era sbagliato il calcolo delle espressioni per calcolare la posizione dei fori. Ora modificato e provato SEMBRA che funzioni, Uso L per ripetere al posto di K, stile mitsubishi del simulatore.
Programma con espressioni modificate, testato

Codice: Seleziona tutto

%
O1000
(Programma pezzo reticolo fori)
#100=30 (distanza fori in X)
#101=50  (distanza righe in Y)
#102=8 (numero fori riga)
#103=5 (numero righe)
#104=4 (pozSizione primo foro riga)
#105=3  (riga di partenza)
#106=1 (abilita centrinatura 1 o 0)
#107=1 (abilita foratura)
#108=0  (abilita maschiatura)
#110=1 (Contatore)
#111=0 (variabile appoggio)
N1 IF[#106EQ0]GOTO10
T1M6 (Punta da centro)
S1000M3G54
G0 X[#100*#104 - #100]  Y[[#105-1]*#101] 
G43 H1 Z100
#111=#104
WHILE[[#110+#105-1]LE#103]DO1 (RIPETE NUMERO RIGHE)
G90 G99 G81 Z-2 R2 F300 ( Primo foro della riga)
G91 X#100 L[#102-#111] ( Restanti fori della riga)
G90G80
G90 G0 X0 Y[[#101*#110]+[#105-1]*#101] (Posizionamento primo foro riga successiva)
#110=[#110+1]

#111=1
END1                                    

N10 IF[#107EQ0]GOTO20
#110=1
T2M6 (Punta elicoidale)
S1000M3G54
G0 X[#100*#104 - #100]  Y[[#105-1]*#101] 
G43 H2 Z100
#111=#104
WHILE[[#110+#105-1]LE#103]DO1 (RIPETE NUMERO RIGHE)
G90 G99 G81 Z-2 R2 F300 ( Primo foro della riga)
G91 X#100 L[#102-#111] ( Restanti fori della riga)
G90G80
G90 G0 X0 Y[[#101*#110]+[#105-1]*#101] (Posizionamento primo foro riga successiva)
#110=[#110+1]

#111=1
END1                  

                      
N20 IF[#108EQ0]GOTO30
#110=1
T3M6 (Punta elicoidale)
S1000M3G54
G0 X[#100*#104 - #100] Y[[#105]*#101] 
G43 H3 Z100
#111=#104
WHILE[[#110+#105-1]LE#103]DO1 (RIPETE NUMERO RIGHE)
G95
G90 G99 G84 Z-2 R2 F300 ( Primo foro della riga)
G91 X#100 L[#102-#111] ( Restanti fori della riga)
G90G80
G90 G0 X0 Y[[#101*#110]+[#105-1]*#101] (Posizionamento primo foro riga successiva)
#110=[#110+1]

#111=1
END1  
G94                

G91 G28 Z0
G90
N30 M30
%

I punti sono i posizionamenti, il punto in alto al reticolo non è un foro è il posizionamento finale.

[Vomisa]

Sera a tutti,

vorrei proporre la mia soluzione:

Codice: Seleziona tutto

(DATI FORATURA)
(verso Y+, 2 colonne da 26 fori passo mm17, distanziate mm25)
(verso X+, 33 righe passo mm50, staffe dopo 1,17,32 righe)

(X0, Y0 coordinate primo foro basso a sx, Z0 superfice pezzo)

#102=0 (NumeroForoPartenza-1, programmato in MDI volendo)
(Aggiungere 10000 per foratura, aggiungere 20000 per maschiatura)

(APPOGGIO:)
(#103,#104 COORDINATE X E Y DEL FORO)
(#101 LAVORAZIONE DA FARE)

(SUBPROGRAMS BEGIN HERE)

O1000 SUB (CENTRINATURA)
G00 Z2
G01 Z-6
G00 Z2
O1000 ENDSUB

O2000 SUB (FORATURA)
G00 Z2
G01 Z-30
G00 Z2
O2000 ENDSUB

O3000 SUB (MASCHIATURA)
G00 Z5
G01 Z-33 M3
M5
G01 Z5 M4
O3000 ENDSUB

O5000 SUB (CALCOLI POSIZIONE X E Y FORO)
#83=FIX[#102/52] (QUALE COLONNA)
#84=#102-[#83*52] (QUALE RIGA)
#103=#83*50
#104=#84*17
O5000 IF [#104 GT 425] ("RIALZO" COLONNA)
 #104=#104+25 
O5000 ENDIF
O5000 ENDSUB

O1100 SUB (CICLO)
O1100 WHILE [#102 LT 1716]
O5000 CALL (CALCOLO POSIZIONE FORO)
O1010 IF [#104 EQ 0] (SALTI STAFFA)
O1101 IF [#103 EQ 50]
G00 Z50
O1101 ENDIF
O1101 IF [#103 EQ 900]
G00 Z50
O1101 ENDIF
O1101 IF [#103 EQ 1600]
G00 Z50
O1101 ENDIF
O1010 ENDIF
G00 X#103 Y#104

O1011 IF [#101 EQ 0]
O1000 CALL 
O1011 ENDIF

O1012 IF [#101 EQ 1]
O2000 CALL
O1012 ENDIF

O1013 IF [#101 EQ 2]
O3000 CALL 
O1013 ENDIF

#102=#102+1
O1100 ENDWHILE
O1100 ENDSUB

(END SUBPROGRAMS)

(************** PROGRAM START ***********)

G54
O100 IF [[#102-10000] LT 0]
#101=0
G00 Z200 M5
T1 M06 (PUNTA CENTRI 16 MM)
S900 F120
G00 X0 Y0 Z50
M3
O1100 CALL
#102=10000
O100 ENDIF
 
O101 IF [[#102-20000] LT 10000]
#101=1
#102=#102-10000
G00 Z200 M5
T2 M06 (PUNTA METALLO DURO 10.3 MM)
S1250 F180
G00 X0 Y0 Z50
M3
O1100 CALL
#102=20000
O101 ENDIF

O102 IF [[#102-30000] LT 20000]
#101=2
#102=#102-20000+1 (NON SI RIMASCHIA IL FORO DI FERMO)
G00 Z200 M5
T3 M06 (MASCHIO M12)
S750 F210
G00 X0 Y0 Z50
M3
O1100 CALL
#102=0
O102 ENDIF

G00 Z200 M5
M30 (FINE PROGRAMMA)

(************** PROGRAM END **************)

Il codice e' scritto per CAMotics ( https://camotics.org/ ) e dovrebbe essere compatibile con LinuxCNC.
Credo sia abbastanza chiaro, anche se non ho mai capito l' abuso del codice O# da parte di questo parser.
La cosa credo sia piu' interessante e' la possibilita' di commentare #102, inserirlo in MDI o schermata parametri e ripartire da dove voglio. Oppure dopo il reset per qualsiasi motivo, ricalcolarlo in base a #102 e #101, la macchina ripartira' da dove si era fermata.

<Vomisa>,(*** post end ***)

[torn24]

Se funziona va bene
In linea generale e non per questi esempi del thread...
Anche in informatica programmazione, si parla di implementazione, cioè realizzazione del programma che rispetti le richieste, ma è bene sapere che non esiste un unica implementazione possibile, esiste una più efficiente o meno efficiente, ma se l'implementazione rispetta "fa" quello che viene richiesto è giusta.
Più efficiente potrebbe essere, impiega meno tempo, oppure usa meno memoria ecc...
Ma se l'implementazione del programma fa tutto quello che richiesto non si può dire sbagliata

[hellfire39]

Non sono molto d'accordo.
Se l'implementazione fa schifo e ci sono soluzioni più semplici ed efficienti allora non possono certo dirsi giuste.
Funzionanti magari si, ma giuste no.

Di solito, quando un programmatore parte per la tangente con soluzioni inutilmente complicate, questo significa che non è un buon programmatore. Che manca di esperienza o non ha basi sufficienti oppure, più semplicemente, non è adatto a fare il programmatore.

Ultimamente mi è capitato di dover mettere mani su un banco che è stato implementato da uno di questi cani da tastiera. Per calcolare dei semplici offset aveva usato millemila parametri, a volte con segni discordanti e ci sono voluti secoli per ricostruire cosa voleva fare (ed era solo la punta dell'iceberg, tralascio pietosamente altri aspetti ancora più critici del programma).
Si tratta di uno di quei casi che funzionano, ma poi è difficilissimo metterci le mani per qualsiasi modifica.

[torn24]

Non mi sembra solo la mia opinione, molti informatici dicono che ci possono essere diverse implementazioni, se fatte in modo diverso potrebbero avere differenza di efficienza, ma non credo che si possa definire sbagliato, oppure è sbagliato usare il bubble sort solo perché impiega più tempo, fatto meglio perché risparmi 20 byte, ma sbagliato se non lo fai.
Diciamo cosi per essere corretti, è sbagliato se tutti gli informatici direbbero che è sbagliato, se ci sono opinioni diverse no
Tenendo presente che lavoriamo su cnc, per cui è un ambito da non programmatori professionisti. Di solito un programmatore che non trova impiego si reinventa sviluppatore web, ma non ho mai visto lavorare su un CNC per professione

[claugo]

Ellfire: Di solito, quando un programmatore parte per la tangente con soluzioni inutilmente complicate, questo significa che non è un buon programmatore

Molte volte mi hanno mosso la critica di complicare la programmazione a fronte di una programmazione più semplice. E proprio nel caso di questa foratura mi è stato contestato da un operatore che con il cam tutto sarebbe stato molto più semplice, almeno per lui. Alla mia domanda come sarebbe stato molto più semplice ha risposto che bastava mettere un richiamo all'inizio del programma di cosa volevi eseguire, centrinatura, foratura, maschiatura, e nel caso di partenza da un determinato foro o una determinata riga, copiavi il programma, cancellavi le forature che non ti servivano e lanciavi il programma normalmente. alla fine riprendevi il programma originale. Certo che funziona ma... se si parlasse di una decina di fori, tutto ok, un centinaio di fori, anche anche, oltre diventerebbe pesante. Considerando anche che i fori devono essere separati nelle varie operazioni e questo perchè la partenza da un determinato foro non deve essere obbligatoria per tutte le operazione.

Un programmatore deve tenere conto di alcune considerazioni importanti, sia che programmi solo per se stesso e per la propria macchina o che programmi anche per altri e macchine diverse, nonostante queste montino lo stesso controllo.
Queste considerazioni sono... Adattabilità, Versatilità.

Torn: Ma se l'implementazione del programma fa tutto quello che richiesto non si può dire sbagliata

Più o meno è così se alla fine svolge il suo lavoro, bisogna poi vedere se nel caso di un cambiamento questo programma con poco si adatta o deve essere riscritto da capo

[hellfire39]

@torn24
non so che "informatici" frequenti, ma, tra gli informatici seri, la regola KISS (keep it simple) è sacra.
Ecco tu fai riferimento ad un algoritmo di sorting: finché sviluppi cavolate può andare bene. Ma quando l'efficienza è un obbligo, perché un programma inefficiente sarebbe qualche ordine di grandezza più lento, la differenza tra un programmatore bravo ed uno scarso diventa lampante.
Non per nulla è pieno di SW che fa schifo...

@claugo
la complicazione fine a se stessa, per me è il male assoluto. Si complica quando serve, se serve e se non c'è un modo più elegante e semplice di fare la stessa cosa.
Un esempio, nella programmazione plc sono le funzioni turbonucleari che vogliono gestire, con un unico codice, millemila configurazioni differenti, quando sarebbe molto più semplice avere più funzioni atomiche specializzate (più semplici e più leggibili).
Un altro esempio nella programmazione ad oggetti: il volersi incaponire nel mettere per forza classi astratte quando hai un'unica implementazione concreta (e non prevedi di averne in futuro). Molto meglio evitarla e, nel caso, inserirla in futuro con un minimo di refactoring.

[torn24]

Vero in cose importanti deve essere fatto tutto in modo efficiente, ma le cose meno importanti non sono tutte cavolate, una lavatrice non è a mio avviso una cavolata, un cancello automatico non è una cavolata, però se il programma rispetta le richieste e rispetta la sicurezza delle persone, per me in questi casi va sempre bene! Ossia un esecuzione più lenta di 500 millisecondi causa un pericolo alle persone è inaccettabile, scarica l'acqua della lavatrice con 500 millisecondi di ritardo, scusa ma chi se ne frega

[hellfire39]

Appunto: si deve sempre considerare il contesto.
Ma di solito non sono i 500ms di ritardo che dici tu. Le complicazioni sono altrove.

Per altro, parlando proprio di lavatrici, non penso che il codice dei micro che le controllano sia scritto a cavolo di cane. Penso, al contrario, che sia complesso e articolato e per poter entrare nel micro, non contenga troppe "inefficienze".

[claugo]

Hellifire: la complicazione fine a se stessa, per me è il male assoluto. Si complica quando serve, se serve e se non c'è un modo più elegante e semplice di fare la stessa cosa.

Questo diventa soggettivo all'individuo che compie l'azione. Se io trasmetto un programma a un altro individuo, questo non deve capirlo, a meno chè non voglia imparare qualcosa, deve utilizzarlo con una certa facilità nell'ambito per cui è stato creato. Il problema diventa se questo programma deve essere modificato perchè è avvenuto un cambiamento significativo che lo induce a rielaborare alcuni parametri. In questo caso il programmatore deve essere in grado di modificare il programma senza riscriverlo nuovamente.

[hellfire39]

Difficile che un programma nasca immutabile.

Un programma ben fatto e leggibile è modificabile più facilmente ed è meno probabile introdurre bachi. A mio avviso bisognerebbe sempre lavorare in questa ottica.

[claugo]

Mettiamola così

O tu, in base alla tua esperienza in campo materiale e alla tua capacità di programmare, crei un programma che affronti la maggior parte delle probaili modifiche che ti si presenteranno, oppure aspetti le eventuali modifiche e crei un semplice programma ad hoc solo in base alla modifica.

Agli albori dei primi CNC la seconda regola era la norma e ci si ritrovava con hard-disk pieni di programmi che a un certo punto non ti ricordavi neanche che cosa facevano. Questo fino al punto che qualcuno ha pensato bene di usare delle variabili e tenere pochi programmi che coprissero la stragrande maggioranza delle modifiche al pezzo.

Credo che questa sia solo una evoluzione del modo di affrontare il proprio lavoro e non un voler complicare ciò che può essere semplice

[hellfire39]

Si tratta di una "evoluzione"che è sbagliata nella maggioranza dei casi.
Non sono un operatore di macchine cnc e non mi esprimo sulla tua specifica esperienza.

Ma che si tratti di programmazione robot, programmazione ad oggetti, programmazione micro, ecc., la regola aurea è sempre il "keep it simple". Un programma = una funzione.

[blackmttr]

Ogni soluzione è poi in funzione del problema e del sistema di lavoro, quindi non vi è una regola che vada bene per tutto.

Di recente mi sono occupato di integrazione I4.0 in alcune aziende.
Tutte queste non programmavano nulla su CNC che sono mere esecutrici di programmi (commesse) che arrivano dall'ufficio.

L'operatore ha solo da scegliere la commessa da mettere in lavorazione,
caricare il pezzo o verificare lo stato caricatore e dare START, verificare eventuali rotture utensili, pulizia da truccioli,
segnalazione e scarico dei pezzi di scarto, etc.

I file sono già preparati tutti a CAD/CAM in ufficio ed inseriti nel sistema per essere spediti alle varie macchine.
Di solito una sola persona si destreggia e fa tutti i lavori necessari per l'intera produzione.

Nel contesto di I4.0, sempre più in uso, la programmazione a bordo macchina diventa veramente un'attività marginale.