MECCANICA e DINTORNI

mimmoletti, per come la giri e per come rispondi ho sempre avuto la "strana" impressione che il tuo unico scopo fosse quello di "insegnare" + che di spiegare...

detto questo, in considerazione che qualsiasi cosa si dica sono ai tuoi occhi "cazzate", visto che il tuo sistema è perfetto e che hai addirittura eseguito un controllo metrologico con tamponi rettificati e cerfiticati
visto che di contro tu non metti a disposizione il tuo software (ampiamente collaudato da chi?)

visto che cmq trovi strano che altre persone cerchino di trovare soluzioni alternative allo stesso problema gia' risolto in passato e quindi non capisco perchè tu in primisi abbia riprogettato il software invece di copiare pari pari quello che gia' esisteva (dal quale per tua stessa ammissione hai cmq "fregato" qualche riga, e questo solo perchè c'è ancora qualche "fesso" che le cose le fa per il gusto di farle e condividerle...)

penso non ci sia molto altro da dire ;)

bye luk


ps, per le alternative "impossibili da applicare", se ho ben interpretato il pensiero di Max, erano "impossibili" per il banale fatto che non erano applicabili con le componenti/processori che lui ha usato, componenti tutti disponibili anche a chi non capisce nulla di elettronica come il sottoscritto e tutti "plug and play" nel senso che alla peggio ci sara' da fare un punto di saldatura e non mettersi a fare circuitini con integrati e componenti che per quanto semplici possono sconfortare i meno pratici), il tutto per rendere autonomo chiunque voglia realizzare il progetto che banalmente non avra' altro da fare che comprare i pezzi, assemblarli e programmare l'arduino personalmente con il codice messo a disposizione e senza aspettare un chip preprogrammato, indifferentemente dal fatto che lo fornisci gratuitamente o meno. in questo modo qualsiasi problema sara sempre perfettamente risolvibile da chi ha creato la cosa, anche perchè mi vien da chiedermi infatti, se un domani tu per un qualsiasi problema non voglia/possa + fornire il chip, io che ho realizzato il tuo progetto, speso soldi e tempo in materiali e montaggio, mi si brucia la schedina.... butto tutto?

ps, perdonami se l'hai vista come un insulto la mia osservazione, io purtroppo sono abituato a parlare chiaro

per me una alternativa non praticabile = nessuna alternativa

Software e manuali aggiornati a v1.4

Continui a dire cose inesatte e non ne capisco il motivo, un conto è discutere se una cosa si possa o non si possa fare o come andrebbe fatta, un'altra cosa è inventarsi le cose di sana pianta, come fai tu:

A Max ho detto (riassumendo), non mi piace il modo in cui esegui la divisione, andrebbe fatta in questo modo...

A Max ho detto (riassumendo), sarebbe opportuno usare il Timer, anziché l'interrupt sul cambio di Stato di delle porte....

Il mio progetto è stato realizzato da tre utenti di questo forum, uno di questi abita nella nostra zona, San Sebastiano al Vesuvio. Attualmente non è a casa, perché si è trasferito momentaneamente dalla figlia che abita in provincia di Milano.
Sarà di nuovo a casa probabilmente a Gennaio.
Avresti potuto vedere di persona l'impossibile...
Il mio non conta perché l'ho aggiornato con il nuovo Pic, anche se il programma e praticamente lo stesso ad eccezione di qualche piccolo particolare.

Perché non ho utilizzato il progetto del russo? semplice non funzionava, succedeva esattamente quello che succede a Max, non riusciva a mantenere la sincronizzazione, durante gli avanzamenti dove la velocità del mandrino e molto più alta che in filettatura. E' soprattutto non aveva le funzioni che ho aggiunto, dettate dalla mia fantasia.
Altrimenti non avrei perso tempo.

[color=#FF0000][color=#FF0000]ps, per le alternative "impossibili da applicare", se ho ben interpretato il pensiero di Max, erano "impossibili" per il banale fatto che non erano applicabili[/color][/color]

Un'altra inesattezza, Max le ha ritenute inapplicabili perché secondo la sua opinione non potevano funzionare e non perché non riproducibili su Arduino, anzi il il processore che usa arduino si può configurare in modo che il Timer si incrementi sia sul fronte di salita che sul fronte di discesa del segnale, rendendo l'XOR superfluo. Andrebbe aggiunto solo il Flip Flop, non mi sembra una cosa impossibile da fare anche per chi mastica poco l'elettronica.

Quindi puoi essere d'accordo o meno su quello che faccio o scrivo, ma questo non ti autorizza ad inventarti le cose...., farlo è scorretto.

Non mi interessa di fare l'insegnate, ma ho sempre pensato che la dove ci si può avvantaggiare dell'esperienza di altri, perché non farlo? Il russo con 4-5 righe di codice ha brillantemente risolto il problema, perché inventarsi soluzioni macchinose e peggiorative?

Ho visto solo dopo il tuo messaggio, il punto non è parlare chiaro ma parlare giusto.

soluzioni PEGGIORATIVE?
E per quale motivo la mia soluzione sarebbe peggiorativa?

Mentre me lo dici, io sto sempre aspettando che rispondi a questa:

COME HAI RISOLTO QUESTO EVIDENTE PROBLEMA? E l'evidenza non é mia, é matematica....

se la tua risposta é nello schema postato sopra beh... mi spiace informarti che NON SI CAPISCE. Anzi, potrei citare le tue parole dicendoti: mi stai prendendo in giro?

perdonami, ma "avvantaggiarsi" dall'esperienza degli altri senza poi condividere la propria se non per sommi capi e in maniera ambigua questo si che mi sembra un atteggiamento scorretto

io ti sto dicendo le cose per come le ho capite, ribadisco la mia ignoranza in merito alla materia, ma vedi... come si suol dire, se l'alunno non capisce la colpa in genere è dell'insegnante

inoltre a voler fare i permalosi, continui a dire che il software di Max è peggiore del tuo
non me ne volere, ma senza conoscere ne' te ne' Max, fra i due trovo il lavoro di Max l'unico degno di interesse visto che è l'unico che si sta prodigando nel migliorarlo e nel condividere poi i risultati mettendo il suo lavoro in chiaro sul forum

onestamente a me non interessa "vedere" il tuo progetto funzionare...
non me ne volere ma se non erro macchine che filettano automaticamente sono almeno un paio di decadi che gia' esistono ;)

se io non posso capire cosa hai fatto, onestamente non mi applico nemmeno
in tal caso, avrei banalmente comprato un kit e amen

bye luk

ps, "andrebbe aggiunto solo il flip flop" rimane una condizione incompatibile con chi si è prefissato di non usare assolutamente ulteriori componenti

Mi arrendo, sei mitico...

ho capito se uno di quei tipi che vuole avere sempre l'ultima parola...

P.S.

Non me ne volere ma se da parte tua, c'è un'interesse o meno nei confronti di ciò che faccio, non me ne può fregare di meno.

Peggiorative perché nella prima versione di programma (non ho visto la successiva) accumuli un errore per ogni giro del mandrino.

Inoltre se per realizzare la divisione degli impulsi utilizzi più di 5 righe di codice e operazioni matematiche complesse, l'algoritmo è sicuramente peggiorato.

Per il secondo quesito la questione va considerata in un'altra ottica:

Poiché questa non è un regolazione di velocità, ma una regolazione di posizione angolare, non vi è accumulo o scarto di velocità.

Il sincronismo si ottiene quando le due posizioni angolari si eguagliano, pertanto in fase di inversione anche se le due posizioni angolare non combaciano è irrilevante, perché si eguagliano successivamente. E un concetto un pò difficile da comprendere e difficile da spiegare. Il problema lo affrontato quasi due anni fà, ora non ricordo tutti i dettagli.

Non ti resta che provare, volendo puoi fare a meno anche del Flip Flop. A suo tempo l'ho usato solo per semplificare il programma, ma non è indispensabile, basta aggiungere qualche linea di codice.
Se ti va ti spiego come impostare il programma e provi.
Puoi realizzare un piccolo programma semplificato solo per verificare se l'idea può funzionare o no.
Ti basta solo collegare uno dei canali dell'encoder all'ingresso del timer, l'altro lo lasci dove ora è collegato.
Non mi sembra cosi difficoltoso da fare.


In ogni caso, non vorrei essere frainteso, non è mia intenzione sminuire il tuo lavoro, mi stuzzica solo potermi confrontare. Se la cosa ti infastidisce finisce qui.

Ti chiedo però prima di ostinarti a ripetere che la cosa non può funzionare, avendola provata personalmente, di darmi almeno il beneficio del dubbio.

allora mimoletti forse non mi sono spiegato. Continui a ripetere le stesse cose senza darne fondamento tecnico. Ti ho fatto notare che c'è una criticità e te l'ho dimostrato matematicamente e ancora non mi dici come hai risolto.

mimoletti: "Inoltre se per realizzare la divisione degli impulsi utilizzi più di 5 righe di codice e operazioni matematiche complesse, l'algoritmo è sicuramente peggiorato."
Questo dimostra che di quello che ho fatto io NON HAI CAPITO niente perché, semplicemente, non te ne frega niente. Ti ho spiegato dettagliatamente quello che faccio e nel ciclo di filettatura fai molte più operazioni tu di me, e questo te lo posso garantire anche senza aver visto il tuo codice.

Ora facciamo così, se ti va di confrontarti, apri il mio codice e leggilo. Son certo che hai le competenze per comprenderlo visto anche che le parti di calcolo sono tutte commentate.

Bene ho dovuto rispolverare i mie vecchi appunti, sinceramente non ricordavo come avevo fatto.

allora mimoletti forse non mi sono spiegato. Continui a ripetere le stesse cose senza darne fondamento tecnico. Ti ho fatto notare che c'è una criticità e te l'ho dimostrato matematicamente e ancora non mi dici come hai risolto.

Utilizzando il timer in ogni caso non è possibile perdere il sincronismo, puoi capitare a seguito di un'inversione che venga generato un'impulsi di step supplementare, bada bene uno soltanto, non voluto.

Facciamo un'esempio: ruotiamo il mandrino prima a destra e poi a sinistra ritornando sempre nella stessa posizione generando in un senso e nell'altro 9 impulsi.

Cosa succede utilizzando il timer, se il valore di divisione è due (TMR0 = 254)? Verranno generati 4 impulsi in una direzione e 5 in un'altra, quando invece vogliamo generare 4 impulsi in entrambe le direzione.
Come ho risolto? Ad ogni inversione del mandrino viene generato un'interrupt di livello prioritario che mi azzera il valore del timer, che genera in questo modo esattamente 4 impulsi a destra e 4 a sinistra facendo ritornare la vite madre sempre nella stessa posizione.

Scusa se lo scritto in modo poco chiaro, ma e tardi e sono stanco.

non vedo come l'azzeramento del timer possa evitare la perdita di sincronismo.
Ogni passo del mandrino corrisponde ad una posizione angolare specifica, se durante l'inversione azzeri il conteggio perdi istantamente la posizione.

Altro problema è che non vedo come tu possa associare un interrupt all'inversione del mandrino dal momento che l'uscita del FLIP-FLOP, ovvero l'unico segnale in grado di darti la direzione, è collegato al pin 14 del PIC18F2520 che corrisponde all'I/O RC3, che non può essere associato ad una sorgente di interrupt esterno. Questo micro ha 3 pins di interrupt (INT0, INT1 e INT2) più la possibilità di mappare un interrupt sul cambio di stato di un pin della porta B.... ma nel tuo caso la porta è la C....

Risponderò ad una sola delle tue domande, affrontando un problema alla volta, precisamente alla prima, ma ho bisogno che tu risponda ad una delle mie, nel tuo progetto, immaginando che il fattore di divisione sia 2 e di ruotare il mandrino in senso orario e successivamente in senso antiorario in modo che generi 9 impulsi in un senso e nell'altro, quanti impulsi di step generi in un senso e nell'altro? In questa fase non mi serve sapere come fai, ma praticamente cosa generi.

4 step in un verso e 4 nell'altro.
Lo step viene generato al cambio di puntatore sull'array e, in caso di rotazione contraria, il cambio viene effettuato quando lo step vale -1 e non 0.... altrimenti si che avrei uno step di troppo.
In realtà dipende da dove mi trovo nell'array; se mi trovo nel mezzo di una cella genererò 5 step in un senso, ma sempre 5 nell'altro.
Questa è la parte di codice interessata, la variabile steps viene controllata dalla routine di interrupt:
if (steps == -1)
{
digitalWrite (DIR, CCW);
absolute_steps++;
pointer--;
if (pointer == -1) pointer = numero_passi - 1;
steps = sequenza[pointer] - 1;
FireStep();
}
if (steps == sequenza[pointer])
{
digitalWrite (DIR, CW);
absolute_steps--;
pointer++;
if (pointer == numero_passi) pointer = 0;
steps = 0;
FireStep();
}

Scusa ma mentre scrivevo mi si è scaricato il cell., volevo correggere immaginando di avere un progetto ideale è non il tuo, perché altrimenti sembra che voglia screditare il tuo progetto, invece voglio dimostrarti che l'uso del timer è possibile.

Ritornando al discorso:


Immaginiamo che vengano generati dall'encoder 9 impulsi in un senso e 9 nell'altro.
Un sistema ideale genera 4 impulsi in un senso e 4 nell'altro.
Utilizzando il timer vengono generati 4 impulsi in un senso e 5 nell'altro. Quindi viene generato un'impulso non voluto.

Immaginiamo che vengano generati dall'encoder 90 impusi in un senso e 90 nell'altro.
Un sistema ideale genera 45 impulsi in un senso e 45 nell'altro.
Utilizzando il timer vengono generati 45 impulsi in un senso e 45 nell'altro.

Immaginiamo che vengano generati dall'encoder 91 impusi in un senso e 92 nell'altro.
Un sistema ideale genera 46 impulsi in un senso e 46 nell'altro.
Utilizzando il timer vengono generati 46 impulsi in un senso e 46 nell'altro.

Immaginiamo che vengano generati dall'encoder 93 impusi in un senso e 93 nell'altro.
Un sistema ideale genera 46 impulsi in un senso e 46 nell'altro.
Utilizzando il timer vengono generati 46 impulsi in un senso e 47 nell'altro. Quindi viene generato un'impulso non voluto.


Quindi possiamo dedurre che utilizzando il timer per il conteggio degli impulsi in alcuni casi durante l'inversione si generi un'impulso non voluto.

Quindi non si verifica una reale perdita del sincronismo ma un'errore. Concordi con quanto ho scritto?