Conflitto encoder SW - serial rec.

[Lombo]

Buongiorno,
Nel corso di alcune prove riguardanti il comando di velocità di un motore dc tramite comunicazione seriale tra FLEX motion board e pc ho riscontrato alcuni problemi relativi al blocco encoder software, che sembra andare in qualche maniera in conflitto con il blocco "FLEX_serial_receive". Lo schema adopretato è quello allegato, la zona nel rettangolo verde serve da "Filtro" per i comandi della seriale in modo da mantenere in uscita l'ultimo carattere inviato ed ignorare i segnali di polling, il complemento ad uno del segnale PWM per avere un PWM sul motore in linea col valore mandato in ingresso al blocco "FLEX_MTB_pwm" che, come mi ha confermato Dario in un'altra discussione, ha questo comportamento per poter utilizzare l'apposito plugin di controllo dei motori DC fornito che però Noi non utilizziamo per ragioni storiche (Il progetto è cominciato utilizzando erroneamente palette del menù DemoBoard e senza utilizzare detto plugin ed andare a cambiare le cose adesso sarebbe troppo complicato)
Il blocco "FLEX_gpout" serve per il comando direzionale del motore, inserito in un ponte H esterno. Disponiamo di due motori comandati dai pin FLEX_gpout 6 e 7 (Più 8 per l'abilitazione, comune ad entrambi).
Lo stesso schema, utilizzando però l'ingresso encoder hardware, funziona senza problemi, Qualunque uscita PWM si utilizzi e Qualunque segnale di comando di direzione si adoperi.
Vi segnalo il problema non solo perchè possiate risolverlo negli aggiornamenti futuri ma anche perchè, dovendo implementare un protocollo di comunicazione seriale 485 basandomi sul 232 già fornito, finchè questo inconveniente non viene in qualche modo chiarito mi trovo impossibilitato a proseguire col mio lavoro.
Certo di una Vostra risposta e del Vostro supporto, Vi ringrazio anticipatamente, distinti saluti,
Lorenzo.

[paolo.gai]

Ciao,

chiedo a Dario di fare una verifica... ti faremo sapere quanto prima!

PJ

[Lombo]

Ulteriore prova: usando la comunicazione seriale per comandare un motore collegato all'encoder hardware ed inserendo nello schema anche il blocco encoder software lasciato però scollegato (Vedi schema sotto) il funzionamento risulta corretto. Al momento in cui però vado a muovere a mano il motore collegato all'ingresso encoder software avviene il conflitto: il valore in uscita dal blocco verde si modifica indipendentemente dalla comunicazione seriale. Può essere un problema di memoria condivisa o di conflitto tra interrupt? Bo!

[erikadds]

Potrebbe esserci un conflitto. Per esserne certi dovrei fare un po' di debug.
Per accelerare un po' i tempi potresti inviarmi il diagramma a blocchi e nei prossimi
giorni cercherò di ritagliarmi un po' di tempo, nonostante i vari impegni, per risolvere il problema...

Ciao,
Dario

[Lombo]

Ok, grazie! Ma a che indirizzo lo invio lo schema?

[paolo.gai]

Please use dario "at" evidence "dot" eu "dot" com

PJ

[Lombo]

Buongiorno,
Non vorrei sembrare tedioso, ma il problema persiste ed il tempo stringe...
Ho visto che nel file "flex_serial_receive.c" presente in "C:\Evidence\eclipse\plugins\com.eu.evidence.ee_1.5.1.201101101241\ee_base\pkg\mcu\microchip_dspic\src" non vengono gestiti i casi di errore restituiti dalla funzione "EE_uart_read_byte()" (Definita in "ee_uart.c" presente in "C:\Evidence\eclipse\plugins\com.eu.evidence.ee_1.5.1.201101101241\ee_base\pkg\mcu\microchip_dspic\src") chiamata dalla funzione "flex_serial_receive()" al flag "StateUpdate" (Riga 78) ma non credo sia questo il problema...

[paolo.gai]

dubito sia quello il problema... Dario è attualmente occupato con un progetto in scadenza, per cui non so se riuscirà a rispondere a breve...

In ogni caso non sos e sia corretto nello schema avere dei blocchi encoder non connessi a nulla...

PJ

[Lombo]

Di solito in scicos l'importante è che gli Ingressi dei blocchi siano tutti connessi, le uscite possono rimanere flottanti. Comunque per il caso in esame non è un problema perchè altre volte, per altre prove, ho adoperato una configurazione simile per poter muovere a mano la ruota e leggere l'encoder. In questo caso la prova è stata quella di lasciare l' uscita dell'encoder software "Ferma" ed adoperare la seriale, che funziona finchè non muovo a mano la ruota connessa all'encoder software. A quel punto avviene il conflitto...

[erikadds]

Ciao,
ho testato il diagramma a blocchi che mi hai inviato e non ho riscontrato nessun conflitto anche impostando valori molto bassi nel clock principale (ho provato fino a 2ms).
Riesco a ricevere dati corretti sulla seriale e ad acquisire senza errori l'encoder software.
Con un periodo di 2ms ho una risposta più lenta ma questo è normale.
Se non ti funziona correttamente il problema potrebbe essere che stai usando una versione del codice non molto recente o avete dei collegamenti hw instabili
(io per le prove ho usato il modulo motori DC perchè altrimenti non avevo i pull-up sugli encoder...).
Ti consiglierei di usare valori più alti per il clock principale, di usare una versione più recente dello ScicosLab pack o di Erika e di acquistare il modulo motori DC per avere meno problemi a livello hw.
Inoltre ti informo che sta per uscire il nuovo ScicosLab pack! Il nuovo pacchetto avrò l'installer per facilitare l'installazione e sarà stand-alone, e ciò significa che Erika ed RT-Druid saranno inclusi nel pacchetto. Ti invito a provarlo...

Grazie per avere scritto sul forum.
Ciao