CNC 3 assi+1 - doppia vite - Kflop

[Pedro]

a me successe una volta ma tanti anni fa su un asse solo e ricaricai da 0 sia il bootlog che il firmware della kflop ma perchè "stuzzicai" io qualcosa, non mi ricordo più cosa. La cosa però qui è su tutti gli assi, troppo strano tutto a meno che quei driver siano "lenti" nel leggere gli impulsi di input. A che divisione di microstep siamo? con l'FPGA a 63 più di 100kHz non sono possibili in uscita

[arm]

I driver sono a 1/8.

Stavo ragionando.
Cnc con gli stepper; sulla Y in CL non c'è errore, bene; ma se vanno in OL, come la X e la Z accumula una marea di errore. Anche mettendo gli encoder su x e z sarebbe una cura che però non "guarisce" il problema, lo aggira, ovvero, visto che quei motori e driver quando erano montati sull'altra cnc hanno lavorato per 2 anni con una Bb parallela e non hanno perso un passo dopo due ore di lavoro, allora il problema è solo la Kflop?
Forse anche il problema della velocità modesta della Y sarà conseguenza di questi problemi?

[walgri]

Potrebbe.

La specifica dei driver dice che si possono raggiungere frequenze fino a 100kHz. Non dice nulla sulla durata minima dello step. Adesso stiamo a poco meno di 4us. Potrebbe pure darsi che siamo troppo ai limiti.

Potremmo pure eliminare gli opto sulla bb, ma francamente non me la sento di avere i pin diretti al cuore della kflop così esposti su un" banale" db25.

Se questo fatto è il principale indiziato possiamo fare delle prove con dei piccoli driver che ho che hanno uno step rate massimo di 500kHz, oppure provare con la mia Pokeys che ha una durata di step fissa a 20us.

[Pedro]

per prova si potrebbe si collegare la kflop ai driver, la kflop in modalità OC e vedere. Tra l'altro usando un opto, un altro opto, dopo la kflop si ha un NPN cioè invertente sul segnale in uscita. Quindi se il segnale dovrebbe durare 4 uS sarebbe non in impulso ma di pausa, insomma sempre alto meno i 4 uS, non so se a tutti driver piace. Allora usare eventualmente gli opto in modo collettore comune, collettore di uscita degli opto al +5V, emettitore al + dell'ingresso del driver, il - del driver a GND (senza resistenze perchè dicevamo che i driver le hanno già dentro). Ma prima io li collegherei, o almeno uno per prova, direttamente alla kflop, sempre in modalità OC (però a quel punto il + dell'ingresso dei driver va al +5V, il - dell'ingresso driver all'uscita della kflop). Spero di essere stato chiaro, altrimenti chiedete ma mi pare chiaro.

[dmoglianesi]

Ciao pedro, scusa l'ot ma dovendo fare una scheda d'inerfaccia tra la kflop e il mondo esterno si potrebbero utilizzare dei lne drive tipo max che funzionano a 3,3 volt? Cosi si avrebbe un adattamento perfetto e l'uscita essendo bilanciata sarebbe insensibile ai disturbi, per le entrate molti encoder sono line driver , se ho detto una caz... Come senpre siate benevoli Parlo di max perche li uso e con oltre 100 mt di cavo in ambiente estremamente pieno di disturbi e l'unico che vada bene e tu sai di che ambiente parlo ciao

[walgri]

Forse la prova più rapida da fare ora è impostare la kflop su pulse low, anziché pulse high per invertire il segnale.
Arm, puoi farlo anche da solo: togli + 0x80 dall'init.c alla riga che comincia per FPGA etc. Lascia il punto e virgola finale.

[Pedro]

rispondo a dmoglianesi:

100 mt di cavo, dillo che vuoi il controller in Italia e la macchina a Lima

scherzo Dalmazio, lo sai. In current loop: e perchè così lontano? va bene che metti l'elettronica fuori della macchina ma a tutto c'è un limite, io non lo farei anche se in current loop saresti abbastanza sicura ma abbastanza a casa mia non basta

Tra l'altro ti chiederei di usare il tuo topic per le domande, se vuoi, se no aprine un altro che questo già è difficile seguirlo di suo e non complichiamoci di più la vita

@walgri: si in effetti è la cosa più rapida, io pensavo al segnale e non alla sua generazione

comunque penso che quei driver non amino "status" negativi così brevi ma vediamo che succede

PS: a me risulta che se faccio 63 (dec) + 80 (hex) + 7° bit settato per invertire il segnale fa FF(hex)

quindi scriverei:

FPGA(STEP_PULSE_LENGTH_ADD)=0xFF;

ma sto in carenza caffeina e potrei sbagliarmi...

[arm]

ok. ora è così
FPGA(STEP_PULSE_LENGTH_ADD)=63 + 0x80; // Imposta la durata dello step a ~4us (driver Z lento)

e metto
FPGA(STEP_PULSE_LENGTH_ADD)=63 ; // Imposta la durata dello step a ~4us (driver Z lento)

e poi, 2 prova, provo così.

FPGA(STEP_PULSE_LENGTH_ADD)=0xFF ; // Imposta la durata dello step a ~4us (driver Z lento)

[walgri]

Scusate tutti, prima ho scritto di togliere 0x00, in realtà intendevo 0x80, come poi è stato scritto. Ho corretto il mio messaggio precedente.

@Arm: Puoi anche levare tutto quello che segue il punto e virgola, tanto i driver son tutti uguali.

@Pedro, se tu sei a corto di caffeina io sono a corto di neuroni, mi pare che dia BF, ma già è una pericolosa assonanza con il linguaggio BF
In realtà da quel che ho capito dalla famosa pagina http://www.dynomotion.com/Help/StepAndD ... AndDir.htm è proprio lo 0x80 che inverte l'impulso. Però magari non ho capito nulla.

[Pedro]

mi correggo: la pausa caffè è necessaria più spesso

FPGA(STEP_PULSE_LENGTH_ADD)=63 ; // Imposta la durata dello step a ~4us (driver Z lento)


è la cosa giusta...pardon; ho considerato come uso per la mia la traslazione degli step sul jp4 e jp6 ma non avendo arm la kanlog non serviva

[arm]

Ehm, se levo + 0x80, i motori non si muovono, sia in OL che CL.
Se premo i tasti freccia della x e z vedo a schermo le coordinate che avanzano, se premo le frecce di y le coordinate diventano gialle.
per riabilitare devo spengere la kflop. Anche mandando un gcode la y diventa subito gialla.
Se ripristino il + 0x80 funzionano.

[arm]

Prove in OL e CL con + 0x0,80, con 10 spostamenti.
come ieri in OL rosso e blu sono divergenti.

[Pedro]

mumble...

[arm]

Ho rimesso le htd. Una puleggia su un motore y sgranava un po. Maledetti grani su alluminio...
rifatte prove in OL e CL.
In OL su 5 prove. Le prime 3 ha finito il ciclo fermandosi prima con uno scarto di 4/5 cent. Alla 4 prova si è disabilitato l'asse a metà ciclo

[walgri]

Diagramma errore rosso Y1 OL: quando torna indietro c'è un lasco maggiore che all'andata e si accumula continuamente.