NEW Servo Drive Dc 100W e 800W

[robylunadei]

Ciao a tutti e complimenti siete fenomeni

[Bit79]

Innanzitutto complimenti a marcosin per l'ottimo lavoro realizzato, veramente professionale.

Come hai realizzato la limitazione di corrente? E' a loop chiuso? Nei drive EMC, da cui dici di esserti inizialmente ispirato, è realizzata ad anello aperto, semplicemente stimando la forza controelettromotrice generata dal motore, e effettuando una limitazione a finestra della tensione generata (Fcem +- Ilim x Rarm). Come sistema quello dei drive EMC mi sembra molto impreciso....

Come hai gestito i loop di regolazione del motore? Hai il loop di posizione che pilota direttamente il pwm, con il loop di corrente in sola limitazione, o hai i 3 canonici loop (corrente, velocità  e posizione) uno dentro l'altro? Se hai utilizzato questa seconda soluzione, i parametri dei loop di corrente e di velocità  sono fissi o regolabili?

Altra curiosità , dato che devo realizzare una protezione simile: che algoritmo di codifica hai usato per criptare il formware del pic? Dovrei appunto realizzare un sistema simile, con firmware distribuiti criptati, da far decriptare poi al bootloader... Ovvio che non ti sto chiedendo la chiave di codifica, solo il concetto dell'algoritmo...

Ciao e ancora complimenti!

[marcosin]

Il loop di posizione va a modulare direttamente il pwm, sistema barbaro ma che per il nostro utilizzo va più che bene.
Il loop di corrente non esiste, ho solo utilizzato un comparatore che legge la caduta di tensione in una resistenza e va ad interdire il pwm utilizzando l'ingresso apposito del pic FLTA.
Per qual che riguarda la protezione del firmware, una volta che ho l'hex, lo carico in un programmino che ho fatto in vb che effettua degli scambi tra gruppi di istruzioni hex, poi sostituisce alcuni codici con altri, effettua degli swap in base al crc della riga etc... diciamo che ho un "algoritmo" se così possiamo definirlo, inventato a caso da me, alla fine mi viene generato un file tutto "mischiato"
Il bootloader dentro il pic sa quale sistema ho utlizzato quindi riceve il programma tutto criptato e poi se lo rimette a posto.

[turbina]

Un Sistema semplice per proteggere il firmware e' quello di modificare un bootloader facendogli scrivere al reset prima di andare all' applicazione una password in una serie di locazioni ram che poi l'applicazione verifichera' , la lettura del hex del bootloader e' resa inacessibile all' utente. Il vantaggio di questo sistema rispetto ai sistemi che che ricodificano il codice e' in caso di firmware applicativo errato si puo' inizializzare lo stesso la scheda e far apparire su un display, un led, una seriale etcc un messaggio di firmware errato

[Bit79]

Ciao,
anche io ho sviluppato un drive simile, con loop di posizione che comanda direttamente il pwm. Ho anche provato a utilizzare lo stesso firmware per pilotare un drive commerciale analogico (con loop di corrente e di velocità ) e non ho riscontrato differenze di prestazioni... forse nel secondo caso sono pure leggermente inferiori, anche se la taratura è un pochino più immediata, ma roba di poco.

Mi piacerebbe comprendere a fondo l'utilità  di più loop di regolazione uno interno all'altro, sto anche facendo delle simulazioni con matlab...

Riguardo alla regolazione di corrente la semplice disabilitazione del pwm mi sembra insufficiente... con correnti positive (assorbite dal motore) funziona, ma se la sovracorrente ti si verifica in recupero resettando il pwm peggiori la situazione (in pratica il pwm andrebbe aumentato, non diminuito). Diciamo che se non prevedi funzionamento in recupero può andare. Io ho previsto 2 resistenze di sense, una per ramo, in modo da discriminare anche la corrente di recupero.

Se ho ben capito la tua codifica effettua sia degli spostamenti di posizione che una crittazione dei valori stessi. Avevo il dubbio anche io che una semplice crittazione, senza scambio di posizione tra i blocchi, potesse essere facilmente craccabile, tra l'altro è anche fatta sempre con la stessa chiave, per quanto lunga possa essere...
Ma ti ci sta il bootloader con l'algoritmo di decrittazione nel blocco di memoria relativo al boot code del pic (da 0 a 200h mi pare...)?

Per turbina:
si, il tuo sistema funziona, ma dato che l'hex non è codificato, è facilmente disassemblabile e modificabile per essere poi utilizzato anche su processori senza bootloader. Non sarà  immediato, ma non è un lavoro difficile...
Il concetto è quello di rendere inutilizzabile il codice hex in assenza di processore programmato con il relativo bootloader.

[syntronik]

Ma avete provato a mettere tutto su uno Stratix della Altera, che ha anche un bel micro a 32 bit,
io lo uso correntemente, e sfido chiunque a scopiazzare quello che c'è dentro,
OVVIAMENTE si deve essere in possesso di una regolare licenza, per "chiudere il portone",
altrimenti se si usa il normale Quartus II, è disponibile anche ai meno esperti
saluti
Maurizio

[Bit79]

Intendi dire che il firmware caricato è protetto?
Quello puoi proteggerlo anche su un pic, ma non è il nostro caso.
Sia nel mio caso che in quello di marcosin i firmware è distribuito, e l'utente finale lo può caricare sul micro.
La questione è di non farlo copiare, o caricare su micro vergini, ma poterlo usare solo su micro venduti con apposito bootloader.

[marcosin]

Per un drive dedicato al nostro utilizzo la gestione del ponte come l'ho effettuata mi sembra abbastanza adeguata anche se spartana, la limitazione di corrente deve intervenire quando c'è un sovrasforzo importante, non mi sono prefissato l'obbiettivo di controllare il motore in coppia. Ovvio che tutto è migliorabile.

Il pic che ho usato non ha una memoria dedicata al bootloder quindi ho fatto alla vecchia maniera, faccio un esempio semplificato, ammettiamo di avere un memoria totale di 2000 indirizzi:

da indirizzo 2 a 1200 programma applicazione
da indirizzo 1500 a 1800 bootloder

indirizzo 1 : goto indirizzo 1500
2: applicazione
3: applicazione
4: applicazione.....
.....1199: applicazione
1200:goto indirizzo 2

Indirizzo 1500: attesa firmware per 2 secondi, se arriva vado avanti con il bootloader, altrimenti salto all'indirizzo 2 ed eseguo l'applicazione.
1501: bootloader
1502: bootloader.....
.....1799: bootloader
1800: goto indirizzo 2

Non so se è chiara la rappresentazione fatta, in questa maniera il bootloader lo faccio grande come voglio, devo solo stare attento di non sovrascriverlo con l'applicazione facendo crashare tutto.

Per quel che riguarda il processore mi sembrava buono un pic da qualche euro, con tool di sviluppo free e hardware di programmazione che può anche essere autocostruito.
Certo si può usare uno Stratix, un ARM, un Cortex, fino ad arrivare ad un I7, a me però pare un pò esagerato, e poi sinceramente le mie scarse conoscenze non me lo permettono.
Lasciatemi dire, però, che anche se esistono processori così evoluti e potenti ho potuto ammirare pochi progetti a livello hobbistico di drive dc funzionanti, in compenso so per certo che in molti hanno provato a decodificare o copiare il mio hex, sicuramente prima o poi qualcuno ci riesce...

[Zebrauno]

Chi ha osato!?

[turbina]

Marcosin:Lasciatemi dire, però, che anche se esistono processori così evoluti e potenti ho potuto ammirare pochi progetti a livello hobbistico di drive dc funzionanti,"

Concordo, e' proprio carino il tuo drive...Vedrai il mio eh eh eh

[Zebrauno]

Mi piacerebbe leggere le impressioni di chi ha questi drive sul forum, personalmente installandoli con quel minimo di precauzioni descritte benissimo anche da Marcosin i miei stanno lavorando alla grande.
La prossima cnc si basera' ancora su questi drives e dopo averli usati a lungo credo siano un ottimo modo per fare l'ingresso nel mondo dei servo.

Con altri sistemi commerciali non ho avuto la stessa semplicita' d'uso e configurazione...

ciao

[marcosin]

@Turbina
Grazie, allora aspettiamo anche il tuo moooolto volentieri!

@Zebrauno
Grazie 1000!

[ledtape]

da inesperto ne ho assemblato uno per prova a vuoto ( il motore non e' installato su cnc) e debbo dire che e' a prova di principiante.
Sul cnc in costruzione montero' senz'altro i driver di Marco, che come sempre ringrazio per la disponibilita'.

Non e' da tutti.

[Bit79]

Ciao marcosin,
si, ho capito che struttura hai usato per il bootloader. Io preferivo usare la struttura con bootloader all'inizio della memoria programma, con rimappatura degli indirizzi di interrupt, ma è solo una scelta. In effetti non vi è un limite alla lunghezza del bootloader, è solo che il pic che uso (18F4431) ha i code protection divisi per pagine, e ne ha uno apposito per il bootloader a inizio memoria, di 200h locazioni.
Tu proteggi tutta la memoria programma o solo la parte del bootloader? Immagino che attraverso il bootloader si possa caricare il firmware anche se la memoria è protetta..., quindi si potrebbe anche proteggerla tutta, e avere la massima libertà  per dove e come posizionare il bootloader...

Riguardo ai drive condivido le tue scelte strategiche di regolazione... dovrò vedere come si comportano applicati su una cnc in lavorazione, lo farò a breve. Io ho fatto un loop di corrente più accurato, che lavora in limitazione sul pwm. Alla fine però se mi trovo nella condizione di limitare al corrente, in brevissimo tempo vado in errore di posizione, quindi in effetti una regolazione molto elaborata può servire a poco... servirebbe se si usasse il drive in regolazione di coppia, ma non è il caso usuale degli assi di una cnc...
Sarebbe interessante confrontarne le prestazioni, anche a distanza, utilizzando lo stesso tipo di motore (gli E240 che giravano sul forum potrebbero essere una buona scelta, li ho anche io).

Qualche giorno fa ho fatto una prova, i cui risultati mi hanno però lasciato un po' scettico. I miei drive, più per tradizione e copia di vecchi programmi che per scelta, lavorano a 2 ms di ciclo programma. Lo so, non è velocissimo, ma funzionano benino. Il processore utilizzato mi permetterebbe di ciclare molto più veloce (il software era nato per la serie 16), almeno 4 volte più veloce... così ho voluto fare la prova. Ho ottimizzato al massimo il pid con il clock a 2 ms, poi ho modificato il firmware per ciclare a 500 us, aspettandomi un notevole miglioramento delle prestazioni (avevo anche fatto una simulazione con matlab, e c'era molta differenza). Contrariamente alla aspettative, ho trovato lo stesso limite della prova con 2 ms, non ho guadagnato nulla, nonostante il ritardo di elaborazione sia diventato 1/4...

[edisonthai]

salve a tutti ed un felice natale ,
parecchio tempo fa, avevo acquistato dei servodrive ed degli stepper drive, della gecodrive , in totale 11 pezzi pagati una fortuna .
ed debbo ammettere senza ombra di dubbio, che il servodrive di marcosim e nettamente migliore , rispetto a quelli della gecodrive .