misura tempo di comunicazione Modbus RTU

[giobos]

Buongiorno a tutti,

 

premesso che sono abbastanza "ignorante" in fatto di reti ma che ho molta voglia di imparare, ho instaurato la comunicazione Modbus RTU tra un azionamento Panasonic e un PLC sempre Panasonic.

Ora vorrei misurare il tempo che intercorre da quando il master dà il comando via Modbus (di posizionamento in questo caso) a quando il comando è ricevuto dallo slave. C'è una qualche relazione che in base al tipo di comando Modbus (write single coil, write register, ...) e alla velocità di comunicazione mi fornisca questo tempo?

 

Grazie a tutti 

[Livio Orsini]

La durata di trasmissione è calcolabile, basta contare i bit trasmessi dal comando e moltiplicare per il boaud rate espresso in bit/secondo.

Se invece vuoi conoscere il tempo che intercorre da quando il comando viene inviato dal PLC a quando viene eseguito puoi tentare di alzare un'uscita del PLC scrivendo direttamente nell'uscita fisica, e poi facendo alzare dallo slave un uscita digitale (dovrebbe esserci qualche digital out libero sull'azionamento) al momento dell'inizio della funzione comandata. Se la distanza fisica tra i 2 oggetti è piccola, puoi usar eun oscilloscopio per misurare il tempo intercorso.

[rguaresc]

Quote

il tempo che intercorre da quando il comando viene inviato dal PLC a quando viene eseguito

Il tempo tra quando il messaggio modbus arriva allo azionamento e quando questo risponde "Done" si aggira sui 50 millisecondi, ed e' abbastanza indipendente dalla marca dello inverter. E' la componente principale dei ritardi, la trasmissione del messaggio dura molto meno. Il modbus RTU non ha reazioni rapide.

[SandroCalligaro]

SIccome nel Modbus ogni comando del master prevede una risposta, andando a misurare il tempo che intercorre tra la fine dello stream di bit del master e l'inizio di quello di rispota dello slave, hai una stima per eccesso del tempo necessario a "ricevere" il dato.

 

Il fatto che quel ritardo sia indipendente dall'implementazione mi sembra molto strano. Anzi, mi aspetto che ci sia addirittura un minimo di dipendenza dalla lunghezza del dato da scrivere (teoricamente si possono scrivere parecchi byte con un solo comando).

[giobos]

Quote

Il fatto che quel ritardo sia indipendente dall'implementazione mi sembra molto strano. Anzi, mi aspetto che ci sia addirittura un minimo di dipendenza dalla lunghezza del dato da scrivere (teoricamente si possono scrivere parecchi byte con un solo comando).

 

Certo, anche io infatti da un rapido conto come mi ha suggerito Livio ho potuto verificare che il tempo che intercorre tra l'inizio di scrittura o lettura dello stream di bit da parte del master e la fine di questa stessa operazione va da meno di 1 ms a circa 1 ms e questo tempo dipende dalla lunghezza del dato da scrivere.

 

Ma allora mi sorge spontanea un'altra domanda: se io devo dare il comando di servo ON al mio azionamento via Modbus, il master invia il comando al driver (scrittura su un indirizzo), il driver risponde a questa domanda chiudendo la comunicazione e solo dopo va in Servo ON? Oppure una volta che l'azionamento riceve il comando dal master va in Servo ON e poi invia la risposta di avvenuta operazione al master?

 

[Livio Orsini]

Ci sono delle priorità, il controllo è ad alta priorità, la risposta di comando andato a buon fine o abortito, è a bassa priorità.

Per questo motivo, se vuoi avere l'esatta percezione del tempo intercorso tra l'invio del comando e la sua esecuzione, dovresti arrangiare una prova come quella che ti ho descritto.

 

Comunque Modbus è più adatto a strumen tazione ed ad HMI, per automazione e controllo bisognerebbe usare bus di campo come profibus, che è praticamente uno standard de facto, o altri simili.

[SandroCalligaro]

Dal punto di vista della misura del ritardo, una misura con oscilloscopio, fatta sul bus di comunicazione, taglierebbe la testa al toro.

Come dice Livio, però, il ritardo di risposta non dice molto sull'effettivo comportamento dello slave a seguito della scrittura, quindi sarebbe un interesse più accademico che altro.

[Livio Orsini]

Quote

il ritardo di risposta non dice molto sull'effettivo comportamento dello slave a seguito della scrittura,

 

No Sandro, la misura come l'ho proposta nel primo messaggio è quella effettiva del tempo intercorrente tra l'invio del comando e la sua reale effettuazione.

L'ho proposta appositamente perchè so che intercorre sempre un certo ritardo tra l'effettiva attuazione e la comunicazione al master, specialmente con protocolli come modbus che non sono stati concepiti per il controllo in tempo reale.

[SandroCalligaro]

E' vero, ero rimasto alla domanda originale:

Quote

vorrei misurare il tempo che intercorre da quando il master dà il comando via Modbus (di posizionamento in questo caso) a quando il comando è ricevuto dallo slave

ma quella misura di per sé ha poca utilità.

[rguaresc]

Quote

ma quella misura di per sé ha poca utilità.

Perché fino a che non arriva il "Done" non si può mandare un altro messaggio.

Di recente ho provato con dei Rockwell Powerflex e dei Danfoss VLT e il tempo era identico come se le routine di gestione del Modbus fossero le stesse.

 

 

[Livio Orsini]

Quote

Perché fino a che non arriva il "Done" non si può mandare un altro messaggio.

 

Certo, ma io ho inteso che a Giobos interessasse l'effettivo ritardo tr invio del comando e sua effettuazione reale.

[SandroCalligaro]

Quote

Di recente ho provato con dei Rockwell Powerflex e dei Danfoss VLT e il tempo era identico come se le routine di gestione del Modbus fossero le stesse.

E' probabile che sia stata fatta in entrambi i casi la stessa scelta, mi aspetto che la comunicazione sia gestita in un processo con cadenza attorno al millisecondo.

[Livio Orsini]

Quote

mi aspetto che la comunicazione sia gestita in un processo con cadenza attorno al millisecondo.

 

Non è un bus di campo ma è una comunicazione da normale porta seriale. In genere questa comunicazione viene gestita a bassa priorità, nei "ritagli di tempo" della CPU.

Infatti rguaresc scrivava:

Quote

Il tempo tra quando il messaggio modbus arriva allo azionamento e quando questo risponde "Done" si aggira sui 50 millisecondi

 

Il fatto che questo ordine di grandezza di ritardo sia pressocchè costante su 2 marche differenti di inverter, conferma la bassa priorità di questa comunicazione.

[SandroCalligaro]

In effetti, sì, essendo "asincrono" l'arrivo dei pacchetti, la comunicazione quasi certamente è gestita nei ritardi di tempo, mentre l'attuazione degli I/Ot mi aspetto che sia gestita a cadenza fissa.

 

50 millisecondi a me sembrano tanti, a dire il vero, ma verificherò il ritardo sul drive che ho in laboratorio...

[Livio Orsini]

Quote

ma verificherò il ritardo sul drive che ho in laboratorio...

 

Visto che fai questa verifica, aresti anche quella dell'effettivo ritardo tra invio del comando e sua effettiva attuazione?

Questa misura è, a mio avviso, più interessante.

[SandroCalligaro]

Ho fatto una misura sulla comunicazione tra PC e drive Gefran ADV200 (vedi immagine).

La trasmissione lato PC è RS-232 (e su quella ho fatto la misura), il convertitore 232-485 non introduce ritardi apprezzabili.

 

Uso un adattatore USB Prolific, che stranamente ha lo stato di riposo che non è quello usuale, ma il pin viene portato a tensione positiva prima del bit di start).

 

Ho impostato gli I/O digitali in modo da portare in output la condizione !=0 su un parametro (intero a 32 bit).

 

La trasmissione è a 38400 baud, quindi la scrittura Modbus del parametro impiega poco più di 3.4 ms (13 byte, Preset Multiple Registers). Se il dato fosse a 16 bit si potrebbe accorciare questo tempo a circa 2.1 ms (Preset Single Register).

Il ritardo di attuazione, cioè tra la fine della trasmissione del pacchetto e l'effettiva attuazione (cambio di stato dell'uscita digitale) è di circa altrettanti 3 ms.

La variabilità del ritardo di attuazione è abbastanza marcata, circa ±0.3 ms.

 

La risposta di conferma della scrittura (non visibile nell'immagine, perché ovviamente è sul pin "RX") avviene a cavallo dell'attuazione (inizia circa 0,8 ms prima del fronte), e dato che comprende 8 byte impiega circa 2.1 ms.

[rguaresc]

I dati di quell'azionamento sono molto interessanti, un ciclo < 10 ms.
Ipotizzando di:
1-Interrogare l stato 10 ms
2-assegnare la frequenza 10 ms
Elaborare il confronto fra lo stato e il comando di Start/Stop da darsi solo quando serve che per azionamenti tranquilli come pompe e ventilatori e' praticamente mai 0 ms
In un secondo si possono governare 1000 / 20 = 50 inverter, mentre se anche si interroga la corrente e il feedback di frequenza 25 inverter.
Quelli con cui ho provato erano molto piu' lenti.
 

[Livio Orsini]

Quell'inverter è abbastanza veloce, però bisognerebbe forse vedere in che condizioni sta lavorando ovvero il carico di lavoro della CPU per le regolazioni.

hai provato a chedere a gerenzano se hanno fatto delle caratterizzazioni per la linea seriale (presumo che sia un prodotto dello stabilimento di Gerenzano).

[SandroCalligaro]

In effetti, chissà perché, non ci avevo pensato: le prove erano fatte a drive disabilitato.

Visto che non mi costava molta fatica, ho rifatto la prova con drive abilitato (in sensorless per sincrono a magneti permanenti, che è una condizione tra le più gravose per il processore).

 

I risultati sono praticamente identici, cioè sempre <6.5 ms tra inizio della scrittura ed attuazione dell'uscita digitale.

Il ciclo completo, cioè dall'inizio della scrittura alla fine della risposta (compresa ovviamente l'attuazione effettiva, che avviene durante la trasmissione della risposta) dura meno di 8 ms.

 

Il fatto che non ci sia praticamente differenza tra drive abilitato e disabilitato fa capire che il margine sul tempo di esecuzione del processore è piuttosto ampio (appunto per permettere la comunicazione e l'esecuzione del codice PLC internamente al drive). Nel mio caso sul drive non era caricato codice PLC, mi aspetto che i tempi possano cambiare con un'applicazione PLC "pesante" (come ad esempio il posizionatore, che il costruttore propone).

[Livio Orsini]

Si. Se ricordo bene la parte posizionamentoè ad alta priorità, inferiore solo alla priorità di regolazione.

Che processore monta?