Sincronizzazione assi elettrici Gantry

[Axis23]

Buongiorno,

 

sto progettando la meccanica di un sistema a portale in cui ho un asse X dotato di 2 servomotori + rispettive viti ricircolo, uno per lato, come su alcune frese a pantografo.

 

La struttura non è sufficientemente rigida da poter tollerare un eventuale mancanza di sincronismo tra i 2 servomotori che comporterebbe dei danni meccanici irreversibili.

 

Quello che volevo capire è come e se è possibile garantire "elettronicamente" che questa condizione di sincronismo venga rispettata in ogni condizione.

 

Chiaramente capisco che in condizioni di normale funzionamento sarà compito del motion controller mantenere la sincronia tra i due "assi elettrici" ma volevo capire cosa succederebbe in caso anomalie di vario genere come guasti, allarmi, frenate di emergenza e quant'altro tali da poter innescare un eventuale disallineamento dei due motori.

 

Ho parlato con il fornitore ma onestamente non ne ho ricavato una risposta concreta ed esaustiva quanto piuttosto una cosa del tipo "vediamo poi con la macchina in opera" che ritengo inaccettabile perchè se dovessero risultare problemi irrisolvibili comporterebbe la riprogettazione completa.

 

Vi ringrazio anticipatamente.

 

Saluti

 

 

 

 

 

 

[Axis23]

Aggiungo quanto credo di aver capito e i dubbi che ho allo stato attuale, probabilmente la risposta è legata a qualche cosa che ho capito male:

 

1) I 2 servomotori saranno definiti come 2 "assi elettrici" facenti parte di uno stesso "asse meccanico" e questo sarà impostato nel software.

 

2) Eventuali allarmi o anomalie del servo 1 possono essere comunicati dal suo driver al motion controller tramite Bus, il controller provvederà di conseguenza mandando in allarme anche il servomotore 2: in questo caso ritardo se non ho capito male è quantificabile in circa 80/100ms....più che sufficienti a disallineare il tutto specialmente a certe velocità (mi sembra un tempo molto alto, è possibile?)

 

3) In riferimento al punto sopra, se và in allarme il Master mi manda in allarme lo Slave, invece non succede nel caso opposto (anche questo mi sembra assurdo, ho capito male?)

 

3) Attualmente sono previsti 2 servomotori con driver indipendenti, avrei dei vantaggi usando un driver doppio al posto dei 2 singoli ? (forse sono fatti appositamente per questo scopo ma io non lo sò...i manuali non entrano in merito di questa specifica problematica)

 

4) Si è parlato anche dell'ipotesi di utilizzare 1 solo asse elettrico a software e sdoppiare poi l'uscita analogica del primo driver verso il secondo driver (singoli fili cablati) ma mi sembra una cosa posticcia che probabilmente garantisce simultaneità di intervento ma non capisco come possa garantire il sincronismo

 

5) Cercando di scervellarmi nella mia ignoranza ho ipotizzato il collegamento incrociato degli I/O programmabili presenti sui 2 driver, avrà senso?

 

 

 

[Ctec]

1) Corretto

2) Dipende dal bus usato. In Ethercat la risposta è di pochi ms. Poi generalmente il motion controller analizza le posizioni dei due assi e se lo scostamento è eccessivo, blocca tutto.

3) No, il fatto che uno sia master e l'altro slave dipende dal fatto che uno (slave) segue l'altro (master) come posizione. Gli allarmi sono collettati separatamente e gestiti tutti.

4) Analogica? Allora non c'è un bus di campo? Allora cambia tutto. Va progettato bene il sistema.

5) dipende molto dal sistema. Se c'è il bus di campo, non serve. Se non c'è, potrebbe essere interessante.

 

Andiamo nello specifico: che servosistemi sono? Come sono connessi? Chi riporta la posizione dell'asse?

[Axis23]

1 ora fa, Ctec ha scritto:

1) Corretto

2) Dipende dal bus usato. In Ethercat la risposta è di pochi ms. Poi generalmente il motion controller analizza le posizioni dei due assi e se lo scostamento è eccessivo, blocca tutto.

3) No, il fatto che uno sia master e l'altro slave dipende dal fatto che uno (slave) segue l'altro (master) come posizione. Gli allarmi sono collettati separatamente e gestiti tutti.

4) Analogica? Allora non c'è un bus di campo? Allora cambia tutto. Va progettato bene il sistema.

5) dipende molto dal sistema. Se c'è il bus di campo, non serve. Se non c'è, potrebbe essere interessante.

 

Andiamo nello specifico: che servosistemi sono? Come sono connessi? Chi riporta la posizione dell'asse?

Grazie della risposta!

 

I servomotori sono YASKAWA-SGD7A-08D (400V - 750W) con servopack SGD7S-3R5-D e il tutto gira su Mechatrolink-III nella versione con RJ-45

Il collegamento è a cascata "entra-esci" (ci sono 17 azionamenti) partendo ovviamente dal controller MP3300iec.

Sul "chi riporta la posizione dell'asse" mi verrebbe da dire "l'encoder" ...ma probabilmente non ho capito la domanda, in ogni caso specifico che non sono previsti encoder lineari aggiuntivi sull'asse.

 

P.S. L'Ipotetico servopack doppio utilizzabile è il SGD7W-2R6D che à 2x750W del quale però come dicevo non conosco e non trovo gli eventuali vantaggi/svantaggi rispetto alla versione singola.

 

 

[Ctec]

Eh, mi spiace, non ho mai usato la Mechatrolink, non so quindi i tempi di risposta. Bisognerebbe sapere il tempo di ciclo del controller e del bus. Bisogna sentire qualcuno che sa nello specifico. Comunque, impiegherà come layer fisico una ethernet almeno da 100M, quindi molto veloce.

Quindi, capisco che la posizione è ripresa dall'encoder del servomotore, non tramite un ulteriore encoder. Bene, mi è venuto in mente che se esiste potrebbe essere usato un rilevatore di sfasamento tra encoder (nel tuo caso le uscite encoder simulato dei servo), tipo quelli di sicurezza che servono a rilevare alberi fermi. Ripeto, non so se ci sono.

 

Per esperienza personale, con assi elettrici in bus di campo si ha un sincronismo perfetto anche in allarme o emergenza. A parer mio siamo nel campo delle frazioni di grado, che riportato allo spostamento lineare siamo nelle frazioni di millimetro.

 

I driver doppi fanno risparmiare posto, un po' sull'alimentazione e soprattutto recuperano l'energia di un asse per alimentare l'altro. Ma come allarmi sono gestiti singolarmente.

[Axis23]

1 ora fa, Ctec ha scritto:

Eh, mi spiace, non ho mai usato la Mechatrolink, non so quindi i tempi di risposta. Bisognerebbe sapere il tempo di ciclo del controller e del bus. Bisogna sentire qualcuno che sa nello specifico. Comunque, impiegherà come layer fisico una ethernet almeno da 100M, quindi molto veloce.

Quindi, capisco che la posizione è ripresa dall'encoder del servomotore, non tramite un ulteriore encoder. Bene, mi è venuto in mente che se esiste potrebbe essere usato un rilevatore di sfasamento tra encoder (nel tuo caso le uscite encoder simulato dei servo), tipo quelli di sicurezza che servono a rilevare alberi fermi. Ripeto, non so se ci sono.

 

Per esperienza personale, con assi elettrici in bus di campo si ha un sincronismo perfetto anche in allarme o emergenza. A parer mio siamo nel campo delle frazioni di grado, che riportato allo spostamento lineare siamo nelle frazioni di millimetro.

 

I driver doppi fanno risparmiare posto, un po' sull'alimentazione e soprattutto recuperano l'energia di un asse per alimentare l'altro. Ma come allarmi sono gestiti singolarmente.

Grazie, 

si confermo che la velocità è di 100Mbps, ma non sò appunto dove possa essere l'eventuale collo di bottiglia.

 

E' interessante questa cosa del sincronismo perfetto anche in caso di allarme/emergenza, se funziona in questo modo anche su questi prodotti direi che potrebbe risolvere il problema.

 

 

[Ctec]

In bus di campo deterministici (a tempo di risposta definito e breve...) tipo l'Ethercat o il Profinet, hai la certezza che i messaggi arrivino nei tempi stabiliti, e si parla di roba sotto il millisecondo. Anche con altri sistemi meno diffusi (da noi) come il SSCNET o CClink TSN (Mitsubishi) si hanno stesse prestazioni. Tutte le sopra le ho usate, ma per esempio la Mechatrolink no, mi spiace.

[Axis23]

2 ore fa, Ctec ha scritto:

In bus di campo deterministici (a tempo di risposta definito e breve...) tipo l'Ethercat o il Profinet, hai la certezza che i messaggi arrivino nei tempi stabiliti, e si parla di roba sotto il millisecondo. Anche con altri sistemi meno diffusi (da noi) come il SSCNET o CClink TSN (Mitsubishi) si hanno stesse prestazioni. Tutte le sopra le ho usate, ma per esempio la Mechatrolink no, mi spiace.

 

A riguardo avevo trovato questa comparativa, se può interessare:

 

https://www.ethercat.org/forms/taiwan2016/download/02_EtherCAT_vs_Modbus_vs_Mechatrolink_1609.pdf

 

Se ho capito bene è leggermente più "lento" dell'EtherCAT ma mi sembra che siamo più o meno nello stesso range quindi, se è vero che in caso di guasto/allarmi con Ethercat il problema di cui sopra in sostanza non si pone mai e poi mai e dipende unicamente dai tempi indicati (microsecondi) senza che ci sian altri fattori/ritardi in gioco allora direi che si potrebbe andar tranquilli.

Modificato: 21 gennaio 2022 da Axis23

[Ctec]

Uhm.... Se considero le limitazioni (pag. 10), le performance (pag. 12), probabilità errori/pacchetti persi (pag. 14) e le performance generali (pag. 25), con 17 servo da servire, personalmente passerei direttamente a Ethercat. Capisco il costo, ma mi pare che ci siano anche problemi tecnologici da non sottovalutare.

[lelos]

Il 21/1/2022 alle 15:40 , Ctec ha scritto:

Anche con altri sistemi meno diffusi (da noi) come il SSCNET o CClink TSN (Mitsubishi) si hanno stesse prestazioni.

assolutamente prestazioni superiore a 'Ethercat o il Profinet. un bus proprietario è sempre più veloce perché cucito su misura.

ho usato molto in passato mechatrolink II (connettori simile a usb) ed era già superiore a profinet., 

ho trovato in internet che maggiore è la quantità di byte che di scambia il master con gli slave in Ethercat  più aumenta il tempo di ciclo della rete.

ora..non ricordo con precisone perché l'ho usato solo una volta anni fa,mi sembra di ricordare che più dati scambiavo più il tempo di ciclo aumentava.

 

[Axis23]

Il 23/1/2022 alle 19:54 , lelos ha scritto:

assolutamente prestazioni superiore a 'Ethercat o il Profinet. un bus proprietario è sempre più veloce perché cucito su misura.

ho usato molto in passato mechatrolink II (connettori simile a usb) ed era già superiore a profinet., 

ho trovato in internet che maggiore è la quantità di byte che di scambia il master con gli slave in Ethercat  più aumenta il tempo di ciclo della rete.

ora..non ricordo con precisone perché l'ho usato solo una volta anni fa,mi sembra di ricordare che più dati scambiavo più il tempo di ciclo aumentava.

 

non sono sicuro di aver capito bene, mi stai dicendo che Mechatrolink-III ha prestazioni superiori ad Ethercat?

Tornando alla domanda iniziale anche secondo la tua esperienza il problema della mancata sincronizzazione non si pone in caso di allarmi/guasti, frenate di emergenza o qualsivoglia problematica (ovviamente escluse le condizioni di rottura meccanica su cui l'azionamento non può fare nulla)

 

Grazie

[lelos]

 

Il 27/1/2022 alle 20:14 , Axis23 ha scritto:

non sono sicuro di aver capito bene, mi stai dicendo che Mechatrolink-III ha prestazioni superiori ad Ethercat?

 

Mi sono fermato a mechatrolink II con 14 assi  , confrontato  a profinet era leggermente più performante , il mechatrolink III non l'ho  mai usato e non dati per paragonarlo a ethercat. 

La sincronizzazione in caso di allarmi/guasti ecc. viene a mancare .Solitamente il master è un asse virtuale , ma nel tuo caso di pantografo potrebbe essere interpolazione a 2 assi.

Poi come rimettere in fase il tutto ,ogni marca si diversifica dall'altra.

Ci sono schede motion dove il carico di lavoro è lasciato alla cpu del plc ,ci sono schede motion con processore dedicato  molto più potente di quello del plc perché devono fare molti calcoli in poco tempo.

ok il bus di campo può essere il più veloce , ma occorre tener conto di costa ci sta a monte.

faccio un esempio Mitsubishi stessi motori , stessa rete sscnet su fibra ottica ,stessa applicazione   ma una con cpu motion , una con simple motion che usa la cpu del plc.

prestazioni non confrontabili con interpolazioni e ripetuti posizionamenti (oltre 180 al minuto).

Quindi ritornato al pantografo .. in caso si errore il "sistema" potrebbe gli assi in stop rapido (per evitare, come tu dici rotture) ,  che anche se messo al minimo come tempo di frenata, dipende dall'inerzia del carico, dagli eventuali riduttori ,ecc..

La rete con 2 assi mechatrolink III è sufficiente , ora, da quando c'è un errore (impedimento /errore in genere) il sistema in quanto tempo risponde ?

con quello che uso (plc/motion) sto appena sotto a 1 millisecondo. Se il pantografo  si muove veloce di serve un sistema performante , in caso contrario non penso,

Il 21/1/2022 alle 11:49 , Axis23 ha scritto:

Ho parlato con il fornitore ma onestamente non ne ho ricavato una risposta concreta ed esaustiva quanto piuttosto una cosa del tipo "vediamo poi con la macchina in opera" che ritengo inaccettabile perchè se dovessero risultare problemi irrisolvibili comporterebbe la riprogettazione completa

capisco il fornitore , ci sono variabili che sono diffidi da calcolare e solo l'esperienza può aiutare , anche se non  darti certezze  ma almeno essere confidenti che funzioni. 

L'uscita di allarme che usi per lo stop dell'altro servo non mi sembra idonea..

L'uscita quando si attiva ? quando perde sincronismo (il servopack non può saperlo)  ? quando il servo va in errore ? e qui si apre un ventaglio si casi , potrebbe essere sovraccoppia, errore di inseguimento tra gli impulsi che deve fare e quelli che ha fatto ,ma rimane il fatto che è legato al servo e lui non conosce cosa sta facendo quell'altro. Quindi per me è e compito del sistema il controllo e lo stop dei motori.

Discorso diverso per l'emergenza che apre le abilitazioni (di emergenza) del servo , sempre che la macchina debba rispettare le normative.  

Modificato: 29 gennaio 2022 da lelos

[Axis23]

Il 29/1/2022 alle 20:53 , lelos ha scritto:

Mi sono fermato a mechatrolink II con 14 assi  , confrontato  a profinet era leggermente più performante , il mechatrolink III non l'ho  mai usato e non dati per paragonarlo a ethercat.

Si il ML-II dovrebbe essere a 10Mbps mentre il ML-III arriva a 100Mbps.

 

Il 29/1/2022 alle 20:53 , lelos ha scritto:

Solitamente il master è un asse virtuale , ma nel tuo caso di pantografo potrebbe essere interpolazione a 2 assi.

Non dovrebbe essere lo slave l'asse virtuale rispetto al Master? Forse faccio casino con le definizioni...

 

Il 29/1/2022 alle 20:53 , lelos ha scritto:

con quello che uso (plc/motion) sto appena sotto a 1 millisecondo

ti riferisci al ML-II Yaskawa di cui sopra o ad un altro sistema/marca?

Il 29/1/2022 alle 20:53 , lelos ha scritto:

L'uscita quando si attiva ? quando perde sincronismo (il servopack non può saperlo)  ? quando il servo va in errore ? e qui si apre un ventaglio si casi , potrebbe essere sovraccoppia, errore di inseguimento tra gli impulsi che deve fare e quelli che ha fatto ,ma rimane il fatto che è legato al servo e lui non conosce cosa sta facendo quell'altro. Quindi per me è e compito del sistema il controllo e lo stop dei motori.

Discorso diverso per l'emergenza che apre le abilitazioni (di emergenza) del servo , sempre che la macchina debba rispettare le normative.

Si in realtà lo schema di collegamento che ho ipotizzato non sarebbe per gestire la sincronizzazione (visto che come dici ogni servopack non sà "cosa fà l'altro") quando piuttosto per velocizzare la comunicazione tra servopack A e B in caso di allarme.

Prendendo ad esempio il caso in cui un oggetto estraneo finisca su uno dei due lati del gantry bloccandone meccanicamente l'avanzamento, avrei un allarme dovuto al superamento di coppia, questo allarme dovrei quindi trasmetterlo il piu velocemente possibile al servo posto sull'altro lato del gantry per fermalo immediatamente ed evitare ulteriori danni.

L'ipotesi nasceva da questa situazione critica, con il presupposto (forse sbagliato) che passando per il motion ci sia un delay sensibile (centesimi di secondo) avevo ipotizzato questo collegamento diretto, teoricamente più veloce. Insomma, se anche passando dal motion controller si parla di millesimi di secondo (o meno) tutto il ragionamento perde di significato.

 

Il 29/1/2022 alle 20:53 , lelos ha scritto:

Ci sono schede motion dove il carico di lavoro è lasciato alla cpu del plc ,ci sono schede motion con processore dedicato  molto più potente di quello del plc perché devono fare molti calcoli in poco tempo.

Il controller MP3300iec ha una CPU a 1,2Ghz ...dovrebbe essere molto più potente dei processori per PLC standard, no?

[lelos]

19 ore fa, Axis23 ha scritto:

Prendendo ad esempio il caso in cui un oggetto estraneo finisca su uno dei due lati del gantry bloccandone meccanicamente l'avanzamento, avrei un allarme dovuto al superamento di coppia, questo allarme dovrei quindi trasmetterlo il piu velocemente possibile al servo posto sull'altro lato del gantry per fermalo immediatamente ed evitare ulteriori danni.

se aspetti il superamento del limite di coppia (dipende poi a quando lo imposti dal 100% al  300%) significa che il sistema ha urtato qualcosa ha prodotto una coppia (impostata) e dopo un tempo x (solitamente programmabile) dà il segnale di coppia superata ,se poi usi dei riduttori questo sistema diventa poco sensibile.

in questo caso si può monitorare costantemente la coppa e quando supera una certa soglia fermate gli assi. (rientriamo nel discorso di velocità del sistema , più è veloce e più ti "proteggi")

oppure monitorare la differenza tra gli impulsi fatti e quelli da fare (se il sistema li fornisce) e  quando supera una certa soglia fermate gli assi. 

oppure modulare la coppia durante il movimento , questo dipende dalla meccanica... e se il sistema ha questa possibilità 

 

19 ore fa, Axis23 ha scritto:

Il controller MP3300iec ha una CPU a 1,2Ghz ...dovrebbe essere molto più potente dei processori per PLC standard, no?

non conosco questo controller , la velocità della cpu può dire tutto niente , dipende dal software ....non so neanche se fa anche da plc.