Costruiamo un sistema di controllo CAN

Realizziamo un sistema di controllo a distanza basato su CAN Bus, composto da un’interfaccia CAN-USB per PC nel quale gira un apposito software mediante il quale controllare una serie di schede slave ognuna delle quali dispone di 4 relè utilizzabili per pilotare carichi elettrici. 

Il protocollo CAN (Controller Area Network) è ormai diventato lo standard de facto per la realizzazione delle reti di bordo degli autoveicoli; creato all’interno della Robert Bosch GmbH negli anni ‘80 del XX secolo, con l’idea di creare uno standard per le comunicazioni seriali a corto raggio tra diverse unità elettroniche che avesse caratteristiche di elevata immunità ai disturbi, basso costo ed elevata affidabilità, questo standard si sta ormai diffondendo anche al di fuori dell’automotive, iniziando a penetrare all’interno di settori come l’automazione ed il controllo industriale, il monitoraggio e l’aerospace. Un esempio di applicazione basata su livello fisico CAN che ha avuto un notevole successo in ambito non-automotive è rappresentato dallo standard CANopen.

 

Fig. 1 Esempio di applicazione CANopen.

Schema elettrico scheda CAN Master

Descrizione del progetto

Ciò che ci proponiamo di realizzare è un sistema di controllo di carichi elettrici composto da una scheda master che funge da interfaccia USB/CAN (controllata tramite un software per ambiente desktop) locale e da una serie di schede slave remote (cioè poste fisicamente dove si trovano i carichi da controllare), dotate ognuna di interfaccia CAN e di 4 relé. Ogni singola scheda slave potrà essere controllata tramite un set di comandi di alto livello inviati tramite opportuni messaggi CAN.

Sarà inoltre possibile modificare i parametri di funzionamento delle schede slave, come ad esempio il baud-rate o il filtraggio hardware dei messaggi in ingresso, in modo da fornire al sistema un alto livello di configurabilità.

Le caratteristiche del CAN Bus rendono un sistema di questo tipo adatto a diverse applicazioni nelle quali sia necessario controllare un certo numero di carichi tramite una soluzione cablata con un certo numero di nodi e anche su distanze elevate.

Infatti, riducendo opportunamente il baud rate, con il CAN Bus è possibile realizzare collegamenti a distanze anche di alcuni chilometri (vedere Tabella 1).

 

Come si può vedere dalla tabella, abbassando il baud-rate della connessione a una decina di kbit/s (comunque un data-rate sufficiente per molte applicazioni), si può arrivare a coprire alcuni chilometri di distanza.

In Fig. 2 è rappresentato uno schema di principio dell’applicazione, con quattro nodi slave.

In questa prima puntata esamineremo in dettaglio la scheda slave, partendo dai requisiti fino ad arrivare all’implementazione hardware; nella puntata successiva ci concentreremo sui dettagli realizzativi della scheda di interfaccia, mentre nella terza ed ultima puntata analizzeremo i dettagli dello sviluppo del firmware in Flowcode.

 

Fig. 2 Schema a blocchi di principio.

Requisiti del sistema

Analizziamo adesso i requisiti della scheda slave: possiamo individuare un gruppo di requisiti hardware, un gruppo di requisiti funzionali e, infine, un gruppo di requisiti di configurazione.

Requisiti hardware
Dal punto di vista hardware, vogliamo che il sistema sia dotato di:
• interfaccia CAN 2.0B, con indirizzamento esteso (29-bit) e capacità di raggiungere baud-rate fino a 500 kbit/s;
• 4 relé con relativi LED per l’indicazione dello stato logico associato;
• tensione di alimentazione a 12V;
• due LED di stato, controllati direttamente dal microcontrollore principale e due LED di indicazione del traffico collegati alle linee CANH e CANL;
• opzione per la terminazione della rete CAN a 120 Ω, attivabile tramite jumper.

Requisiti funzionali
Prima di tutto il sistema deve prevedere un messaggio CAN di controllo tramite il quale vengono comandati gli stati dei quattro relé. Vogliamo che lo stato dei relé venga comandato tramite i primi 4 byte del messaggio, secondo la seguente codifica:
• BYTE 1: 0 relé 1 disattivato, 1 relé 1 attivato, 2 inverti stato relé 1;
• BYTE 2: 0 relé 2 disattivato, 1 relé 2 attivato, 2 inverti stato relé 2;
• BYTE 3: 0 relé 3 disattivato, 1 relé 3 attivato, 2 inverti stato relé 3;
• BYTE 4: 0 relé 4 disattivato, 1 relé 4 attivato, 2 inverti stato relé 4.
Il sistema dovrà inoltre prevedere un messaggio CAN di “status”, inviato ad intervalli regolari (ed impostabili), con questa forma di codifica:
• BYTE 1: 0 relé 1 disattivato, 1 relé 1 attivato;
• BYTE 2: 0 relé 2 disattivato, 1 relé 2 attivato;
• BYTE 3: 0 relé 3 disattivato, 1 relé 3 attivato;
• BYTE 4: 0 relé 4 disattivato, 1 relé 4 attivato;
• BYTE 5: Stato della tensione di alimentazione (0: Ok, 1: out of range).

Il sistema dovrà inoltre prevedere che i due LED di stato possano funzionare sia autonomamente (lampeggio alternato), sia controllati tramite il byte 5 del messaggio di controllo, secondo la seguente codifica:
• 00 entrambi i LED spenti,
• 10 LED1 acceso e LED2 spento,
• 01 LED1 spento e LED2 acceso,
• 11 entrambi i LED accesi.

Requisiti di configurazione
Il sistema dovrà inoltre prevedere tre messaggi CAN di configurazione, con le funzioni seguenti.
1) CAN_CONFIG_MSG_1: messaggio di configurazione per l’impostazione dell’indirizzo del messaggio CAN di controllo.
2) CAN_CONFIG_MSG_2: messaggio di configurazione per l’impostazione dell’indirizzo del messaggio CAN di status.
3) CAN_CONFIG_MSG_3: messaggio di configurazione per l’impostazione delle opzioni di sistema. Le opzioni disponibili saranno:
a. impostazione del periodo di invio del messaggio di stato;
b. impostazione del tipo di controllo per i due LED di stato;
c. impostazione del baud-rate CAN.

Tutte le impostazioni inviate tramite i messaggi di configurazione dovranno essere salvate in memoria non volatile e caricate durante la fase di start-up, in modo che il sistema mantenga la configurazione impostata anche se viene meno la tensione di alimentazione.

Progetto hardware della scheda

Veniamo adesso al progetto hardware della scheda, il cui schema a blocchi è riportato in Fig. 3. Come unità centrale del sistema si è scelto di utilizzare un PIC16F1829, un dispositivo mid-range prodotto dalla Microchip Technology. Il microcontrollore è stato selezionato in base ai requisiti, scegliendo il componente tramite il MAPS (Microchip Advanced Part Selector), un tool online disponibile sul sito della Microchip, che seleziona i dispositivi aventi un certo set minimo di caratteristiche, secondo i parametri specificati dall’utente nei campi di un’opportuna interfaccia grafica.

I criteri di ricerca da noi utilizzati sono stati:
• almeno 8k di memoria Flash;
• EEPROM interna;
• almeno una porta SPI;
• convertitore A/D;
• almeno 6 GPIO ed 1 canale analogico disponibili.

Fig. 3 Schema a blocchi della scheda hardware.

 

Chiaramente è stato scelto il componente meno costoso in grado di soddisfare tutti i requisiti: infatti un’oculata scelta prevede tra i parametri l’ottimizzazione dei costi. Il microcontrollore da noi scelto è il PIC16F1829, del quale in Fig. 4 è riportata la pin-out.

Fig. 4 Pinout del PIC16F1829. L’MCP2515 è interfacciato al microcontrollore principale tramite collegamento SPI.

 

L’interfaccia CAN del dispositivo è costituita dal CAN controller MCP2515, collegato al transceiver MCP2551 (compatibile CAN 2.0B).

Il controller CAN MCP2515 dispone di tre buffer di trasmissione e due buffer di ricezione, con un totale di sei filtri e due maschere hardware, e risulta quindi più che sufficientemente dimensionato per il compito da svolgere (trasmissione di un singolo messaggio e ricezione di un totale di quattro, tra messaggi standard e di configurazione).

In Fig. 5 è riportato lo schema a blocchi dell’MCP2515, ed in Fig. 6 lo schema a blocchi del transceiver MCP2551.

La tensione di alimentazione della scheda è di 5 V, da ottenersi tramite un regolatore lineare di tipo serie. Il circuito di alimentazione prevede un’apposita interfaccia per consentire la lettura della tensione di ingresso da parte della MCU, a fini diagnostici.

Fig. 5 Schema a blocchi dell’MCP2515.

Fig. 6 Schema a blocchi dell’MCP2551.

 

Per il controllo dei relé si è deciso di utilizzare un ULN2003A, un array di transistor a Darlington molto utilizzato in applicazioni di controllo motori e di potenza in generale.
Infine sono stati previsti i quattro LED per segnalare lo stato dei relé e i due LED di stato previsti in fase di definizione dei requisiti.

Passiamo adesso alla fase di realizzazione hardware della scheda. Per il progetto hardware è stato utilizzato il tool EDA (Electronic Design Automatico) KiCad, uno strumento open source molto completo, che permette di realizzare sia schemi elettrici, sia layout e che fornisce anche i relativi file necessari alla costruzione del circuito stampato con i processi industriali correnti.

Lo schema elettrico del dispositivo è riportato in Fig. 7; analizziamone i dettagli in modo da comprendere le scelte implementative effettuate.

Fig. 7 Schema elettrico della scheda.

 

Partiamo dalla sezione relativa al microcontrollore; il clock del PIC16F1829 è stato ottenuto tramite un oscillatore al quarzo da 4 MHz, ed il microcontrollore è stato dotato di circuito di reset hardware, tramite un pulsante ed una resistenza di pull-up connessi al pin MCLR.

Infine sono stati inseriti i due LED di stato ed il classico condensatore di bypass da 100 nF. Passiamo all’interfaccia CAN, costituita da controller MCP2515 e dal transceiver MCP2551. L’MCP2515 è stato temporizzato con un quarzo da 16 MHz ed è collegato al microcontrollore tramite interfaccia SPI.

Oltre alle linee tipiche dell’SPI (SDI, SDO ed SCK) è stata prevista anche una linea di CS ed una linea di Interrupt (INT); quest’ultima non è strettamente necessaria, ma può essere utile se si decide di gestire in interrupt l’interfaccia CAN. Il transceiver invece è stato collegato alle linee Tx ed Rx del controller dal un lato ed al connettore CAN dall’altro.

Infine è stata prevista la terminazione a 120 Ω (attivata tramite un jumper a 2 poli) ed i due LED per l’indicazione del traffico sul bus.

Passiamo adesso al regolatore di tensione: la sezione corrispondente è stata realizzata tramite un LM340, collegato alla classica rete di condensatori anti-oscillazione (330 nF e 100 nF), oltre ad altri due condensatori da 47 µF posti da entrambi i lati del circuito, che fungono da serbatoi di carica. Nella sezione d’ingresso del regolatore è stato inoltre inserito un partitore resistivo con rapporto 1/3, collegato all’ingresso analogico An0 del microcontrollore, in modo da poter monitorare la tensione di alimentazione primaria.

Infine passiamo all’analisi del circuito di controllo dei relé. Questo circuito è stato realizzato tramite un ULN2003a, un array di 7 transistor in configurazione Darlington. Gli ingressi dei primi quattro Darlington sono stati collegati ai primi quattro pin della porta C (RC0:RC3) e le relative uscite sono utilizzate per eccitare le bobine dei quattro relé. Infine, sono stati connessi quattro LED sulla sezione di ingresso, in modo da avere un’indicazione visiva immediata sullo stato di ogni singolo relé.

In Fig. 8 è riportato uno screenshot del progetto del PCB, mentre in Fig. 9 è possibile osservare il render 3D della scheda; entrambi sono stati generati da KiCad.

Fig. 9 Render 3D della scheda slave.

 

Mappa messaggi CAN

Analizziamo adesso la mappa messaggi CAN del sistema. La mappa messaggi è un documento che descrive il contenuto informativo dei messaggi di un sistema basato su una rete CAN. Tale documento è indispensabile per decodificare correttamente i vari “segnali” contenuti all’interno dei messaggi.

Messaggio di controllo
In Tabella 2 è riportato il formato del messaggio di controllo. Questo messaggio permette di controllare lo stato dei quattro relé tramite i primi quattro byte (Byte0:Byte3), e lo stato dei due LED tramite il Byte 4.
I restanti tre byte non sono utilizzati e restano disponibili per utilizzi futuri. L’indirizzo del messaggio è impostabile tramite il messaggio di configurazione 1, ed una volta impostato viene memorizzato in maniera permanente all’interno della memoria EEPROM del microcontrollore.

Tabella 2 Messaggio di controllo.

Messaggio di stato
Nella Tabella 3 è riportato il formato del messaggio di stato. Questo messaggio è utilizzato dalla scheda per fornire indicazioni sullo stato delle uscite (Byte0:Byte3) e sullo stato della tensione di alimentazione (Byte 4:Ok/Out of range). L’indirizzo del messaggio può essere impostato tramite il messaggio di configurazione 2; una volta impostato, viene memorizzato in maniera permanente all’interno della memoria EEPROM del microcontrollore.

Tabella 3 Messaggio di stato.

Messaggi di configurazione
In Tabella 4 sono riportati i formati dei messaggi di configurazione. Come abbiamo visto, tramite questi messaggi è possibile impostare l’indirizzo del messaggio di controllo e del messaggio di stato (messaggi 1 e 2) ed una serie di opzioni di funzionamento del microcontrollore (messaggio 3) , tra cui periodo di invio del messaggio di stato sulla rete (in multipli di 10ms), modalità di funzionamento dei LEDs di stato e baud rate dell’interfaccia CAN.

Tabella 4 Messaggi di configurazione. 4a – Messaggio di configurazione 1. 4b Messaggio di configurazione 2. 4c – Messaggio di configurazione 3.

Piano di montaggio

Elenco Componenti:

C1, C2, C7: 100 nF ceramico (0805)
C3, C5: 22 pF ceramico (0805)
C4, C6: 27 pF ceramico (0805)
C8: 47 µF 25 VL elettrolitico
C9: 330 nF ceramico (1206)
C10: 100 nF ceramico (0805)
C11: 47 µF 25 VL elettrolitico
D1÷D4: GF1M (DO214)
LD1, LD3: LED giallo (1206)
LD2, LD4÷LD8: LED rosso (1206)
LD9: LED verde (1206)
R1: 4,7 kohm (0805)
R2: 560 om (0805)
R3: 10 kohm (0805)
R4: 120 ohm (0805)
R5÷R12: 560 ohm (0805)
R13: 100 kohm (0805)
R14: 220 kohm (0805)
U1: MCP2515-E/SO 
U2: PIC16F1829-I/SO 
U3: MCP2551-E/SN 
U4: ULN2003AFWG 
U5: LM340MP-5.0 
X1: Quarzo 16 MHz
(HC49/US)
X2: Quarzo 4 MHz (HC49/US)
RL1÷RL4: Relé miniatura 5V
SW1: Microswitch

Varie:
- Plug alimentazione
- Morsetto 2 poli (2 pz.)
- Morsetto 3 poli (4 pz.)
- Strip maschio 2 poli
- Strip maschio 6 poli
- Jumper
- Circuito stampato

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.

Menu