Data: 24 Luglio 2009

Os: 13.17.1632

RoboxLib: 3.4.0

Derivata da : RTE 33.17.7

Nota: suite con >= RDE3.7.0

Nota: suite con >= RC3E v33.3.2

Nota: suite con >= RPE v1.3.0

build8

•IMPLEMENTAZIONE/CORREZIONE(OS)

Comunicazione EtherCAT Ethernet

build7

•IMPLEMENTAZIONE/CORREZIONE(OS)

Comunicazione EtherCAT Ethernet - configurazione.

•CORREZIONE

Eliminato potenziali  cause di undefined opcode.

•CORREZIONE

Eliminato problemi di inizializzazioe su Canbus.

build6

•CORREZIONE(OS)

Configurazione Fieldbus

Inserito OSF con correzioni configurazione fieldbus mediante file "fb.cfg". Non funzionava l'associazione agli INP_W e alle OUT_W (segnalazione di errore configurazione nel report durante il boot di OSF). Inoltre non funzionava la scrittura sugli output e la lettura degli input digitali nel caso non fossero stati definiti tutti quelli che lo precedono nella stessa word

•VARIANTE(OS)

Configurazione EtherCAT

Modificato OSF per velocizzare analisi del file, in formato XML, di configurazione del fieldbus di tipo EtherCAT durante la fase di boot.

•CORREZIONE(OS)

Canopen uRMC

Nella versione 33.17.5 non funzionava più il can su uRMC se sulla flash era presente il file RSW.CFGX

build5

•IMPLEMENTAZIONE

POWER_SET AM

Aggiunta la possibilità di specificare un bit di AM come Global feedback per power set

build4

•VARIANTE

POWER_SET UNRESOLVED

La presenza di simboli irrisolti in uno qualsiasi dei task utente causa il blocco dell'andata in potenza e sul fronte della richiesta di andata in potenza rigenera l'allarme 801

•VARIANTE(OS)

EtherCAT

Migliorata la gestione (ottimizzato routine esecuzione / tempistiche / priorità)

•VARIANTE(OS)

CAN402

Modificato limite frequenza massima del SYNC del CANopen da 600 a 1000 Hz.

•VARIANTE(OS)

BCC3 monosocket

Aggiunta gestione server BCC3 monosocket. Il server BCC3 monosocket viene avviato sulla porta TCP 8100 mentre quello multisocket, compatibile alle versioni precedenti RDE3, rimane sempre in ascolto sulla porta TCP 8000.

•IMPLEMENTAZIONE(OS)

EtherCAT

Aggiunta interfaccia per poter accedere alle stazioni CoE (Can Over EtherCAT) come se fossero delle stazioni CAN. In questo modo il firmware RTE non "vede" la differenza tra una stazione CAN canonica ed una CAN via EtherCAT potendo così usufruire delle stesse funzioni di accesso come, ad esempio, la lettura e le scrittura degli SDO, la gestione della macchina a stati DS402, le Emergency generate dalle stazioni, la lettura dei traduttori, l'impostazione dell'attuatore, lettura e scrittura della NMT.

•VARIANTE(OS)

IO

Gestione delle variabili INP e OUT con EtherCAT in modo più diretto

•VARIANTE(OS)

RSW

Il file di configurazione "RSW.CFG" adesso è stato chiamato "rsw.cfgx".

•CORREZIONE(OS)

RHW.CFG

Risolto il problema che dichiarano nel file "RHW.CFG" il canale CAN "Unused;", cioè senza lo spazio tra "Unused" e ";", veniva preso come errore con conseguente segnalazione di BadConfig.

•VARIANTE(OS)

EtherCAT

Per configurare i fieldbus di tipo EtherCAT adesso prima si cerca se esiste il file "/fa/ecat1.cfgx". Se non presente si cerca allora il file "/fa/ecat1cfg.xml".

•VARIANTE(OS)

RBUS

Gestione interfaccia per drive generico di tipo CiA 402 via RBUS (rack Robox). Per configurare il bus, bisogna inserire il file "/fa/rbus1.cfgx" nella compact flash del controllo.

•VARIANTE(OS)

EtherCAT

Nella gestione CoE (Can Over EtherCAT), modificata la funzione ReadNmt() per rendere il flag di presenza stazione in base alla segnalazione di "GetLinkError()" reso dalla interfaccia EtherCAT master. In questo modo non dovrebbe più essere necessario testare da applicativo R la variabile globale "DevState" bit "0" per sapere se il cavo ethernet è connesso o meno.

•CORREZIONE(OS)

RHW.CFG

Nel caso su uRbxm venisse configurata una, o più, linea CAN (con file COC appropriato) e sulla linea non fosse connessa alcuna stazione CAN, OSF andava in "UNDEF-OPCODE" oppure a volte si riscontravano problemi con la FAT (ad esempio problema di caricamento file)

•CORREZIONE(OS)

CAN402

Modificate le tempistiche di scrittura informazioni di debug nel report da parte del Service Can.

•IMPLEMENTAZIONE

SYS_FLAG

Aggiunto il bit

o0x00000800 (B11) abilita il calcolo di SER_CTHR anche quando l'allarme di inseguimento è disabilitato

•VARIANTE

TFB RC OC

Disabilitata scrittura diretta come variabili da shell, ladder, bcc3

•CORREZIONE

F_DEL

Corretta cancellazione file con wild_card

•VARIANTE

SERIALI

Onorate tutte le seriali gestite da os/bios

build3

•IMPLEMENTAZIONE

F_RENAME

Aggiunto istruzione di rename che viene eseguita da main

Ad uso e consumo di ob

•VARIANTE

F_OPEN F_CLOSE

Gestita esecuzione di queste funzioni da task di main

•IMPLEMENTAZIONE

ENCODER ASSOLUTO

Abilitata gestione encoder assoluto per schede ABS_AXI e ABS_ENC

•IMPLEMENTAZIONE

WATCH_DOG

Nell'eventualità che l'esecuzione delle rule venga rilevata troppo lunga oltre alla normale caduta del W.D., si sospendono tutti i task utente con priorità superiore che possono interferire (rule asincrone, task ladder....). Vengono inoltre sospesa l'esecuzione delle rule utente e il gestore stesso di rule (con blocco di tutte le eventuali comunicazioni sincrone).

build2

•IMPLEMENTAZIONE

LADDER

Gestione del formato del file 1.4

•CORREZIONE

REPORT

ALARM HISTORY Corretta emissione messaggi in funzione dell'id anche su scaravolto su U32

•VARIANTE

FIELDBUS

Cambiato ordine esecuzione su sync(per can/sercos/ethercat)

build1

•CORREZIONE

LOV

Possibile male interpretazione dei nomi in ladder

build0

•CORREZIONE

SER_MOD

Disattivato effetivamente controllo handshake hw se modalità 2 e 17

•IMPLEMENTAZIONE

ALARM_RESET

Velocizzata sua esecuzione

•IMPLEMENTAZIONE

POWER_SET

Aggiunto keyword -POOW bool per l'istruzione POWER_SET_FLAGS

Serve per poter andare in potenza se nello stack allarmi ci sono solo warning

•IMPLEMENTAZIONE

TRACKING

Funzione di inseguimento di un target in posizione e velocità con velocità e accelerazione massime e dei limiti di movimento.

Qualora si volesse disabilitare il controllo dei limiti imporli uguali.

SINTASSI :

TRACKING (sdef)

dove:

osdef struttura di tipo STRU_TRACK per lo scambio dei vari dati

 

Esito della funzione:

oMV_SYNCHRONIZED (8) = target raggiunto - movimentazione in coppia

oMV_FOLLOWING (5) = target non raggiunto - inseguimento in corso

oMV_SPEED_LIMITED (10) = target non raggiunto - inseguimento in corso - limitazione della velocità

oMV_ACCEL_LIMITED (9) = target non raggiunto - inseguimento in corso - limitazione della accelerazione

oMV_DECEL (17) = target non raggiunto - decellerazione per raggiungimento di uno dei due limiti di posizione

oMV_REACHED (6) = target non raggiunto - raggiunto uno dei due limiti di posizione

oMV_OUT_OF_LIMITS (19) = target non raggiunto - tentativo di uscire ulteriormente dai limiti di posizione

o-6 = parametro acc nullo

o-5 = parametro maxspeed nullo

o-9 = parametro delta minore/uguale a 0

 

DEFINIZIONE STRUTTURA STRU_TRACK

STRUCT stru_track

REAL despos ; quota desiderata

REAL desspeed ; velocità desiderata

REAL actpos ; quota attuale

REAL actspeed ; velocità attuale

REAL maxspeed ; massima velocità

REAL acc ; massima autorizzazione

REAL posmin, ; paracarro inferiore slave

REAL posmax, ; paracarro superiore slave

REAL delta ; intervallo di campionamento

END_STRUCT

•IMPLEMENTAZIONE

KIN_CONV

Funzione che calcola i valori di accelerazione e di jerk che consentono, partendo da fermo, di raggiungere la velocità 'vel' nel tempo 't_acc'.

SINTASSI :

KIN_CONV (vel, t_acc, p_jerk, acc_r, jerk_r)

KIN_CONV (vel, t_acc, p_jerk, acc_r, jerk_r, max_acc)

dove:

ovel valore di velocità da raggiungere partendo da 0. Viene usato il suo valore assoluto [unit/sec]

ot_acc tempo per passare da 0 a vel [sec]

op_jerk valore compreso tra 0 e 1 che stabilisce quanto jerk applicare al tratto di accelerazione:

▪p_jerk = 0 -> accelerazione brusca a gradino (jerk non utilizzato)

▪p_jerk = 1 -> accelerazione dolce a triangolo (tratto completamente jerkato - rampa di velocità a S)

oacc_r variabile in cui viene scritto il valore di accelerazione necessario [unit/sec^2]

ojerk_r variabile in cui viene scritto il valore di jerk necessario [unit/sec^3]

omax_acc [opzionale] valore massimo che può assumere l'accelerazione. Viene usato il suo valore assoluto

 

NOTA: Nel caso di accelerazione limitata da max_acc, quando possibile, la funzione cerca di garantire comunque la durata del tratto di accelerazione t_acc a scapito del fattore di jerk p_jerk.

 

Esito della funzione:

o0 = tutto a posto

o1 = parametro p_jerk non rispettato a causa della limitazione di max_acc

o2 = tempo t_acc non rispettato a causa della limitazione di max_acc

o3 = tempo t_acc e parametro p_jerk non rispettati a causa della limitazione di max_acc (in tal caso) il parametro p jerk viene assunto come se fosse 0

o-2 = parametro t_acc negativo o nullo (si assume t=1)

o-3 = parametro p_jerk esterno all'intervallo [0-1]) (si assume p_jerk = 0)

•IMPLEMENTAZIONE

RPE

Aggiunto supporto per RPE per poter utilizzare delle rule per la gestione del ciclo di 0 utente.

Aggiunto allarme "993 internal error <code>"

"<code>" descrizione

1 --> il numero di rule complessivo (RTE + RPE è maggiore di 32)

imposta il bit am[34].2

Aggiunto allarme "2804 Wrong rule number <%d> from RPE <%d>"

imposta il bit am[41].4

•VARIANTI

ALLARMI

Cambiato testo allarmi

"18#nax R.ID<id> CAN fault <code>"

"19#nax R.ID<id> CAN Emcy <code>"

"80 R.ID<id> CAN fault <code>"

"81 R.ID<id> CAN Emcy <code>"