Author Archives: admin

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!


Clone Arduino & driver chip CH340, CH340G, CH341

Tags :

Category : RISORSE UTILI

Il chip CH340 /CH341 viene utilizzato da molte schede compatibili Arduino per fornire la connettività USB.

Molti sistemi operativi non riconoscono questi chip in modo nativo perché mancano i driver e di conseguenza abbiamo un errore dovuto alla assenza del driver.

La mancanza di questo driver non ci consente di comunicare con le piattaforme hardware e utilizzare il software di sviluppo Arduino.

Nessun panico, l’installazione del driver è molto semplice!

Dal sito web ufficiale del produttore (cinese) occorre scaricare il driver.

Una volta eseguita la decompressione del pacchetto, è possibile procedere con l’aggiornamento del driver per il dispositivo CH340/CH341 o equivalente (download solo il driver per il proprio sistema operativo):

 

WINDOWS 32/64bit (versione: 3.4 – 2016/09/27)

I driver nel sistema operativo Windows sono mancanti, è necessario scaricarli e installarli.

(WINDOWS 32/64bit) for Windows 10/8.1/8/7/VISTA/XP/2000/ME/98 & SERVER 2016/2012/2008/2003

 

LINUX 32/64bit (version: 1.5 – 2018/03/18)

I driver sono integrati in diverse distribuzioni Linux. Se il dispositivo non è riconosciuto, scaricare il driver Linux CH340/CH341.

(LINUX 32/64bit)

 

MAC OS 32/64bit (version: 1.5 – 2018/07/05)

Questo driver è per MacOS Sierra / High Sierra. Non installare i driver per Mojave, perché sembra che le ultime versioni siano dotate del supporto CH340/CH341.

(MAC OS 32/64bit) for MacOS Sierra/High Sierra

Installatione
• Disconnettere ogni dispositivo CH34*.
• Rimuovere i vecchi drivers se presenti:
• sudo kext unload /Library/Extensions/usbserial.kext
• sudo kext unload /System/Library/Extensions/usb.kext
• Rimuovi i vecchi driver digitando i seguenti comandi (dipende dalla vostra installazione):
• sudo rm -rf /System/Library/Extensions/usb.kext
• sudo rm -rf /Library/Extensions/usbserial.kext
• Doppio click su CH34x_Install_V1.5.pkg file e installare (non necessita di riavvio)
• Invece di riavviare, dovete forzare l’uscita dall’installere dopo che la procedura è completa.
• Carica il nuovo driver:
• sudo kextload /Library/Extensions/usbserial.kext
• Connettere il dispositivo. Esso dovrebbe comparire sotto la directory /dev . Esempio:
• /dev/cu.wchusbserial1410
• /dev/cu.wchusbserial1420

 

ANDROID (version: 1.5 – 2018/03/18)

Android 3.1 – USB Host, root, apk, lib, (Java Driver), App Demo, (USB UART Demo SDK)

 

Enjoy!


RICARICA SENZA FILI PER BATTERIE EBIKE

Ricarica senza fili per batterie Ebike

In questa pagina RubinoLab.com presenta diverse foto di un prototipo e prove sperimentali di un caricabatterie senza fili per E-bike da 300 W, realizzato per attività di ricerca.

Per questo progetto, sono stati scritti diversi documenti scientifici sviluppando un modello matematico e conducendo analisi delle prestazioni per determinare la funzione di trasferimento della tensione, la massima capacità di trasferimento di potenza, l’efficienza i per diversi gap d’aria (1 -3 cm) con vari disallineamenti (0,5-1,5 cm)

La frequenza di risonanza di questo circuito per la ricarica wireless delle batterie è di 40kHz.
Per ottenere la massima efficienza e il massimo trasferimento di potenza, occorre lavorare alla frequenza di risonanza.
Per valutare la correttezza dei parametri di tutto il circuito è stata realizzata una interfaccia LabView dove è stato possibile caratterizzare il circuito risonante variando la frequenza tra 30-50 kHz.

Di seguito il secondo prototipo del caricabatteria per Ebike. È il primario del caricabatterie e rispetto al primo prototipo funziona ad una frequenza più alta. Per la parte magnetica è stata utilizzata una bobina di Wurth Elektronik.

Il circuito durante un test connesso ai vari strumenti di misura e alla seriale di un pc per la variazione della frequenza.

Articoli scientifici:

1- Resonant inductive power transfer for an E-bike charging station (Journal ELSEVIER)

2- Controller design and experimental validation of a power charging station for e-bike clever mobility (Conference IEEE)

3- Detailed continuous and discrete–time models and experimental validation to design a power charging station for e-bike clever mobility (Journal ELSEVIER)


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!


Progetto Europeo Clean Sky Project (FP7) – I-PRIMES

I-PRIMES: Intelligent Power Regulation using Innovative Modules for Energy Supervision

JTI-CS – Joint Technology Initiatives – Clean Sky
from 2012-06-01 to 2014-12-31

I-PRIMES è un progetto Europeo FP7-JTI del programma di ricerca Clean Sky, nel settore Aeronautico.

I partecipanti al progetto:

  • Università degli studi della Campania “Luigi Vanvitelli”;
  • Aeromechs: di cui i fratelli Rubino Guido e Luigi sono stati i responsabili della progettazione, realizzazione e test hardware e dei codici firmware delle SSPC (Solid State Power Controller) progettate.

Tutte le parti del progetto sono state sviluppate e realizzate presso il laboratorio dei fratelli Rubino, ora RubinoLab.

 

Fase di test del dispositivo I-PRIMES.

Descrizione

L’obiettivo principale è stato lo sviluppo di un dispositivo hardware/software in grado di implementare un sistema innovativo di gestione dell’energia (I-LPM) per una rete elettrica aeronautica.
I-PRIMES è un sistema avanzato “intelligente” per carichi elettrici, che ottimizza il consumo e uniforma le richieste di energia nei periodi transitori di potenza o al sopraggiungere di un guasto elettrico.

Il sistema utilizza una struttura modulare.

Ogni cella è composta da un dispositivo programmabile, uno stadio di interfacciamento e una innovativa parte di potenza che implementa una tecnica di filtraggio sulla linea dc a 270Vdc di dimenzioni contenute.
Il modulo “master” è stato in grado di implementare le I-LPM e comunicare ai moduli “slave” tramite CAN-BUS 2.0B la strategia di gestione dell’energia. Alcuni moduli “slave” sono a “potenza fissa”, altri a “potenza variabile” per la riduzione del consumo.

Caratteristiche:

  • Tensione nominale: 270V (DC)
  • Potenza massima per singolo dispositivo: 15kW
  • Modalità operative: ON / OFF – buck converter
  • Filtro di linea DC bus 270V @15kW
  • CAN-BUS 2.0

TEST: RIG SAFRAN (Tolouse-Paris).

 

Inviti e presentazioni del progetto I-PRIMES

  • CIRA “Centro Italiano Ricerche Aerospaziali” di Capua (12 Giugno 2014). Presentazione del dispositivo I-PRIMES nel meeting “Clean Sky GRA Annual Review”. Durante il meeting, sono stati esposti in una sala conferenza le funzionalità del dispositivo I-PRIMES con una demo in tempo reale ai responsabili del progetto Clean Sky e dirigenti di aziende del settore aeronautico.

  

  • Stand “Clean Sky” al 49th Farnborough International Airshow (18 lug 2014 – 20 lug 2014). Selezionati per esporre e dimostrare le funzionalità del dispositivo I-PRIMES.

UPGRADE

Un aggiornamento del progetto I-PRIMES con estensione hardware/software è un EPC (Electrical Power Center) che è stato progettato e realizzato per test in volo “PERMIT TO FLIGHT LEVEL“.


Progetto Europeo Clean Sky (FP7) – EPOCAL

EPOCAL: Electrical POwer Center for Aeronautical Loads

JTI-CS – Joint Technology Initiatives – Clean Sky
dal 2013-03-01 al 2015-07-31

EPOCAL è un progetto Europeo FP7-JTI del programma di ricerca Clean Sky, nel settore Aeronautico.

I partecipanti al progetto:

  • Università degli studi della Campania “Luigi Vanvitelli”;
  • Aeromechs: di cui i fratelli Rubino Guido e Luigi sono stati i responsabili della progettazione, realizzazione e test hardware e dei codici firmware delle SSPC (Solid State Power Controller) progettate ad hoc. Inoltre si sono occupati di tutte le comunicazioni interne (CAN-BUS 2.0b) e l’interfacciamento a dispositivi esterni di terze parti.

Tutte le parti del progetto sono state sviluppate e realizzate presso il laboratorio dei fratelli Rubino, ora RubinoLab.

Descrizione

L’obiettivo principale di questo progetto è stato lo sviluppo di un Electrical Power Center (EPC) cioè di un distributore di potenza per il “flight test” su AIRBUS ATR-72, da integrare con una consolle di controllo dedicata (CC), per valutare le strategie avanzate di gestione dell’energia (E -EM).

I principali punti chiave sviluppati sono stati:

  1. Un EPC equipaggiato con Solid State Power Controllers (SSPC) progettato ad hoc che integra le protezioni hardware e software della sua funzionalità e regola la potenza dei carichi in base alla strategia di gestione dell’energia.
  2. Le tecnologie più recenti sono state implementate nel distributore di energia, riferendosi alle più moderne tecniche, al fine di garantire la conformità con gli standard aeronautici.

Il progetto è stato realizzato procedendo secondo un tipico flusso di lavoro basato sull’analisi dei requisiti, sulle specifiche, sulla fase progettuale, sull’implementazione fisica, sulla fase di test, sull’analisi dei risultati rispetto alle simulazioni e alla convalida finale delle apparecchiature.

L’EPC è uno dei componenti fondamentali per il corretto funzionamento di tutte le parti elettriche ed elettroniche di un aereo, per questo motivo prima dell’installazione per il “test in volo” su AIRBUS ATR-72 (tenutosi a Tolosa nel mese di marzo 2016) sono stati richiesti severi test preliminari per la qualificazione fino a 10000mt, presso un laboratorio esterno qualificato per specifiche aeronautiche (più di 35 test).

I test di qualificazione di tutte le parti per il volo, sono stati condotti presso la azienda Celab (Latina) che ha certificato l’affidabilità del dispositivo secondo i più rigidi standard aeronautici.

Di seguito alcune foto dell’interno del dispositivo “Epocal”

Foto dell’equipaggiamento “Epocal” installato all’interno di un ATR-72.

Il dispositivo nell’ambito del progetto Clean Sky, nel mese di marzo 2016 si è classificato tra i primi
10 migliori lavori per tecnologia su oltre 300 progetti valutati. In futuro sarà riprodotto per la installazione di serie su nuovi velivoli.

Articoli:

  1. Electrical Power Center for Aeronautical Applications

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!


Convertitore risonante LLC

In questa pagina RubinoLab.com presenta diverse foto di un prototipo e prove sperimentali di un convertitore DC-DC risonante di tipo bidirezionale da 3kVA, realizzato per attività di ricerca.

 

Il lavoro è stato commissionato da AIRBUS, una importante azienda europea che opera nel settore aerospaziale e difesa, ed è stato parte della tesi di dottorato di Luigi Rubino, membro di RubinoLAB. Il convertitore è una evoluzione rispetto ai classici convertitori hard- switching a cui abbiamo partecipato nel 2008-2009 per un progetto Europeo chiamato “Moet” More Open Electrical Technologies.

Il convertitore LLC, ha richiesto moltissime ore di lavoro per sviluppare tutti i modelli matematici prima della realizzazione tenendo in conto anche degli effetti parassiti dei componenti. Inoltre tutte le parti difficili da reperire, quali trasformatore, capacità risonante, PCB ad alto spessore in rame, driver per pilotaggio mos fino a frequenze di 300kHz, board di misura e controllo sono stati realizzati nei nostri laboratori e confrontati con i modelli matematici. Il risultato, le misure sono identiche alle simulazioni.

Particolare accuratezza di progettazione è stata rivolta al trasformatore risonante e alle capacità risonanti non reperibili dai distributori di componenti.

Per il trasformatore sono state acquistate solo le parti magnetiche, mentre le spire sono lastre in rame opportunamente lavorate isolate tra loro.

 

Le capacità risonanti al primario e al secondario sono i componenti più critici nel sistema, poiché devono mantenere stabili il valore anche al variare della temperatura di lavoro. Una minima variazione del valore della capacità varia la frequenza di risonanza del circuito e quindi non avremo più il massimo trasferimento di potenza. Il numero di capacità SMD da parallelizzare è stato scelto tenendo presente il valore di capacità e la corrente di lavoro.

 

Per valutare la correttezza dei parametri di tutto il circuito è stata realizzata una interfaccia LabView dove è stato possibile caratterizzare il circuito risonante variando le frequenza del circuito.

In figura il prototipo durante le fasi di test.

Nel video possiamo vedere le tipiche misure al variare della frequenza di lavoro.

Articoli scientifici:

  1. Complementarity Model for Steady-State Analysis of Resonant LLC Power Converters
  2. LLC resonant converters in PV applications comparison of topologies considering the transformer design