Introduzione

I canali CANBus di cui sono dotati i controlli Robox dispongono dei protocolli DS301, DS401 e DS402 e sono in grado di pilotare fino ad un massimo di 16 dispositivi per canale. Sono supportati fino a 4 PDO in trasmissione e 4 PDO in ricezione. Il firmware RTE è in grado di gestire come master fino ad un massimo di 4 canali CANBus per un totale quindi di 64 dispositivi.

Per la gestione dei canali CANBus mediante schede CAN.INT è necessario che sulla partizione di sistema della flashcard (SYS_DIR) sia presente il gestore della comunicazione CANBus (file CODMvvrr.UFW).

Deve essere presente il file contenente la configurazione delle rete COCn.CFG (Deve trovarsi nell'alias di cartella CAN_DIR o USER_DIR).

Segnalibri

Argomenti correlati

Configurazione

File COCn.CFG

Nel file COCn.CFG è contenuta la configurazione di un canale della rete CANBus; ne possono essere presenti fino a 4 nel caso si utilizzi il numero massimo di canali CANBus gestiti.

n rappresenta il numero del canale, quindi COC0.CFG contiene la configurazione del primo canale, poi vengono COC1.CFG per il secondo canale, COC2.CFG ed infine COC3.CFG.

Si tratta di file ASCII che vengono assunti da RTE solo all'accensione del controllo e che vengono utilizzati sia per parametrizzare la rete, sia per conoscere i pacchetti dati scambiati con ciascun dispositivo presente.

Per generare questi file l'ambiente di sviluppo RDE mette a disposizione dell'utente un apposito configuratore (vedi documentazione relativa all'editor di configurazioni CANopen). Tramite quest'ultimo è possibile configurare i parametri relativi al canale di comunicazione CANBus (bit rate, frequenza del sync ecc... ), inoltre per ogni singola WS della rete l'utente può programmare quali variabili Robox devono essere coinvolte nella comunicazione CAN, mappandole nei PDO RX e TX.

NOTA: Assicurarsi che nella finestra di progetto-->proprietà-->configurazione-->canopen ci sia il flag sull'abilitazione. In questo caso ad ogni generazione verrà automaticamente linkato il file generato cfg nella finestra di progetto tab "file in flash".

Passi da seguire per configurare la rete

I passi che l'utente deve seguire sono i seguenti:

•Creare il file COC relativo al canale che descrive quanti e quali device sono presenti sulla linea. Dal menù principale selezionare file-->nuovo. scegliere il tipo "coc" ed assegnare il nome della linea can (suggerimento "coc")

•Dalla finestra editor di configurazioni CANOpen procedere alla parametrizzazione del canale ed alla descrizione dei nodi collegati

•Dal menù principale selezionare modifica-->generazione file quindi selezionare 0 per il canale CAN1, 1 per il canale CAN2 etc.

NOTA: Al nome file verrà aggiunto il numero di canale ed associata estensione cfg. Questo file dovrà essere caricato sulla CF e verrà utilizzato da RTE all'accensione per analizzare/configurare la rete.

•Agganciare il file COC al configuratore grafico di progetto (impostazioni-->CANOpen)

Nella finestra di configurazione CANOpen viene richiesto:

•ID nodo: Rappresenta il numero fisico del nodo CAN e può essere variare (1 -:- 127)

•ID stazione Robox : Rappresenta il numero della workstation can Robox logica (1 -:- 64)

Nella finestra di configurazione di progetto-->menù assi viene richiesto:

•ID asse: Asse logico Robox al quale fanno riferimento le variabili predefinite (IP, CP etc) (1 -:- 32)

•ID stazione Robox : Rappresenta il numero della workstation can Robox logica (1 -:- 64)

•ID stazione Robox DEVE essere impostato dall'utente uguale nelle due finestre

NOTA: Questa doppia associazione è necessaria dal momento che RTE gestisce fino a 4 reti can distinte. Quindi possono esistere due ID nodo uguali ma su reti diverse che chiaramente devono essere associati a due ID stazione Robox diverse!

Mappatura PDO

Nei PDO in RX posso mappare i seguenti tipi:

•Real position (CP(ax))

•Drive ideal position (Posizione ideale in formato drive)

•Input word (IW(n))

•CANOpen status word

•Integer 16 register (R(n) per controlli Robox 16 bit)

•Integer 32 register (R(n) per controlli Robox 32 bit)

•Real register (RR(n))

•Auxiliary (È usato solo dal sistema operativo per eseguire il ciclo di 0, mapparlo nei PDO  consente al drive di velocizzare la comunicazione di micro raggiunto. La variabile non è visibile dall'utente)

•Input Word + auxiliary 0 (È uguale al precedente, ma viene mappato lo stato dell'auxiliary su una IW(n) in modo che l'utente ne possa consultare il valore)

Nei PDO in TX posso mappare i seguenti tipi:

•Ideal position (IP(ax))

•Ideal speed (IV(ax))

•Output Word (OW(n))

•Speed Reference (SREF(ax))

•Torque Reference (TREF(ax))

•CANOpen control word

•Integer 16 register (R(n) per controlli Robox 16 bit)

•Integer 32 register (R(n) per controlli Robox 32 bit)

•Real Register (RR(n))

•Auxiliary (Serve per velocizzare il comando per l'esecuzione del C0)

NOTA: Se opportunamente programmato, il file COCn.CFG può essere di aiuto nella diagnostica dell'applicativo attivando e disattivando errori o warning, restituiti dal sistema, che possano rendere macchinoso il debugging dell'applicativo.

Operazioni effettuate dal Master all'avvio della rete

Le operazioni eseguite dal master Robox CAN durante l'avvio di una rete CAN sono le seguenti:

1.Invia per prima cosa un messaggio NMT broadcast di ENTER_PRE_OPERATIONAL per mettere tutti gli eventuali nodi slave presenti in PRE-OP

2.Verifica la presenza degli slave mappati nella rete chiedendo l'oggetto DeviceType (0x1000 0x00)

a.Se non c'è risposta o il valore di risposta è diverso da quello che si aspetta abortisce la configurazione di quel nodo

b.Se c'è risposta con valore corretto (o valore errato ma flag di ignora valore DeviceType) prosegue

3.Invia l'oggetto CommunicationCyclePeriod (0x1006 0x00)

a.Se non c'è risposta o risposta errata (senza flag di bypass) abortisce la configurazione di quel nodo

b.Se c'è risposta ok (o flag di bypass) prosegue

4.Configura il protocollo di WATCH-DOG CANOpen impostato per quel nodo. Le operazioni effettuate dipendono dal protocollo configurato

a.HEARTBEAT: invia l'oggetto ProducerHeartbeatTime (0x1017 0x00)

i.Se non c'è risposta o risposta errata (senza flag di bypass) abortisce la configurazione di quel nodo

ii.Se c'è risposta ok (o flag di bypass) prosegue

b.LIFEGUARD: invia gli oggetti GuardTime (0x100C 0x00), LifeTimeFactor (0x100D 0x00) e imposta l'oggetto ProducerHeartbeatTime (0x1017 0x00) a 0 (di default per le specifiche CANopen si usa HEARTBEAT, se ProducerHeartbeatTime = 0 si attiva LIFEGUARD)

i.Se non c'è risposta o risposta errata (senza flag di bypass) abortisce la configurazione di quel nodo

ii.Se c'è risposta ok (o flag di bypass) prosegue

5.Configura i PDO secondo quanto specificato nella configurazione del nodo

a.Se non c'è risposta o risposta errata (senza flag di bypass) abortisce la configurazione di quel nodo

b.Se c'è risposta ok (o flag di bypass) prosegue

6.Invia per prima cosa un messaggio NMT broadcast di START per mettere tutti gli eventuali nodi slave presenti in OPERATIONAL

7.Comincia a trasmettere i TxPDO mappati e il SYNC e si aspetta di ricevere gli RxPDO mappati.

NOTA: Da RTE 34.30.2 è stata aggiunta la possibilità di modificare la sequenza di configurazione dei parametri del protocollo LIFEGUARD. Impostando il valore del Tipo di dispositivo con il bit 30 a 1 (0x40000000) verrà modificata la sequenza di invio dei parametri: prima si provvederà ad azzerare il tempo di HEARTBEAT, poi si andrà a configurare il LIFE_GUARD_TIME e il LIFE_GUARD_FACTOR. Gli altri bit del Tipo di dispositivo rimangono invariati e devono corrispondere al valore dell'oggetto DEVICE_TYPE (0x1000).

Operazioni effettuate in caso di disconnessione di un nodo

Il master Robox CAN utilizza il protocollo di WATCH-DOG configurato per controllare che un nodo sia ancora presente ed, eventualmente, per verificare che sia scomparso dalla rete. Senza un protocollo WATCH-DOG configurato il master Robox CAN non può verificare la presenza di un nodo.

In caso di scomparsa di una stazione durante il runtime, se specificato l'apposito flag sulla singola stazione, il master Robox CAN richiede al nodo, tramite sdo, il DeviceType ogni 2.5s, quando ottiene una risposta corretta ripete le operazioni effettuate all'avvio dal punto 1 al punto 6 (vedi capitolo precedente) inviando però i messaggi NMT solo a quel nodo e non a tutti tramite broadcast.

Funzioni/istruzioni

Keyword

Comandi SHELL

Comandi dispositivo