Category Archives: PROGETTI CAN-BUS

CAN-ISO: CAN-BUS isolato galvanicamente (ARDUINO)

Unico prodotto “isolato galvanicamente”, professionale sul mercato mondiale per Arduino e/o similari!!

CAN-ISO è uno shield CAN-BUS (isolato galvanicamente) e permette di interfacciare una scheda Arduino o similare con propri dispositivi e/o commerciali, quali centraline, condizionatori, BMS (sistemi di ricarica), ecc che utilizzano il bus CAN.

Il costo di CAN-ISO (Made in Italy) è di 35 euro (solo shield).

 

Per informazioni o altro, e-mail: rubinolab(at)gmail dot com

 

E’ uno shield “professionale” completo di tutte le protezioni hardware con pin-out standard CAN su DB-9 facile da utilizzare.

Perché sceglierla rispetto altri prodotti? Principalmente poiché è isolata galvanicamente, di qualità, dalle alte prestazioni, riconfigurabile.

Ma l’isolamento galvanico a cosa serve? Per operare in sicurezza visto che solitamente si lavora su linee CAN con diversi dispositivi collegati. Nel caso di malfunzionamento di un dispositivo CAN (non isolato) per esempio guasto all’alimentatore o dispersioni di tensione che possono verificarsi in un ambiente di lavoro per umidità o pioggia è possibile che sulla linea CAN ci sia una tensione pericolosa per l’utente. In generale in base alla norma tecnica IEC 60479-1 la soglia di tensione minima considerata pericolosa per una persona è di 50Vac (tensione alternata a 50Hz) e 120Vdc (tensione continua). Gli effetti più frequenti e più importanti che la corrente elettrica produce sul corpo umano sono fondamentalmente quattro e bastano decine di milliampere per trovarsi in una delle condizioni: Tetanizzazione (>10-15mA), Arresto della respirazione (20-30mA), Fibrillazione ventricolare (70-100mA), Ustioni (>100mA).

Dove si utilizza? Si può utilizzare in moltissimi campi, per connettere più dispositivi con soli 2 fili twistati (consiglio di utilizzare anche uno schermo). E’ un sistema Real-Time, alla velocità di 1Mbit/s è possibile connettere linee di 40metri, mentre a 10kbit/s linee fino a 6 chilometri.

Riporto alcuni campi di utilizzo:

  • Automazione Industriale, Controllo, Sensori, Sistemi di comando a distanza
  • OBD II (On Board Diagnostics) Automotive
  • Industria 4.0 internet of things
  • Automazione di edifici e controllo del clima (HVAC)
  • Sistemi di sicurezza
  • Mezzi di trasporto
  • Sistemi medicali
  • Sistemi di telecomunicazioni
  • Standards CAN Bus quali: CANopen, DeviceNet, NMEA2000, ARINC825, ISO11783, CAN Kingdom, CANaerospace

Inoltre CAN-ISO è un progetto OPEN Software per i Makers !!!

In questa pagina sono riportati:

Grazie al supporto della community, questa pagina raccoglierà anche i migliori progetti di Makers, dando alla comunità dei Makers il miglior archivio per i loro progetti sviluppati con questo hardware.

Declinazione di responsabilità: RubinoLAB non può essere considerato responsabile per l’uso improprio del progetto.

Descrizione Tecnica

CAN-ISO è uno shield isolato galvanicamente per CAN-BUS, con protezioni e filtri su can-bus per board Arduino o similari.

In combinazione con una board Arduino è un potente strumento per l’invio e la ricezione di comandi, test e analisi delle reti CAN-BUS.
CAN-ISO può essere alimentata da una board Arduino attraverso la USB oppure da una alimentazione esterna a 12V sul connettore DB-9 consentendo di avere una board “standalone”. La scheda sarà sempre isolata sia se alimentata da Arduino che dal connettore DB-9.

Caratteristiche

  • Completamente conforme con le specifiche CAN 2.0B Bosch
  • ISO 11898-2 (CAN alta velocità) interfaccia fisica
  • CAN baud rate configurabile da software fino a 1Mbps
  • 1000Vrms isolamento galvanico tra CAN-BUS e board Arduino
  • Protezione Fault Bus tra –27 V e 40 V
  • Protezione ESD
  • Filtro CAN di modo comune (rumore di linea)
  • Terminatore di linea CAN da 120 ohm (configurabile)
  • MCP2515 @16MHz
  • Circuit Operating Voltage: 5V default; 3.3V su richiesta prima dell’acquisto
  • Alimentazione isolata tra la board Arduino e il CAN-BUS (il dispositivo previene le il rumore delle correnti parassite sul bus dati o altri circuiti che possono entrare sul piano di massa e interferire o danneggiare i circuiti sensibili)
  • Pienamente compatibile con i protocolli ad alto livello quali: CANopen, DeviceNet, NMEA2000, ARINC825, ISO11783, CAN Kingdom, CANaerospace
  • Connettore industriale standard DB-9 (possibilità di alimentare da una sorgente esterna a 12V dc)
  • Protezione inversione di polarità da sorgente esterna su DB-9
  • Indicatori LED

Connessione

Riportiamo le connessioni dello shield “CAN-ISO”. Le etichette in blu sono utilizzate da CAN-ISO.

Il clock della board per il chip MCP2515 è 16.00 MHz.

Note :

  1. Lo shield CAN-ISO ha a bordo un terminatore CAN bus che è possibile inserire/disinserire mediante pinhead
  2. Il CAN bus deve essere terminato con un solo terminatore a 120 Ohm per cavi piccoli di lunghezza (< 2m)
  3. Per cavi CAN networks (>10m) & ambienti rumorosi usa cavi con schermo, con fili twistati.

Compatibilità

CAN-ISO Shield è utilizzabile sulle board che lavorano con segnali a 5V (default), fornibile per segnali a 3.3V su richiesta prima dell’acquisto:

Nome dispositivo Compatibilità Note
Arduino UNO (ATmega328) 100% testato
Arduino Mega (ATmega1280/2560) 100% da testare
Arduino Leonardo (ATmega32U4) 100% da testare

Test

Diversi test di base sono stati condotti per garantire che lo shield lavori in modo appropriato. I tests includono la misurazione della frequenza di clock, la potenza assorbita, le caratteristiche del filtro EMI.

Inoltre sono stati condotti altri specifici test con strumenti dedicati o hardware personalizzato. Questi test includono:

ISOLAMENTO fino a 1000 V Misuratore di isolamento:

NORMA

L.Nr.1806 30303

ERRORE DI COMUNICAZIONE più di 10 ore continue di comunicazione due shields sono stati utilizzati per un test in loopback

Lo Shield CAN-ISO ha superato con successo tutti i test menzionati!

On-Board Diagnostics (OBD)

Interfacciare OBD-II con DB9

Questo è la connessione standard per interfacciarsi alla OBD-II per tutti i veicoli in circolazione dal 2008. Per quelli più vecchi o per le auto FORD la piedinatura OBD-II potrebbe variare e dipende dal costruttore auto.

Codice di esempio RubinoLAB

Il primo esempio di codice si chiama “CANINO”. Questo codice trasforma l’hardware Arduino + CAN-ISO in un bridge tra la porta seriale USB e il CAN BUS. I pacchetti sono facilmente leggibili con un programma “serial terminal”, ciò consente di debaggare facilmente le linee o creare una facile interfaccia grafica con LabVIEW, Python, Processing ecc.

Per l’esempio: Configurazione del codice e test CAN-ISO

Un video YouTube dove CAN-ISO dialoga con una centralina CAN BUS, utilizzando il codice “CANINO” e interfaccia grafica “LabView”:

Per l’utilizzo con interfaccia grafica “professionale” vai alla pagina: CANHacker

 Maker

Per condividere il tuo progetto realizzato con CAN-ISO, invia una e-mail a: info(at)rubinolab dot com e proponi la tua idea.

Se la tua idea sarà considerata interessante, sarà ospitata nel sito web RubinoLAB o collegata alla nostra pagina.

Dove acquistare

Abbiamo realizzato una prima serie per soddisfare le nostre esigenze e quelle di molti makers, fino ad esaurimento scorte. Nel caso ci sia ulteriore richiesta ci sarà una ulteriore produzione.

Il costo della scheda (Made in Italy) è di 70 euro ora in offerta a 35 euro.

Per informazioni o altro, e-mail: rubinolab(at)gmail dot com


Confronto tra convertitori USB – CAN BUS isolati galvanicamente

Category : PROGETTI CAN-BUS

In quest’articolo confronteremo il convertitore CAN-ISO (di RubinoLAB) con vari prodotti USB-CAN BUS commerciali (isolati galvanicamente).
Poiché sul mercato non esistono shields CAN bus “isolati galvanicamente” per Arduino o piattaforme simili, il team RubinoLab ha confrontato CAN-ISO con le migliori interfacce sul mercato che consentono di utilizzare interfacce proprietarie e permettono la personalizzazione.

Confrontando i dati risulta che l’interfaccia CAN-ISO (di RubinoLAB) è l’unica soluzione con “software aperto”, tutti gli altri hanno limitazioni sulle piattaforme di utilizzo (tipicamente OS Windows), firmware, e uso del software proprietario.
Ciò permette l’utilizzo nel settore industriale, e automobilistico a basso costo.
CAN-ISO ha due ingressi di alimentazione (ma necessita per funzionare di una sola alimentazione): USB e pin su connettore CAN. Tipicamente via USB per un utilizzo come sniffer connesso al PC, dal pin +12V su connettore CAN per realizzare un dispositivo stand-alone con alimentazione da remoto (non connesso al pc). Le due alimentazioni garantiscono isolamento galvanico e alimentazione dello shield CAN-ISO e della board Arduino (o compatibile).
CAN-ISO ha molti pin liberi presenti sullo shield e permette di collegare display, pulsanti, potenziometri, sensori, ecc. per realizzare nuovi dispositivi con connettività bidirezionale CAN-BUS “isolata galvanicamente”.
Ottimo per realizzare un banco di test CAN per centraline con interfacce realizzate ad hoc.

Contattateci per farci conoscere le vostre opinioni, o proporci una vostra idea/progetto. Per scriverciinfo(at)rubinolab dot com

Per l’acquisto di CAN-ISO: LINK

Enjoy!


CAN-ISO con interfaccia grafica CANHacker

Category : PROGETTI CAN-BUS

In questa sezione vedremo come realizzare un “monitor CAN BUS di tipo universale isolato galvanicamente” utilizzando la piattaforma Arduino con lo shield CAN-ISO (RubinoLab) e l’interfaccia grafica CANHacker.

Un dispositivo professionale “completo” utilizzabile per tutti i protocolli CAN-BUS, da quello per settore automobilistico a quello industriale.

Per l’acquisto di CAN-ISO: LINK

Un dispositivo CAN che consente di scrivere/leggere su Canbus per eseguire operazioni di diagnostica, analisi sul traffico di rete, identificazione problemi di rete, ecc. Ad esempio:

Nel settore automotive: può essere utilizzato per leggere i codici di errore delle auto, moto, ecc. che utilizzano OBD-II oppure eseguire operazioni di “Canbus Reverse Engineering” monitorando lo scambio di dati CAN tra unità lato motore, o inviare comandi per resettare codici di errore, eseguire test a banco di singoli sottosistemi, ecc

Nella industria: con il monitoraggio della rete è possibile aiutare i gestori di una rete CAN a identificare se una rete funziona normalmente o è congestionata. Inoltre, possono essere identificati i colli di bottiglia all’interno di una rete per migliorare le prestazioni aggiornando l’infrastruttura.

Identificazione dei problemi: Come accennato in precedenza, oltre a leggere/scrivere su CAN è possibile identificare tutti i problemi relativi alla rete. Dalle informazioni acquisite via CAN è possibile identificare i pacchetti errati e/o identificare il nodo che non ha risposto alle richieste. Ciò facilita l’identificazione dei dispositivi difettosi all’interno della rete e offre la possibilità di intraprendere azioni correttive rapide.

Ecco di cosa hai bisogno

Compra l’hardware:

Download il software:

Ora siamo pronti per iniziare!

Caratteristiche

Prima dell’installazione, vediamo cosa sono i software “Arduino canbus monitor” e “CANHacker tool”.

Lo sketch “Arduino canbus monitor”, implementa il protocollo CAN ASCII/SLCAN compatibile con CAN232/CANUSB di Lawicel. Esso può essere usato per monitorare una gran parte di protocolli CAN. Note: Per velocità CAN che eccedono i 500kbps con una alta densità di dati sulla porta seriale di Arduino, la porta seriale può diventare un collo di bottiglia.

L’interfaccia grafica “CANHacker tool” di (Lawicel) si interfaccia a “Arduino canbus monitor”. Essa implementa una comunicazione CAN con:

  • invia & riceve Can Frames
  • supporta lo standard (11 bit) & esteso (29 bit) frames
  • supporta remote frames (RTR)
  • supporta filter ID (mask + code)
  • supporta can baudrates da 10Kbps fino a 1Mbps
  • supporta MCP2515 @ 16 MHZ

Ora vedremo passo passo come installare il software “Arduino canbus monitor”  e “CANHacker tool”.

Installazione

Dopo aver download “Arduino canbus monitor”:

  1. carica lo sketch “arduino-canbus-monitor.ino”
  2. Compilare e se non ci sono errori continua al punto 3. Se ci sono errori per mancanza delle librerie (“mcp_can.h” e “can-232.h”) zip il files in in una cartella (can-232.cpp, can-232.h, mcp_can.cpp, mcp_can.h, mcp_can_dfs.h) e poi da Arduino IDE: Sketch -> Include Library -> Add .ZIP Library. Riavvia Arduino IDE e vai al punto 1.
  3. Carica nella piattaforma Arduino
  4. Disconnetter e riconnettere Arduino su USB

Ora download “CANHackerV2.00.02.exe” e installa il software sulla piattaforma Windows. Dopo l’installazione, riavvia Windows. Ora siamo pronti.

Uso

Ora possiamo usare il nostro “sniffer” o “monitor canbus”.

  1. Connettere il dispositivo CAN (Arduino+CAN-ISO shield) al PC. Aspetta che Windows assegni un numero di porta seriale COM. Verifica il numero di porta seriale assegnata da Windows in “Gestione dispositivi”.
  2. Avvia il software CANHacker, e in “Setting” scegliere:
  • CAN Device: la porta COM assegnata a Arduino da windows
  • COM Baudrate: 115200 bits/s
  • CAN Baudrate: velocità della porta CAN

Fare clic sul pulsante “OK”, quindi su “Connect”. Divertiti! Monitora il tuo Can bus, salva i valori, invia messaggi, fai quello che può fare il tuo software di analisi/visualizzazione.

EXAMPLE 01

In questo test effettueremo un test di comunicazione Canbus tra due schede “Arduino UNO” con lo shield “CAN-ISO”.

Per il test occorrono:

(2) boards “ARDUINO UNO”
(2) Shields “CAN-ISO”
(1) cavo Canbus

Per utilizzare lo stesso PC per leggere/scrivere su Canbus, utilizzeremo un “terminale Windows” e come interfaccia grafica “CANHacker”.

Lo sketch per la prima scheda Arduino è “CANINO”, mentre nella seconda “Arduino canbus monitor”
Download CANINO
Download Arduino canbus monitor

Ora è possibile avviare i seguenti terminali dopo averli configurati:
CANHacker: configura la porta COM, la velocità CAN (per la board con Arduino canbus monitor);
CANINO: configura la porta COM, la velocità CAN (per la board con Canino);

Nella figura, per esempio, possiamo vedere l’invio della stringa @00A0102030405060708 dal “terminale seriale di Windows” via CAN all’interfaccia grafica “CANHacker”.

Conclusioni

Con questa soluzione avremo un completo tool, galvanicamente isolato per molteplici usi, a basso costo.

Contattateci per farci conoscere le vostre opinioni, o proporci una vostra idea/progetto. Per scriverciinfo(at)rubinolab dot com

Per l’acquisto di CAN-ISO: LINK

Enjoy!


CAN-ISO: Configurazione del codice e test

Category : PROGETTI CAN-BUS

In questa sezione vedremo come configurare il modulo RubinoLAB CAN-ISO su Arduino e come testarlo.

Per l’acquisto di CAN-ISO: LINK

Il protocollo implementato utilizza una comunicazione standard ASCII. Ciò rende il sistema compatibile con qualsiasi programma (Python, LabVIEW, MATLAB etc), semplice da adattare al proprio progetto.

Il primo passo da fare è installare la libreria MCP_CAN (se non l’avete già installata), nell’editor Arduino. Qui trovate il link della libreria:

https://github.com/coryjfowler/MCP_CAN_lib

Create un progetto con il codice esempio qui riportato o in alternativa scaricate il progetto allegato e scompattatelo nella vostra cartella di lavoro.

CANINO_v2 CANINO_V2.zip

Compilate e caricatelo nel modulo Arduino.

[pastacode lang=”cpp” manual=”%2F%2Frevisione%202%20del%2030%2F03%2F2018%2C%20con%20Arduino%201.8.5%0A%2F*%0A%20%20CAN%20BUS%20%2B%20ARDUINO%20–%3E%20CANINO%20interface%20%3A)%0A%20%20USB%20%3C–%3E%20CAN%20BUS%20interface%0A%20%20Author%3A%20Luigi%20Rubino%0A%0A%20%20Adesso%20accetta%203%20byte%20di%20indirizzo%0A%0A%20%20STRING%20EXAMPLE%3A%0A%20%20%4000A0102030405060708%5Cn%0A*%2F%0A%0A%23include%20%22mcp_can.h%22%0A%23include%20%3CSPI.h%3E%0A%0A%23define%20CAN0_INT%202%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20Set%20INT%20to%20pin%202%0AMCP_CAN%20CAN0(10)%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20Set%20CS%20to%20pin%2010%0A%0A%0A%2F%2F%20the%20cs%20pin%20of%20the%20version%20after%20v1.1%20is%20default%20to%20D9%0A%2F%2F%20v0.9b%20and%20v1.0%20is%20default%20D10%0A%2F%2F%20Can_Bus_shield-ISO-v1%20is%20default%20D10%0A%2F%2Fconst%20int%20SPI_CS_PIN%20%3D%2010%3B%0A%2F%2FMCP_CAN%20CAN(SPI_CS_PIN)%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20Set%20CS%20pin%0A%0Aunsigned%20char%20buf%5B8%5D%3B%0Aunsigned%20char%20canId%3B%0Along%20unsigned%20int%20rxId%3B%0A%0A%0A%23define%20LEN_STRING%2010%0A%0Aunsigned%20char%20ReceivedString%5BLEN_STRING%5D%3B%20%20%2F%2Fstringa%20ricezione%20carattere%20da%20USB%0A%0Aint%20inByte%20%3D%200%3B%20%20%20%20%20%20%20%20%20%2F%2F%20incoming%20serial%20byte%0A%0A%2F%2Fglobal%20var%0Aint%20%20digValue%2C%20sign%3D1%3B%0Achar%20rxpos%2C%20rxpos2%3B%20%20%20%20%20%20%20%20%20%20%2F%2Fper%20il%20parser%20seriale%0Aint%20address%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2Fcomando%20da%20eseguire%0Aint%20DT%3B%0A%0A%0Avoid%20setup()%20%7B%0A%20%20%2F%2F%20start%20serial%20port%20at%20115200%20bps%3A%0A%20%20Serial.begin(115200)%3B%20%2F%2Fprovare%20velocit%C3%A0%20115200%0A%20%20while%20(!Serial)%20%7B%0A%20%20%20%20%3B%20%2F%2F%20wait%20for%20serial%20port%20to%20connect.%20Needed%20for%20native%20USB%20port%20only%0A%20%20%7D%0A%20%0A%20%20%2F%2F%20Initialize%20MCP2515%20running%20at%2016MHz%20with%20a%20baudrate%20of%20500kb%2Fs%20and%20the%20masks%20and%20filters%20disabled.%0A%20%20if(CAN0.begin(MCP_ANY%2C%20CAN_500KBPS%2C%20MCP_16MHZ)%20%3D%3D%20CAN_OK)%0A%20%20%20%20Serial.println(%22MCP2515%20Initialized%20Successfully!%22)%3B%0A%20%20else%0A%20%20%20%20Serial.println(%22Error%20Initializing%20MCP2515…%22)%3B%0A%20%20%0A%20%20CAN0.setMode(MCP_NORMAL)%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20Set%20operation%20mode%20to%20normal%20so%20the%20MCP2515%20sends%20acks%20to%20received%20data.%0A%0A%20%20pinMode(CAN0_INT%2C%20INPUT)%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20Configuring%20pin%20for%20%2FINT%20input%0A%20%20%0A%20%20Serial.println(%22CANINO%20READY…%22)%3B%0A%7D%0A%0Avoid%20loop()%20%7B%0A%0A%20%20unsigned%20char%20len%20%3D%200%3B%0A%20%20%0A%20%20%2F%2F%20if%20we%20get%20a%20valid%20byte%2C%20read%20analog%20ins%3A%0A%20%20if%20(Serial.available()%20%3E%200)%20%7B%0A%20%20%20%20%2F%2F%20get%20incoming%20byte%3A%0A%20%20%20%20inByte%20%3D%20Serial.read()%3B%0A%20%20%20%20%2F%2FSerial.write(inByte)%3B%0A%20%20%20%20%2F%2F%20delay%2010ms%20to%20let%20the%20ADC%20recover%3A%0A%20%20%20%20%2F%2Fdelay(10)%3B%0A%20%20%20%20%0A%20%2F*%20Get%20the%20character%20received%20from%20the%20USART%20*%2F%0A%20%20if%20(inByte%3D%3D’%40′)%0A%20%20%20%7B%0A%20%20%20%20%20rxpos%20%20%20%20%20%3D%201%3B%0A%20%20%20%20%20digValue%20%20%3D%200%3B%0A%20%20%20%7D%0A%20%20else%0A%20%20%7B%0A%20%20%20%20%0A%2F%2F%20%20%20%20Serial.print(%22–%3E%22)%3B%0A%2F%2F%20%20%20%20Serial.print((int)%20rxpos)%3B%0A%2F%2F%20%20%20%20Serial.println()%3B%0A%20%20%20%20%0A%20%20switch(rxpos)%0A%20%20%7B%0A%20%20%20case%201%3A%0A%20%20%20%20%20%20address%20%20%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%202%3A%0A%20%20%20%20%20%20address%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20address%20%2B%3D%20hex2int(inByte)%3B%20%20%20%20%20%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%0A%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%0A%20%20%20case%203%3A%0A%20%20%20%20%20%20address%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20address%20%2B%3D%20hex2int(inByte)%3B%20%20%20%20%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%3D%20%200%3B%20%0A%0A%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%0A%20%20%20case%204%3A%20%20%20%2F%2Fbyte%201%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%205%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%206%3A%20%20%20%2F%2Fbyte%202%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%207%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%0A%20%20%20case%208%3A%20%20%20%2F%2Fbyte%203%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%209%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%2010%3A%20%20%20%2F%2Fbyte%204%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%2011%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%0A%20%20%20case%2012%3A%20%20%20%2F%2Fbyte%205%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%2013%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%2014%3A%20%20%20%2F%2Fbyte%206%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%2015%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%2016%3A%20%20%20%2F%2Fbyte%207%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%2017%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%0A%20%20%20case%2018%3A%20%20%20%2F%2Fbyte%208%0A%20%20%20%20%20%20DT%20%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20case%2019%3A%0A%20%20%20%20%20%20DT%20%20%20%3C%3C%3D4%3B%20%0A%20%20%20%20%20%20DT%20%2B%3D%20hex2int(inByte)%3B%0A%20%20%20%20%20%20ReceivedString%5Brxpos2%5D%20%3D%20DT%3B%0A%20%20%20%20%20%20rxpos%20%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20rxpos2%20%20%20%2B%3D%201%3B%0A%20%20%20%20%20%20break%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%0A%20%20%20case%2020%3A%20%2F%2Feseguo%20il%20comando%0A%20%20%20%20%20%20%20%20CAN0.sendMsgBuf(address%2C%200%2C%208%2C%20ReceivedString)%3B%0A%20%20%20%20%20%20%20%20%2F%2Fbyte%20sndStat%20%3D%20CAN0.sendMsgBuf(0x100%2C%200%2C%208%2C%20data)%3B%0A%20%20%20%20%2F%2Fdelay(100)%3B%20%20%20%20%20%20%20%20%20%20%2F%2F%20send%20data%20per%20100ms%0A%20%20%20%20%20%20rxpos%20%20%20%20%3D%200%3B%0A%0A%2F%2Fda%20rinuovere%0A%2F%2F%20%20%20%20%20%20Serial.print(address%2C%20HEX)%3B%0A%2F%2F%20%20%20%20%20%20for%20(int%20kk%3D0%3Bkk%3C%3D7%3B%20kk%2B%2B)%0A%2F%2F%20%20%20%20%20%20%7B%0A%2F%2F%20%20%20%20%20%20%20%20Serial.print(%22%20%22)%3B%0A%2F%2F%20%20%20%20%20%20%20%20Serial.print(ReceivedString%5Bkk%5D%2C%20HEX)%3B%0A%2F%2F%20%20%20%20%20%20%20%20%0A%2F%2F%20%20%20%20%20%20%20%20%7D%0A%2F%2F%20%20%20%20%20%20%20%20Serial.println()%3B%0A%20%20%20%20break%3B%0A%20%20%20%20default%3A%20%0A%20%20%20%20%20%20%20%20rxpos%20%20%20%20%3D%200%3B%0A%20%20%20%20%20%20%20%20break%3B%0A%20%20%7D%0A%20%20%7D%20%20%20%20%2F%2Ffine%20gestione%20acquisizione%20%0A%20%20%7D%20%20%2F%2Ffine%20gestione%20seriale%0A%0A%20%20%2F%2F%20————————————————–%0A%20%20%2F%2Fgestione%20CAN%20BUS%0A%20%20if(!digitalRead(CAN0_INT))%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2F%20If%20CAN0_INT%20pin%20is%20low%2C%20read%20receive%20buffer%0A%20%20%7B%0A%20%20%20%20CAN0.readMsgBuf(%26rxId%2C%20%26len%2C%20buf)%3B%20%20%20%20%20%20%2F%2F%20Read%20data%3A%20len%20%3D%20data%20length%2C%20buf%20%3D%20data%20byte(s)%0A%0A%20%20%20%20canId%20%3D%20(unsigned%20char)%20rxId%3B%0A%2F%2F%20%20%20%20canId%20%3D%20CAN0.getCanId()%3B%20%20%20%20%20%20%20%2F%2F%20indirizzo%20risposta%0A%20%20%20%20%20%20%20%20%0A%20%2F%2F%20%20%20%20%20%20%20Serial.println(%22—————————–%22)%3B%0A%20%2F%2F%20%20%20%20%20%20%20Serial.print(%22Get%20data%20from%20ID%3A%20%22)%3B%0A%20%20%20%20%20%20%20%20Serial.print(%22%40%22)%3B%0A%20%20%20%20%20%20%20%20Serial.print(canId%2C%20HEX)%3B%0A%0A%20%20%20%20%20%20%20%20for(int%20i%20%3D%200%3B%20i%3Clen%3B%20i%2B%2B)%20%20%20%20%2F%2F%20print%20the%20data%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20if%20(buf%5Bi%5D%3C%3D15)%20%20%7B%20%20Serial.print(‘0’)%3B%7D%0A%20%20%20%20%20%20%20%20%20%20%20%20Serial.print(buf%5Bi%5D%2C%20HEX)%3B%0A%20%20%20%20%20%20%20%20%7D%0A%20%20%20%20%20%20%20%20Serial.println()%3B%0A%20%20%20%20%7D%0A%20%0A%7D%0A%0Avoid%20establishContact()%20%7B%0A%20%20while%20(Serial.available()%20%3C%3D%200)%20%7B%0A%20%20%20%20Serial.print(‘A’)%3B%20%20%20%2F%2F%20send%20a%20capital%20A%0A%20%20%20%20delay(300)%3B%0A%20%20%7D%0A%7D%0A%0Aint%20hex2int%20(char%20c)%0A%7B%0A%20%20if%20(c%20%3E%3D%20’0’%20%26%26%20c%20%3C%3D%20’9′)%0A%20%20%7B%0A%20%20%20%20%20%20return%20(int)%20(c-‘0′)%3B%0A%20%20%7D%0A%20%20else%0A%20%20%7B%0A%20%20%20%20%20%20return%20(int)%20((c%20-%20’A’)%2B10)%3B%0A%20%20%7D%0A%7D%0A” message=”CANINO library” highlight=”” provider=”manual”/]

Adesso siamo pronti per iniziare!

Test del codice (Trasmissione)

Una tipica connessione CAN-Bus nel campo dell’automazione industriale è quella mostrata in figura, dove c’è un master e vari multi slave. Nel master/slave ogni dispositivo o processo (chiamato master) controlla uno o più dispositivi o processi (chiamati slaves). Una volta che la connessione master/slave si è stabilita, la direzione del controllo è sempre dal master allo slave(s).

Per il test del codice è necessario creare una micro-rete CAN-BUS, ad esempio utilizzando due interfacce CAN-BUS Arduino. Per l’esempio qui riportato abbiamo utilizzato una interfacca CAN-BUS Arduino connessa a una interfaccia commerciale.

NB. L’interfaccia è configurata per una velocità di comunicazione CAN di 500kbps. Cambiate questo valore nel codice per una velocità diversa. Gli indirizzi sono configurati ad 11bit

Aprite il terminale seriale dall’editor Arduino e configuratela per una velocità di 115200 baud, nessun controllo di flusso.

Digitate la seguente stringa: @00A0102030405060708 e premete invio.

La stringa è composta di tre parti:

  • @ (Attention) avverte l’interfaccia che una nuova stringa sta arrivando e che deve riallinearsi per un nuovo invio
  • 00A indirizzo di destinazione
  • 01 02 03 04 05 06 07 08 sono gli 8 byte da inviare in formato esadecimale. Ricordiamo che un byte esadecimale è compreso tra 00 e FF.

Se tutte le operazioni sono state effettuate correttamente, l’altra interfaccia riceverà all’indirizzo 0A i byte come nella sequenza mostrata.

Test del codice (Ricezione)

Per il test del codice in ricezione, si effettua l’operazione inversa.

Inviamo all’indirizzo 0B, la stringa 08 07 06 05 04 03 02 01

In ricezione avremo una stringa ASCII formattata in modo analogo alla trasmissione, come di seguito riportato:

Esempio (Canino+LabView)

Un video YouTube dove CAN-ISO dialoga con una centralina industriale con CAN BUS, utilizzando il codice “CANINO” e interfaccia grafica “LabView”:

Conclusioni

Adesso che il codice è testato e siamo in grado di trasmettere/ricevere un pacchetto generico, opportunamente formattato, il prossimo step è utilizzare l’interfaccia con un programma. Nei prossimi tutorial vedremo come utilizzare l’interfaccia con Python, LabVIEW, MATLAB, bash shell ed altri.

Contattateci per farci conoscere le vostre opinioni, o proporci una vostra idea/progetto. Per scriverciinfo(at)rubinolab dot com

Per l’acquisto di CAN-ISO: LINK

Enjoy!


Presa EOBD (European On Board Diagnostic)

Category : PROGETTI CAN-BUS

Con il termine OBD o OBD-II, nel contesto automobilistico, motociclistico o motoristico in generale, è un termine generico che si riferisce alla capacità di autodiagnosi e segnalazione di errori/guasti di un veicolo. Tecnicamente il suo nome è J1962 e in europa è chiamato con il termine EOBD.

Il protocollo di comunicazione utilizzato per la OBD (On Board Diagnostics) è il CAN (Controller Area Network) che può dialogare con il “Body computer” al quale sono connessi tutti i dispositivi di un veicolo.

E’  fondamentale distinguere i ruoli dei due protocolli CAN e OBD-II.

Il protocollo CAN (controller area network) è un bus seriale di comunicazione digitale di tipo “broadcast”: permette il controllo real-time distribuito con un livello di sicurezza molto elevato. E’ stato introdotto dalla Bosch nei primi anni ‘80 per applicazioni automobilistiche, per consentire cioè la comunicazione fra i dispositivi elettronici intelligenti montati su un autoveicolo, ma ora si è diffuso in molti settori dell’industria. Ma affinché ci sia comunicazione tra i dispositivi CAN occorre che i dati ricevuti siano identificati univocamente e di conseguenza è stato introdotto l’OBD. Il protocollo OBD-II, molto più dettagliato del CAN, è nato espressamente come standard per i mezzi di trasporto ed è diventato obbligatorio in America nei veicoli prodotti a partire dal 1996. La versione europea di questo standard si chiama EOBD, esso è sostanzialmente identico all’OBD-II ed è obbligatorio dal 2001.

L’OBD-II non definisce solo lo standard di comunicazione, ma anche il connettore che deve essere presente nell’abitacolo del veicolo per il collegamento degli strumenti OBD-II compatibili. Tale connettore è sostanzialmente una porta di collegamento al bus CAN (o altro bus presente sul veicolo). Quando a questo connettore viene collegato a uno strumento con interfaccia OBD-II esso viene praticamente collegato al bus CAN ed è in grado di fare due cose:

  • “lettura” in modo passivo di tutti i messaggi che le centraline inviano sul bus e trasmetterli al computer (o altro dispositivo) dell’utente.
  • “scrittura” in modo attivo con le centraline, richiedendo dei dati e poi trasmettere al computer (o altro dispositivo) le risposte ricevute.

Come tutti i sistemi attivi, è possibile inviare comandi per modificare i parametri di funzionamento è consigliabile quindi limitarsi ad inviare i messaggi di cui si conosce l’effetto, perché messaggi diversi potrebbero alterare il funzionamento dell’auto e ciò può costituire un pericolo.

Il connettore OBD-II prevede anche una linea che fornisce energia al dispositivo collegato. È importante sapere che il connettore in molti veicoli fornisce sempre energia, anche quando è spento e uno strumento di diagnostica sempre collegato al veicolo (anche a motore spento) potrebbe far scaricare la batteria poiché mantiene sempre attive le centraline che non vanno in Energy Saver. Per questi motivi è consigliato scollegare dopo ogni utilizzo il connettore di diagnostica per preservare la carica della batteria del veicolo.

OBD-II

Lo standard OBD-II definisce inoltre alcuni comandi per il controllo dell’output, le modalità di autocontrollo e per l’azzeramento della memoria KAM (Keep Alive Memory).

Il connettore OBD-II è identico per tutti i modelli ma esistono cinque differenti protocolli di comunicazione:

  • VPW (Variable pulse width): General Motors
  • PWM (Pulse-width modulation): Ford
  • ISO 9141: Chrysler in Asia ed Europa
  • ISO 14230 KWP2000 (Keyword Protocol 2000 su linea K)
  • ISO 15765 (tramite linea CAN, come SAE-J2284)

Inoltre fornisce le informazioni su tutti i parametri e gli errori rilevanti ai fini delle emissioni inquinanti:

  • Codici dei parametri (RLI):
  • Velocità
  • Giri al minuto
  • Codici degli errori (DTC):
  • Sensore dell’ossigeno

La lettura dei componenti di errore è standardizzata, quindi qualsiasi officina anche non munita dello strumento ufficiale della casa, deve poter leggere gli errori OBD.

Note: Per i motori benzina ante 2001, anziché di OBD-II si parla di OBD-I, cioè una diagnosi a bordo relativa ai soli errori elettrici.

La normativa EOBD European On Board Diagnostics (European On Board Diagnostics) è l’equivalente europeo dell’OBD-II ed è stata introdotta per i motori a benzina nel 2001 assieme al livello di emissioni Euro 3 con la direttiva 98/69/CE[1].

La EOBD si applica a tutte le autovetture di categoria M1 (con non più di 8 posti a sedere e un peso lordo del veicolo fino a 2.500 kg) immatricolate per la prima volta all’interno degli Stati membri dell’UE a partire dal 1º gennaio 2001 per le autovetture con motore a benzina e dal 1º gennaio 2004 per le autovetture con motore a gasolio. Per i modelli di nuova introduzione, le date di applicazione della normativa sono state anticipate di un anno: 1º gennaio 2000 per le autovetture a benzina e 1º gennaio 2003 per le autovetture a gasolio.

Per le autovetture con un peso lordo del veicolo superiore a 2500 kg e per i veicoli commerciali leggeri, le date di applicazione della normativa sono partite dal 1º gennaio 2002 per i modelli a benzina, e dal 1º gennaio 2007 per i modelli a gasolio.

Nota: Se nella presa   EOBD2 è presente il contatto del pin 15, è possibile eseguire la procedura per la lettura dei codici errori.
Collegare il pin 15 (se presente) con  il  pin 5  di massa e  tramite la  spia diagnosi e la lista codici errori identificare il codice errore in memoria.

Su alcune autovetture il codice lampeggio è disponibile sul pin 13.

EOBD-II – Codici Guasto

I codici di guasto EOBD European On Board Diagnostics sono composti da cinque caratteri: una lettera, seguita da quattro numeri.

La lettera si riferisce al sistema che fa riferimento interrogato (es.. Pxxxx rimanda al sistema di propulsione) mentre se il carattere successivo è un 0 indica la conformità allo standard EOBD European On Board Diagnostics, se è un numero diverso rientra nella tabella codici proprietari del costruttore e può variare a seconda del sistema diagnosticato. Il terzo carattere fa riferimento ad un sottosistema, ad es:

  • P00xx – Misurazione carburante e aspirazione aria, controllo emissioni ausiliarie.
  • P01xx – Misurazione carburante e aspirazione aria
  • P02xx – Misurazione carburante e aspirazione aria (sistema di iniezione).
  • P03xx – Controllo iniezione e mancate accensioni.
  • P04xx – Controllo emissioni ausiliarie.
  • P05xx – Controllo velocità veicolo e sistema di regolazione minimo motore.
  • P06xx – Controllo sistema di comunicazione centralina.
  • P07xx – Controllo sistema di trasmissione.
  • P08xx – Controllo sistema di trasmissione.

Per la tabella completa dei codici: OBD II Standard Fault Codes

Adesso prendiamo la CAN-BUS ISO e prepariamo il cavo di collegamento per la lettura dei valori su EOBD!

Enjoy!