Errori di Feed rate con Colibrì

Sezione dedicata all'elettronica di controllo cnc.
Lonewolf
Newbie
Newbie
Messaggi: 29
Iscritto il: venerdì 19 settembre 2014, 10:41
Località: TORINO

Re: Errori di Feed rate con Colibrì

Messaggio da Lonewolf » martedì 29 settembre 2015, 12:34

Grazie Pedro,
non avevo considerato l'aspetto cinematico che metti in luce dei percorsi circolari (mentre mi è assai chiaro che le variazioni repentine di traiettoria rettilinea siano assimilabili ad archi con curvatura infinita).
Questo dimostra che il confronto è sempre utile, a prescindere dal fatto che esso muti le opinioni di chi vi partecipa.
Però le tue osservazioni mi suscitano altre domande.
Supponiamo che il nostro percorso utensile sia una circonferenza di raggio r e centro nell'origine del piano XY.
La geometria analitica ci insegna che la relazione fra ascisse e ordinate di tutti i punti appartenenti a questa circonferenza è
x²+y²=r²
Dal fondo della mia ruggine emerge anche la reminiscenza che quest'equazione può avere anche una formulazione "parametrica", che, detto t il parametro, è la seguente.
x=r*cos(t) (1)
y=r*sin(t)
Ora, chi si occupa come te di software di controllo, non faticherà ad identificare il parametro t col tempo misurato in impulsi ad una data frequenza.
t[s]=N/f[Hz]
dove N è il numero di impulsi inviati, alla frequenza f, corrispondente al tempo t .
Se deriviamo le (1) rispetto a t otterremo
dx/dt=vX=-r*sin(t) (2)
dy/dt=vY=r*cos(t)
Le (2) rappresentano le velocità istantanee in direzione X e Y che il punto comandato del nostro utensile dovrà possedere per percorrere la traiettoria circolare desiderata.
Immagino queste siano le relazioni fondamentali che impieghi nella scrittura delle istruzioni di pilotaggio assi dei tuoi software.
Cioè, assegnata una legge di variazione della velocità per uno dei due assi, diciamo X, la corrispondente velocità dell'altro (Y) è obbligata ad obbedire alla seconda delle (2), ogni scostamento traducendosi in un errore della traiettoria.
Tu scrivi, correttamente, che, ad ogni cambio quadrante di questa circonferenza, quelli che chiami poli, una delle due velocità si annulla (è intrinseco delle funzioni seno e coseno).
Ma questo accade qualunque sia la frequenza di lavoro minima cui il tuo controller ti consente di scendere.
Che sia 125 o 12.5Hz, vi saranno zone della traiettoria in cui la frequenza necessaria a pilotare uno degli assi sarebbe più bassa del limite tecnico, al limite 0.
Se in quelle zone l'asse "impazzisce" come sembra fare colibrì, con aumento esorbitante della velocità, tu avrai dei movimenti inconsulti ma certo assai lontani dalla traiettoria desiderata.
Ebbene, io ho invece sperimentato che con valori F lontani da quelli che impongono al controller di scendere al suo limite inferiore di frequenza (diciamo F50), l'esecuzione di traiettorie circolari (fori per interpolazione con frese a candela) non sembra meno precisa di quella affidata ad una ortodossa barenatura che non sconta tutti questi problemi, essendo una lavorazione con coordinate XY fisse.
Mi è capitato di ricavare sedi per cuscinetti, notoriamente lavorazioni con tolleranze di diametro e cilindricità piuttosto stringenti, del tutto soddisfacenti ed idonee allo scopo.
Di qui la mia curiosità.
Se come dici tu non c'è verso, per quanto piccoli, ci sono tratti non circolari ai poli del cerchio (e nel caso di colibrì che si imbizzarrisce dovrebbero essere roba da rischiare la fresa) allora come fa il software a pilotare con tanta precisione zone in cui "il controller perde il controllo"?
Può essere che la fase di frenata e accelerazione in prossimità dei poli sia gestita dal software "alla cieca", cioè senza ricercare un impossibile controllo istantaneo, ma in qualche modo programmando l'effetto dell'inerzia (nota) degli assi? Però questa decelerazione "a motore spento" non potrebbe che essere lineare e non sinusoidale come necessario per una circonferenza.
A meno che non si utilizzi il principio del pendolo in cui si assume che per le piccole oscillazioni (<5°) il seno possa approssimarsi col suo argomento e quindi sin(t) quasi uguale t e incrociare le dita, riprendendo successivamente a inviare impulsi con legge sinusoidale in zone della traiettoria in cui la velocità torni compatibile con la frequenza limite inferiore.
Michele

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » martedì 29 settembre 2015, 13:01

Ciao a tutti, quando parlo ,sempre con rispetto, non tolgo che nel fare i calcoli sei più bravo di me, quello che voglio intendere e non per scopi personali,che il Sig.Ribaudo non vende le cose tanto per venderle, è successo che ho fatto richieste per cnc particolari e le risposte sono state no non si può fare con Colibri,cosa che certi fornitori fanno pur di raggiungere fatturato.
Quello che mi sembra strano è che non ti sia stato detto che il tuo asse Z non poteva avere avanzamenti cosi minimi,o in fase di progettazione del retrofit non è stato pensato.

Visto che parliamo di rispetto ,non mi sembra giusto parlare cosi male di un'azienda,visto che un'azienda la gestisco anche io ,gli errori ci possono stare. Tutto qui.

Io capisco la mancata risposta al tuo problema ma ci sarà un motivo.

Posso chiederti il perchè di un passo 10 sulla z?
Poi ho visto che hai nominato il controllo della Delta, ma se dicono che lo vendono solo con le loro cnc come hai fatto ad averlo?

Ciao

Avatar utente
Pedro
God
God
Messaggi: 7084
Iscritto il: domenica 6 aprile 2008, 18:44
Località: Roma

Re: Errori di Feed rate con Colibrì

Messaggio da Pedro » martedì 29 settembre 2015, 13:39

rispondo a Luonewolf: innanzi tutto non possiedo una colibrì ne tanto meno ho mai visto il suo firmware quindi difficilmente posso risponderti nel dettaglio. Però posso dirti che colibrì usa un processore ARM M30833 a 32 bit con capacità di calcolo in floating point, quindi presumo (e solo presumere posso) che il calcolo della traiettoria lo faccia giusto. Quello che desumo, invece, da il dato dichiarato dal costruttore dell'interfaccia che essa possa avere in uscita degli assi una frequenza minima di 150 Hz e una massima di 80KHz è che proprio il rapporto sulla generazione degli impulsi sia limitato, e per questo ipotizzavo un comportamento del tipo: faccio quello che posso (ripeto, alla fine un sistema deve adattarsi). L'esempio che scrissi nel post precedente, dare per un tempo T/2(o frazione di esso ovvio se le divisioni sono diverse da 1/2) gli impulsi minimi possibili e per un tempo corrispettivo (o frazione di esso ovvio se le divisioni sono diverse da 1/2) è una delle soluzioni che si adottano, non è l'unica ovvio. Il processore M30833 non è un fulmine con i suoi 30MHz di clock quindi magari hanno dovuto adattare in qualche modo gli algoritmi come ho ipotizzato. E ripeto (non mi stanco di dirlo perchè è così) sono deduzioni da quello che sappiamo, sapessimo come è fatto il firmware saremo più sicuri di quello che si dice.

PS: tu dici di avere i tuoi driver in modo Step/diro, ovvio perchè non li piloteresti con colibrì, e con il controllo di posizione (quindi doppio encoder sia sul motore che sull'asse). Hai quindi i PID sui driver che sono tarati per "mediare" le piccole variazioni che il controller darebbe al suo cambio di frequenza, nella ipotesi che ho dato io di dividere il tempo T in frazioni. Se T è sufficientemente piccolo penso che il risultato sia ottimo come puoi vedere tu (sto sempre ipotizzando non potand fare prove pratiche e strumentali, sto teorizzando insomma)
"Ho controllato molto approfonditamente," disse il computer, "e questa è sicuramente la risposta. Ad essere sinceri, penso che il problema sia che voi non abbiate mai saputo veramente qual è la domanda."

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » giovedì 1 ottobre 2015, 18:30

Lonewolf ha scritto:A Samevox
Non mi piace il tuo tono.
Non stai parlando al garzone della tua bottega.
La prima condizione per un confronto è il rispetto dell'interlocutore, che non diventa opzionale solo perché si sta nascosti dietro un monitor.
Se ti fossi preso la briga di leggere con attenzione gli interventi precedenti, avresti trovato la risoluzione che impiego, oltre che il mio parere sul rivolgersi al mondo dei costruttori di sistemi CNC professionali.
Tornando alla tecnica, la mia macchina adotta degli azionamenti monofase DELTA ASDA-A2, a ciclo chiuso, dove il controllo di posizione è affidato ai segnali che questi ricevono dalle righe ottiche di bordo, con risoluzione di 1µm, la più alta che conosco, mentre gli encoders rotativi coassiali ai motori brushless della movimentazione assi vengono utilizzati soltanto per verificare la coerenza fra movimenti comandati e movimenti eseguiti.
In altre parole con questa elettronica il controller non pilota direttamente il motore, ma chiede semplicemente all'azionamento "intelligente" di comandare al motore un dato spostamento asse.
E' poi l'azionamento a convertire con la sua elettronica interna la richiesta del controller nel corretto numero di passi da far fare al motore; e controlla continuamente il risultato, confrontando i dati dell'encoder rotativo motore con quelli della riga; generando errori a gestione programmabile nel caso di disallineamenti fra comandi impartiti e spostamenti eseguiti oltre la soglia impostata.
Con l'ottima assistenza DELTA Italia, che fa capo a SIT, proprio nel Bergamasco, resasi necessaria quando Ribaudo mi ha lasciato a piedi a metà della configurazione complessa e nuova anche per lui, abbiamo appurato che la risoluzione da imporre al controller era la stessa delle righe:1µm, cioè 1000step/mm.
Quindi non a libera scelta, come sarebbe possibile su azionamenti B2 a ciclo aperto e decisamente più economici.
Ed indipendente dal rapporto di trasmissione motore-asse.
Tanto è vero che, pur utilizzando sui tre assi tre rapporti diversi
τX=4
τY=5
τZ=10,
la risoluzione impostata su colibrì è sempre la stessa: 1000 step/mm, visto che le righe sono ovviamente tutte uguali.
Guarda caso con una frequenza di 125Hz partono 7500 impulsi al minuto, cui corrisponde, con la predetta risoluzione, la velocità minima che riesco a ottenere negli avanzamenti assi di circa 7.5mm/min, come scritto nel primo messaggio.
Non c'è dubbio che per la maggior parte delle operazioni di fresatura, velocità così basse non siano necessarie.
Ma quando si parla di velocità di tuffo in materiali con resistenza R0>1000 MPa, che nel mio caso riguarda tanto l'asse Z che lo Y, per via della presenza anche di un mandrino orizzontale, torno ad assicurarti che se non vuoi passare le serate a togliere punte spezzate e buttare via pezzi, sarebbe sacrosanto poter disporre di un più opportuno limite inferiore.
E c'è un'altra situazione da considerare.
Colibrì consente, intelligentemente, di programmare una riduzione di velocità negli archi, il cui valore è frutto di un calcolo interno del software dipendente dal raggio di curvatura.
I risultati di questo calcolo non sono esplicitati da nessuna parte.
Può capitare allora che, se quest'opzione è impostata ed il valore di F assegnato alla passata "lineare" è prossimo alla "velocità di stallo", si mandi in tilt il controllo proprio nell'esecuzione dell'arco, in cui l'utensile parte a velocità incontrollata, magari di rapido, con pregiudizio della qualità della lavorazione che può arrivare, in delicate contorniture, fino allo scarto del pezzo.
Non metto in dubbio che tu riesca ad ottenere velocità più basse delle mie, su un controllo a ciclo aperto di tipo B2, o A2 con righe ottiche con risoluzione da spettrometro di massa che io non ho mai visto, ma le formule che esprimono le relazioni fra i vari parametri sono tanto semplici quanto inesorabili.
Siano
F = avanzamento [mm/min]
f = frequenza di lavoro controller = frequenza impulsi al motore [Hz, 1/s]
N0 = Num impulsi per giro motore [impulsi/giro] caratteristica del motore
τ = rapporto di trasmissione motore-vite
p = passo vite di manovra asse [mm]
R = risoluzione controller [step/mm]
Si avrà allora
R = N0* τ/p (1)
F = f*60*p/(N0* τ) (2)
Ricavando N0 dalla (1) e sostituendolo nella (2), fatte le necessarie semplificazioni, si ottiene
F = 60*f/R
relazione fra la velocità di avanzamento ottenuta e la frequenza degli impulsi inviati dal controller.
Ora, per colibrì l'intervallo dichiarato della frequenza di lavoro è 125Hz<f<80000Hz (ma Ribaudo stesso sconsiglia di superare i 40000Hz, perciò teniamo buono questo).
Per esempio, se tu ottieni un movimento alla velocità minima di 2mm/min, significa che la R impostata è almeno 3750step/mm.
Ma con questa risoluzione, che tu puoi scegliere a differenza di me, la corrispondente velocità max (a 40 KHz) sarà 640mm/min: scarsina perfino per la mia vecchia Maho...
Se ho sbagliato qualche passaggio sarò grato a chiunque me lo farà notare civilmente, con le dovute correzioni a margine.
Michele

Ciao,stavo riguardando il risultato del tuo calcolo R,ti posso dire che i miei step in Colibri sono R =400step,mm.
Buona serata

Lonewolf
Newbie
Newbie
Messaggi: 29
Iscritto il: venerdì 19 settembre 2014, 10:41
Località: TORINO

Re: Errori di Feed rate con Colibrì

Messaggio da Lonewolf » lunedì 5 ottobre 2015, 17:27

Tento di rispondere con ordine.
A Samevox.
Sembrerebbe, leggendo la tua risposta, che ad un'azienda, per il solo fatto di essere un'azienda, spetti una sorta di indulgenza o peggio, il diritto a non vedersi elevare contestazioni quando commette degli errori.
Non sono d'accordo.
Penso che tanto le persone, quanto le organizzazioni fatte da persone possano commettere degli errori.
Ciò che ai miei occhi fa la serietà di una persona, o di un'organizzazione, non è l'assoluta mancanza di errori, ma la determinazione a farsene carico quando capitano, anche a costo di rimetterci.
Secondo.
Quando spendo i miei soldi, soldi buoni, per comprare qualcosa, mi arrogo tutto il diritto di giudicare quello che ho comprato, senza timori reverenziali per la "dimensione" del venditore, o per il fatto che a questo, comprensibilmente, non faccia piacere un mio giudizio negativo.
L'unico limite, naturalmente, sancito anche dal codice penale, resta che le mie affermazioni siano veritiere, altrimenti il venditore ha diritto a che nei miei confronti si proceda per il reato di calunnia, o peggio, di diffamazione, quando le false affermazioni vengano fatte pubblicamente.
Quanto al caso specifico, ben ricordo una telefonata col titolare di cui stiamo parlando, durante la messa a punto del mio controllo, nel corso della quale candidamente mi disse di non essere solito spendere così tante ore in assistenza (era la seconda o terza volta che ci sentivamo, operativamente, davanti alla macchina), frase che mi fece molto riflettere su quali potessero essere successivamente le reali cause della chiusura dei contatti. Quest'ultima, ovviamente, è una mia personale deduzione.
Veniamo alle questioni tecniche.
Perché un rapporto di trasmissione così elevato sull'asse verticale?
Quando ho intrapreso la trasformazione di questa fresatrice avevo un limite fondamentale ed invalicabile: la capcità di operare partendo da una sorgente "domestica" di energia elettrica: 3KW monofase.
Questo ha condizionato la scelta di tutta la nuova architettura meccanica.
In estrema sintesi, i motori brushless di movimentazione dei tre assi hanno rispettivamente potenza X 0.75, Y 0.4, Z 0.75 KW.
La coppia erogabile con continuità dai motori X e Z è dichiarata in 2.39Nm.
Stimando prudentemente un carico verticale max di 1000Kg complessivi, aggiungendo i contributi delle forze d'inerzia dovute alle accelerazioni, delle forze d'attrito sulle guide e delle forze di taglio, i calcoli mi dicevano che sull'asse della vite d32 passo 5 rettificata classe ISO 5 con chiocciola precaricata 3+3 giri di sfere, dovevano finirci almeno 14.38 Nm, il che implicava un rapporto di trasmissione complessivo motore vite da circa 6:1.
Impossibile, dati gli spazi disponibili, da realizzare con un solo stadio cinghia pulegge.
A quel punto ho valutato la soluzione mista di interporre fra motore e puleggia motrice un riduttore epicicloidale Wittenstein a gioco ridotto con l'ulteriore vantaggio che fossero i cuscinetti di questo, ben più generosi di quelli del motore, a sopportare il carico radiale della cinghia.
A valle del riduttore una trasmissione convenzionale puleggia-cinghia puleggia con rapporto 1:1.
Wittenstein produce nell'intervallo di mio interesse due rapporti di trasmissione: 7 e 10.
Il 7, a calcolo già idoneo, è un numero che non mi piace: numero primo che nel caso di altri accoppiamenti avrebbe dato luogo a rapporti complessivi "complicati".
E poi la prudenza mi fa sempre tenere in considerazione l'ipotesi che nel calcolo possa aver dimenticato qualcosa.
Non ho grandi esigenze di velocità, data la bassa potenza complessivamente disponibile e l'età della macchina che comunque già dalla nascita prevedeva una velocità max su Z di 1600 mm/min, così ho scelto il rapporto 10 per il riduttore per stare "dalla parte della ragione", perdendo solo 100mm/min di vel max (ora 1500 mm/min).
E meno male, alla luce dei limiti inferiori di velocità: se avessi scelto un rapporto più basso ora avrei una velocità minima ancora più alta (nel caso di controllo aperto, non chiuso, come ho spiegato).
Quanto a Delta, non ho detto che monto il loro controller (ho colibrì) ma i loro azionamenti monofase e i loro motori brushless.
Vendutimi, come tutto il resto, da Ribaudo.
Quanto ai dati di velocità e risoluzione che mi hai fornito relativi alla tua macchina, dal conto non si scappa: se la tua risoluzione è 400step/mm, a 125 Hz, cioè 7500 impulsi al min, la tua velocità minima deve essere 7500[min-1]/400[step/mm]=18.75mm/min.
Se riesci ad andare più piano con questi numeri vuol dire che quel 125Hz non ha il significato che io gli ho dato finora, che però con le mie misurazioni torna perfettamente; oppure che hai qualche altra riduzione di velocità a valle di Colibrì che ti permette di scendere ancora.
E qui, non mi resta che invocare la competenza di Pedro, al quale, con l'occasione chiedo: "scusa l'ignoranza, ma cosa sono i PID"?

Michele

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » lunedì 5 ottobre 2015, 18:00

Ciao,non è di mio interesse entrare nel merito penale,voglio solo far intendere che il Signore di cui stiamo parlando mi ha sempre risolto tanti problemi,mandandomi programmi anche alle ore 23 di sera.E il mio pensiero è che la Delta non fà vendere prodotti a persone "incompetenti".

Ti spiego il mio asse z monta una vite passo 4 con riduzione 1:2 risoluzione azionamento ad 800, siccome io ho provato a svolgere un retrofit su un trapano a colonna con riduttore epicicloidale 1:8, è li che ho notato questo problema, con avanzamenti molto lenti tipo al di sotto dei 20mm minuto,l'asse accellerava. Ed mi è stato spiegato il perchè.

Scusa la mia ignoranza ma più il passo della vite è alto, più la vite spinge meno.

Ciao

Lonewolf
Newbie
Newbie
Messaggi: 29
Iscritto il: venerdì 19 settembre 2014, 10:41
Località: TORINO

Re: Errori di Feed rate con Colibrì

Messaggio da Lonewolf » martedì 6 ottobre 2015, 11:28

Mai dato dell'incompetente a Ribaudo: non mi permetterei mai e anzi penso esattamente il contrario.
I rilievi che ho mosso, me ne darai atto, riguardano altro e a quanto pare formano un'esperienza recentemente comune a varie persone in questo forum.
Mi rallegra sapere che la tua esperienza sia di segno diverso, ma le 300 macchine di cui hai parlato rafforzano la mia opinione che dietro al silenzio ci stia un comprensibile ma poco trasparente calcolo di convenienza.
Vorrei però finire di discutere con te di un terzo convitato assente, dato che lo scopo della mia partecipazione a questo forum è tentare di risolvere problemi rimasti in sospeso.
E' certamente vero, ad un passo inferiore delle viti corrisponde un rapporto di trasmissione più elevato nella traslazione dell'asse corrispondente: a parità di giri motore l'asse viaggia più lentamente ma richiede al motore meno coppia motrice.
Per questo anch'io avevo cercato delle viti con passo 4mm. Senza trovarle con le caratteristiche che servivano a me, visto che quel tipo di produzione sembra ormai essersi standardizzato sul passo 5mm (parlo di viti a ricircolo di sfere, rettificate in classe ISO3 o 5, con profili di gola ad arco gotico, chiocciole precaricate per annullamento del gioco di inversione, e per finire lavorate di testa su misura).
Abbiamo finito per concentrarci sull'asse Z, perché, ho scritto, è quello dove la velocità minima di 8-10mm/min da' più fastidio.
Ma lo stesso comportamento lo riscontro anche sugli altri due assi che non adottano riduttori epicicloidali ma semplici trasmissioni cinghia-puleggia.
Se ho capito bene i dati che riporti, l'asse di cui stai parlando funziona così.
Per un giro del motore occorrono 800 passi.
Ogni due giri motore (1600 passi) la tua vite fa un giro ed il tuo asse trasla di 4 mm.
Torna perfettamente la risoluzione impostata su colibrì di cui avevi parlato in precedenza: 400 step/mm.
Questo comporta, lo ripeto, che, alla frequenza minima di impulsi inviati da colibrì di 7500 al min (125Hz) corrisponde una velocità lineare di 18.75mm/min.
Tu però sostieni che il comportamento del tuo asse è regolare fino a 2mm/min, che vorrebbe dire una frequenza di impulsi da colibrì di 800 al min, cioè 800/60=13.33Hz.
O volevi scrivere 20 e ti è scappato uno 0, oppure non mi trovo più...
Non riesco a fare conti invece sul tuo trapano a colonna, perché il dato del rapporto di trasmissione 8:1 del riduttore utilizzato non basta: occorrono tutti gli altri parametri, dalla risoluzione del motore, ai rapporti di altre eventuali trasmissioni, al passo della vite di manovra, se il pilotaggio è sulla tavola (colonna prismatica), o alle cartteristiche di rocchetto e cremagliera se la discesa era fatta sul canotto mandrino (poi sarei curioso di capire perché hai impiegato una scheda colibrì e tutto quello che si porta dietro per pilotare l'unico asse di un trapano a colonna...).
In ogni caso, vedi da solo che, più è alto il rapporto di trasmissione, più alta dovrà essere (sui controlli "open loop", come evidentemente è il tuo) la risoluzione da impostare su colibrì e, di conseguenza, più bassa (fermi i 125Hz) la velocità minima raggiungibile.
Quindi: alti rapporti di trasmissione favoriscono l'abbassamento della velocità, come è intuitivo.
Saluti.
Michele

Avatar utente
leomonti
Senior
Senior
Messaggi: 2244
Iscritto il: mercoledì 20 dicembre 2006, 19:04

Re: Errori di Feed rate con Colibrì

Messaggio da leomonti » sabato 17 ottobre 2015, 11:18

Piccolo contributo.
Come dicevo - inutilmente a Ribaudo - e a voi qualche messaggio fa, soffro di strani blocchi random, sia in esecuzione di programma che in MDI. E mi pare di essere in buona compagnia.
Le avevo provate tutte - spostare l'inverter furoi dal case dell'elettronica, cambiare PC, riti Woodoo di varia natura - ma niente.
Sembra, dico sembra perchè voglio prima consolidare il risultato, che il problema si risolva molto più banalmente, cambiando cavo USB con un Belkin ben schermato (prima usavo quello mandatomi da Ribaudo insieme alla scheda) e modificando il percorso fisico del medesimo, passando dietro al case, allontanando così il cavo dall'inverter. Se dovessero verificarsi ancora dei blocchi, proverò anche i manicotti di ferrite intorno al cavo USB. Per ora, comunque, sembra che vada.
Il cervello è l'organo più sopravvalutato...(W.Allen)

Avatar utente
Pedro
God
God
Messaggi: 7084
Iscritto il: domenica 6 aprile 2008, 18:44
Località: Roma

Re: Errori di Feed rate con Colibrì

Messaggio da Pedro » sabato 17 ottobre 2015, 11:58

Rispondo a lonewolf anche se in ritardo, ho avuto un po' di problemi questi ultimi giorni :D , sulla domanda riguardo il PID.

L'acronimo PID rappresenta un sistema di retroazione, quindi un anello chiuso, di cui i valori dei coefficienti proporzionale, derivativo ed integrale danno il nome a questo tipo di controllo

https://it.m.wikipedia.org/wiki/Controllo_PID
"Ho controllato molto approfonditamente," disse il computer, "e questa è sicuramente la risposta. Ad essere sinceri, penso che il problema sia che voi non abbiate mai saputo veramente qual è la domanda."

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » sabato 17 ottobre 2015, 12:20

Ciao rispondo a Senior,
ti chiedo usi un computer fisso o un portatile?

Quanti kw gestisce il tuo inverter?

Quando ti succede questo blocco durante l'accensione dell'elettromandrino o durante la lavorazione?

Ciao

Avatar utente
vincenzo4126
Junior
Junior
Messaggi: 79
Iscritto il: sabato 14 dicembre 2013, 16:51
Località: avezzano

Re: Errori di Feed rate con Colibrì

Messaggio da vincenzo4126 » sabato 17 ottobre 2015, 12:25

leomonti ha scritto:Piccolo contributo.
Come dicevo - inutilmente a Ribaudo - e a voi qualche messaggio fa, soffro di strani blocchi random, sia in esecuzione di programma che in MDI. E mi pare di essere in buona compagnia.
Le avevo provate tutte - spostare l'inverter furoi dal case dell'elettronica, cambiare PC, riti Woodoo di varia natura - ma niente.
Sembra, dico sembra perchè voglio prima consolidare il risultato, che il problema si risolva molto più banalmente, cambiando cavo USB con un Belkin ben schermato (prima usavo quello mandatomi da Ribaudo insieme alla scheda) e modificando il percorso fisico del medesimo, passando dietro al case, allontanando così il cavo dall'inverter. Se dovessero verificarsi ancora dei blocchi, proverò anche i manicotti di ferrite intorno al cavo USB. Per ora, comunque, sembra che vada.
confermo che anche io ho avuto il tuo problema con il cavo ubs in dotazione, ma che con un portatile andava tutto liscio: mai avuti blocchi, invece con pc fisso ogni tanto capitava.
risolto sostituendo il cavo con uno ben schermato e piu corto (circa un 1,3 metri)

vorrei però aggiungere un altra cosa: prima avevo il contatto di accensione dell'inverter collegato direttamente sulla colibri e al momento dell'accensione appunto, capitavano dei rallentamenti soprattutto nella parte grafica del software che poi svanivano con il raggiungimento della rotazione di regime.
ora ho installato un relè e quindi separato l'inverter dalla colibri: tutto va molto meglio.
quindi credo che anche i contatti dell'accenzione possano interferire con il buon funzionamento della colibri.
voi che ne dite?
Ultima modifica di vincenzo4126 il sabato 17 ottobre 2015, 12:29, modificato 1 volta in totale.

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » sabato 17 ottobre 2015, 12:28

Ciao ,bene e questo succede perchè c'è un Loop di terra.

Avatar utente
leomonti
Senior
Senior
Messaggi: 2244
Iscritto il: mercoledì 20 dicembre 2006, 19:04

Re: Errori di Feed rate con Colibrì

Messaggio da leomonti » sabato 17 ottobre 2015, 14:22

Cerco di rispondere in ordine:

- il blocco è random. Talvolta ad accensione del sistema il programma non vede il controller. Altre volte si blocca durante l'esecuzione della lavorazione. Altre ancora accendendo e spegnendo il mandrino.
- Inverter Toshiba VF-S15 1,Kw
- Avvio inverter e regime di rotazione comandati da Colibri, ma lo start/stop, passano da un relè.
- Ho utilizzato sia un fisso che un portatile. Sul fisso era drammatico. Probabilmente una MB scarsa con una pessima gestione dell'USB.
- Le masse credo siano collegate correttamente, sempre da un solo lato ma, in un cablaggio molto complesso qualche errore potrebbe anche starci.

Comunque, come dicevo sopra, la sostituzione del cavo ed il diverso persorso, hanno dato una svolta decisiva (sto usando il portatile). Speriamo duri, è troppo presto per avere un dato certo.
Il cervello è l'organo più sopravvalutato...(W.Allen)

gino
Senior
Senior
Messaggi: 1774
Iscritto il: domenica 11 ottobre 2009, 18:12

Re: Errori di Feed rate con Colibrì

Messaggio da gino » sabato 17 ottobre 2015, 14:54

uso anchio il Colibri , con un Inverter da 2,2 Kw toschiba vf-s11
ma di questi problemi non ne ho avuti ,
nessun blocco ,o riconoscimento Controller.
..unica cosa con il potenziometro non riesco ad azzerare completamente l`avanzamento.
e` quasi a Zero ma si muove un po.(girando la manopola a 0 dovrebbe fermare completamente)
se avesse anche il codice G68 (rotazione coordinate ) sarebbe il controller perfetto !

samevox
Junior
Junior
Messaggi: 89
Iscritto il: martedì 4 settembre 2012, 19:22
Località: bergamo
Contatta:

Re: Errori di Feed rate con Colibrì

Messaggio da samevox » sabato 17 ottobre 2015, 17:01

Ciao,non penso allora che sia l'inverter,perchè ho fatto anche io un quadro elettrico per uan fresa che ho costruito per un'amico e il tutto era nel quadro elettrico l'inverter Toshiba da un 1kw e usando il cavo in dotazione con colibri. Nessun problema anche con lavori lunghissimi.

Mi viene spontaneo chiederti del rele su Toshiba?

Come già scritto ho costruito due plasma con generatori da 200 A in alta frequenza, con il filo del contatto homico per la tastatura collegato alla punta della torcia dove all'innesco per qualche millisecondo si arriva a 5000 volt, ho un rele ultraisolato tra torcia e Colibri e non ho riscontrato questo tipo di problema,anche avendo il generatore vicino al quadro elettrico.Per far capire che non penso che il cavo vicino all'inverter dia questo problema. Il cavo usb della mia taglio plasma si appoggia propio sopra al generatore,e sopra al generatore ho il pc e nessun problema.

L'unico problema che ho riscontrato, ho collaudato una cnc con Pc portatile ed era tutto ok,dal momento che ho collegato il pc fisso sono sorti dei problemi,del tipo che alcuni ingressi restavano attivi,ma risolto perchè qualcuno mi ha specificato che avevo un Loop di terra,cmq facile da trovare.


Vorrei chiedere perchè si scrive che è difficile fare un quadro elettrico e i collegamenti di una cnc?

Rispondi

Torna a “Elettronica CNC”