Benchmarks for the NI 9144 Expansion Chassis

Lo chassis d’espansione NI 9144 è progettato per operazioni di I/O distribuito e sincronizzato su di una rete deterministica. Programmabile tramite il modulo LabVIEW Real-Time questo chassis è in grado di contenere fino ad 8 moduli NI serie C ed può essere connesso in modalità daisy chain con quei sistemi NI CompactRIO e PXI Real-Time muniti di una doppia porta ethernet. In aggiunta a tutto questo ogni NI 9144 possiede un chip FPGA (Field Programmabile Gate Array) che, grazie al modulo LabVIEW FPGA, può essere configurato per creare sistemi con intelligenza distribuita in termini di tempistiche e capacità di processamento dati. Questo articolo esamina i dettagli tecnici e le prestazioni legate al tempo ciclo di un sistema NI 9144 utilizzando l’NI Scan Engine e LabVIEW Real-Time.

Figura 1. Sistema Ethernet Real-Time contenente lo Chassis NI 9144

La comunicazione di rete tramite il controllore master ed il cestello NI 9144 si basa su di un protocollo Ethernet real-time aperto chiamato EtherCAT. Ad alto livello i benchmark effettuati su EtherCAT si dividono in quattro parti: logica, driver, rete EtherCAT ed I/O.

Figura 2. Componenti dei benchmarks tra master e slave

Per quanto riguarda il dispositivo EtherCAT master i risultati dei benchmark dipendono dal codice utente e dal driver EtherCAT il quale muove i dati dal codice al driver. In generale, il controllore EtherCAT master influisce sui tempi ciclo del sistema in quanto la sua capacità di elaborazione determina quanto velocemente vengono processati dalla logica utente e dal driver. Più potente è il controller, maggiori saranno i dati di I/O che verranno gestiti nel tempo.

Per contro i benchmarks sul dispositivo slave dipendono dal tragitto del pacchetto dati sulla rete EtherCAT così come dalla velocità di aggiornamento degli I/O sullo slave stesso. La velocità dei pacchetti sulla rete EtherCAT è dipendente da molti fattori, come il numeri di dispositivi (o nodi) slave, dalla lunghezza del cavo Ethernet e soprattutto da quanti dati di I/O vengono immessi sulla rete. Come nel caso di un protocollo deterministico le tempistiche della rete EtherCAT sono calcolate accuratamente in modo tale che il master conosca esattamente quando ogni slave sta aggiornando oppure trasferendo i dati. Non a caso la velocità della rete EtherCAT è la componente più rapida nell’ambito della chiusura dell’anello di trasmissione per un sistema di questo tipo.

Quando si utilizza il modulo NI 9144 insieme a Controllori Programmabili per l’Automazione (PACs) NI le componenti dei benchmark descritte in precedenza si possono associare ai seguenti elementi:

Figura 3. Componenti di un benchmark NI per Master e Slave

La logica è rappresentata dal codice LabVIEW utente mentre il driver è composto dall’NI Scan Engine in LabVIEW  e dal software NI-Industrial Communications for EtherCAT. La rete EtherCAT è intesa come la comunicazione sul cavo Ethernet ed i punti di I/O si riferiscono ai moduli di C Series I/O modules. Tutte queste componenti fanno parte di un sistema NI anello chiuso sul quale valutare il tempo ciclo.

Durante un singolo ciclo di scansione degli I/O (o I/O Scan) il trasferimento di un pacchetto EtherCAT deve essere sincronizzato tra il controllore Master ed i cestelli slave NI 9144. Ad ogni I/O Scan il master invia un pacchetto contenente nuove uscite ed istruzioni per gli slave i quali lo restituiscono al master inserendovi i nuovi valori acquisiti in ingresso. Utilizzando i dati aggiornati provenienti dal pacchetto EtherCAT il master inizia la parte di scansione all’interno del suo programma (o program Scan) mentre gli NI 9144 aggiornano i dati in uscita (Slave Update). Il program Scan è il tempo richiesto dal master per processare i dati ed eseguire il codice del programma LabVIEW. Lo Slave Update è il tempo impiegato da un dispositivo slave per il trasferimento DMA, il processamento dei dati e l’aggiornamento dei punti di I/O. Pertanto il tempo ciclo è limitato sia dalla fase di program Scan che da quella di Slave Update, a seconda di quale delle due impiega maggio tempo.

Figure 4. Diagramma temporale di un ciclo di Scan

Il tempo legato alla fase di Program Scan aumenta col numero di dispositivi slave e di I/O sulla rete poichè il controllore master ha più dati da processare. Ad ogni modo il tempo di aggiornamento dello slave non incrementa poichè esso aggiorna i suoi punti di I/O in parallelo allo stesso istante. Per questo motivo maggiore è la presenza sulla rete di slave e quindi di I/O, più alta è la probabilità che il dispositivo master diventi il collo di bottiglia per il sistema. Se un’applicazione coinvolge un elevato numero di canali di I/O, è caldamente consigliato l’utilizzo come master di un sistema PXI ad elevate prestazioni.

Figure 5. Sistemi CompactRIO e PXI con il dispositivo NI 9144

Benchmarks per il Controller Master

La tecnica comune per programmare il controller master in LabVIEW è quella di utilizzare l’NI Scan Engine, che è la componente di LabVIEW Real-Time che effettua la scansione dei singoli valori di I/O ed il conseguente salvataggio in memoria ad una velocità predefinita dall’utente. Al fine di creare un benchmark per il controllore master la quantità di tempo richiesta per eseguire il codice utente non è stata calcolata. La parte rimanente dei benchmark sul dispositivo master è quindi legata solamente alla velocità del driver, che include l’ammontare di tempo richiesto dal controllore per trasferire i dati dalla memoria dello Scan Engine verso le variabili di I/O. Questi oggetti software sono utilizzati per accedere i dati presenti sulla mappa di memoria dello Scan Engine ed ogni istanza di queste variabili di I/O richiede tempo per essere eseguita. Il tempo medio di esecuzione di ogni variabile di I/O tende a mantenersi costante anche se il numero di questi elementi sul diagramma a blocchi aumenta ed il grafico che segue mostra i tempi di esecuzione su alcuni controllori master. Partendo da questi dati il tempo medio di esecuzione risulta all’incirca 8 µs per il sistema integrato cRIO-9072, 3.5 µs per il controller embedded cRIO 9022 e 0.3 µs per il controller dual-core PXI-8106. 

Figure 6. Tempi medi di esecuzione per le variabili di I/O

Nota: Questa non è la lista completa di tutti i controller NI compatibili. Riferirsi alla Guida per la selezione di prodotti Ethernet Deterministici per maggiori informazioni. In generale maggiori sono le performance del processore, più rapidamente verranno eseguite le variabili di I/O.

Benchmarks per i dispositivi Slave

Una domanda ricorrente è quanti chassis 9144 posso collegare in daisy chain a partire dal master controller. A livello teorico, il protocollo EtherCAT stabilische che il massimo numero di dispositivi slave in una rete è 65536, ma un tale numero di nodi controllati da un singolo master può degradare la frequenza di scansione a tal punto da rendere consigliabile l’utilizzo di più master. In reatà è il numero di canali di I/O, non di dispositivi slave, che ha impatto maggiore sulla frequenza di scansione del sistema dal punto di vista del master. Come descritto in figura 4, la fase di program scan del master aumenta sulla base dei dati immessi nella rete EtherCAT mascherando quindi il tempo di aggiornamento degli slave. Nonostante quindi la presenza di overhead associato a ciascun dispositivo slave, 300 canali di I/O divisi su 20 slave 9144 hanno lo stesso tempo ciclo.

Combined System Loop Rate

Table 1 combines the benchmarks for the master controller and the NI 9144 to form the minimum cycle time, or system loop rate. 

Minimum Cycle Time = Driver + EtherCAT Network + I/O Updates

Note that these benchmarks do not include the amount of time the user’s code takes to run, so add the appropriate time for the code and see the related links below for more information.

Table 1. System Loop Rates

Based on the tests for these two controllers and four different I/O modules, a benchmarking spreadsheet called system_loop_rate_chart2.xls is attached at the end of this white paper to help you approximate the system loop rate for your configuration. Simply enter the number of analog and digital I/O channels you are using as well as the approximate time for running the LabVIEW code to calculate the system loop rate. Remember that these formulas are based on a specific hardware setup, and results may vary when using other I/O modules.

Related Links
NI Scan Engine Performance Benchmarks
Benchmarking Single-Point Performance on National Instruments Real-Time Hardware

You may also use the NI 9144 expansion chassis with other third-party EtherCAT masters but without the easy-to-use programming experience that LabVIEW provides. In such cases, benchmarks have been provided for just the NI 9144 and EtherCAT network without any master benchmark components. Remember that this is the minimum achievable cycle time; to calculate the actual system loop rate, you need to determine and compare the master’s program scan and execution times. The formula is made of two parts:

Minimum Slave Cycle Time = Packet Transmission Time + Slave Update Time

Packet Transmission Time

Once the EtherCAT packet leaves the master, the packet transmission time refers to the summation of the frame transmission, communication delay, and any jitter introduced along the way. 

Packet Transmission Time = Frame Transmission Time + Communication Delay + Jitter

The frame transmission introduces 80 ns for every byte of EtherCAT data as well as 5 µs for every EtherCAT frame that carries the data. (This total EtherCAT data directly corresponds to the number and type of I/O channels in the NI 9144 chassis.) The communication delay accounts for 600 ns for every NI 9144 chassis and 5 ns for every meter of Ethernet cable.

Slave Update Time

After the EtherCAT packet streams through all of the slaves and back to the master without stopping, all the slaves read inputs and write outputs in parallel. Therefore, the slave device with the worst case slave update time determines the minimum slave cycle time for your system. 

Slave Update Time = DMA Transfer Time + Worst Case Module Timing

To determine this, you must consider the unique module configurations for all NI 9144 chassis. Based on the modules in the chassis, you can calculate the DMA transfer time for input and output data. You also can determine the module with the worst case initiation, conversion, and refraction timing. Find the worst case slave update time by adding these values together.

Note: Since the release of LabVIEW 2009, you can program the modules in the NI 9144 at the hardware level with LabVIEW FPGA. Therefore, you can take advantage of modules that have faster update rates than the system loop rate. By collecting the I/O at the module’s maximum speed, use the FPGA code to do custom signal manipulation and inline processing, and then return the final result to the master controller.

Combined Slave Cycle Time

Because you can use many different combinations of modules in the NI 9144, another benchmarks spreadsheet called ni_9144_only_benchmarks.xls is provided below to apply all of these formulas and accurately calculate the minimum slave cycle time. Once you have entered the correct values, add the benchmarks from the third-party master to the calculated slave benchmarks to determine the entire system update rate for the application. For an extra boost in high-speed performance, use the LabVIEW FPGA capabilities to download custom intelligence onto the NI 9144.

Related Links
NI 9144 Expansion Chassis Under the Hood
CompactRIO Advisor