Protocollo Modbus - implementazione....

[luciopro]

Salve ragazzi, io ed un mio collega stiamo realizzando l'implementazione del protocollo modbus rtu su dei micro PIC 16 f877a.

Il quesito che vi pongo è il seguente:

--abbiamo analizzato le specifiche del protocollo, e si nota la necessiata di controlloare esettamente il tempo tra l'arrivo dei due messaggi, per verificare se ci sono errori di trasmissione e fin qui nessun problema......tuttavia cercando in rete abbiamo trovato vari esempi di comunicazione modbus rtu, ma nessun programmatore si è preoccupato minimamente di verificare tale tempistiche!!!!!!!

Questo fatto è dovuto ad una maggior semplicità di programmazione, oppure effettivamente non considerano le tempistiche per evitare problemi durante la trasmissione (ritardi inseriti dal cavo, interferenze ecc..)

Cosa mi consigliate di fare implementare tale controllo oppure trascurarlo completamente.

Grazie

[elsabz]

Non specifichi per cosa ti serve e quindi risulta difficile risponderti sulla tempistica, in effetti nel prot. modbus non viene data alcuna importanza al tempo, l'iportante è che quando il master chiama uno slave, lo stesso se la ceck-sum è coretta risponde immediatamente. Io ho realizzato una piccola parte del protocollo modbus (funzione 03 come slave), propio sullo stesso PIC16F877A e mi sono trovato bene, per quello che mi serviva, l'unica cosa, se ricordo bene è che ho dovuto usare l'interrupt sulla seriale in ricezione, altrimenti c'erano grossi problemi! Trovo che il protocollo modbus sia un protocollo semplice e di facile integrazione, pertanto se non sono richieste grosse prestazioni, direi che è l'ideale per comunicare pochi dati con strumentazione, plc, pc ecc. ecc.

Ciao!

[luciopro]

ciao elsabz, non ho specifcatoa cosa mi serve hai ragione. Abbiamo intenzione di realizzare qualche schedina (acquisizione ingressi, comando uscite, sensori di temperature, dimmer, pannelli ) da collegare ad un twido per fare della domotica........siamo pazzi lo so ma ci stiamo divertendo la faccia!!!! Pensa che la casa di miop padre (64 anni) e mia madre (62 anni), la uso per fare le prove :D

Ho dato un occhiata al manuale e non mi sembra che le tempistiche il modbus se ne freghi, anzi sono molto importanti.

tratto dalle specifiche.

In RTU mode, messages start with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of character times at the baud rate that is being used on the network (shown as T1-T2-T3-T4 in the figure below). The first field then transmitted is the device address.

The allowable characters transmitted for all fields are hexadecimal 0 ... 9, A ... F. Networked devices monitor the network bus continuously, including during the silent intervals. When the first field (the address field) is received, each device decodes it to find out if it is the addressed device.

Following the last transmitted character, a similar interval of at least 3.5 character times marks the end of the message. A new message can begin after this interval.

The entire message frame must be transmitted as a continuous stream. If a silent interval of more than 1.5 character times occurs before completion of the frame, the receiving device flushes the incomplete message and assumes that the next byte will be the address field of a new message.

Similarly, if a new message begins earlier than 3.5 character times following a previous message, the receiving device will consider it a continuation of the previous message. This will set an error, as the value in the final CRC field will not be valid for the combined messages. A typical message frame is shown below.

Per ora abbiamo realizzato una semplice comunizazione ascii e funziona senza problemi. Ora il dilemma è quello che ho detto prima:possiamo realizzare il modbus come ci richiede il protocollo pari pari, con spreco di memoria, tempo per la realizzazione ecc. e magari trovarci a lavoro finito che il controllo delle tempistiche ci fa interpretare tutti i messaggi come errati!!!!pensa che colpo.

Ecco perchè mi chiedevo se era volutamente trascurato per ebitare tale problema.......

un'altra cosa molti non considerano neanche la parità ma solo il crc.

Approposito dato che hai gia implementato il modbus me lo mandi, cosi non impazziamo a farlo..... ...scherzo comunque se ti va ci confrontiamo.

scusami se sono stato un po lungo (che eufemismo..........)

[elsabz]

Ciao Luciopro,

quindi se ho capito bene voi volete fare degli slave modbus RTU che comunicano con un master, giusto?

Non ha molta importanza ma per curiosità di che master modbus RTU si tratta, un PC un PLC?

L'anno scorso ho collegato il PIC con un RS485 transreciver direttamente sui PIN della gestione seriale e poi ho sviluppato il software con linguaggio C utilizzando il compilatore PICC Lite in MPLAB-IDE.

Ho testato il tutto con SCADA Movicon in modalità modbus master RTU e con un PLC VIPA con scheda CP240 in modalità master. La cosa funziona egregiamente e non ho nemmeno considerato la questione tempistica, di cui non ne conosco nemmeno le speciiche in dettaglio.

Quello che hai postato mi sembrano delle specifiche che parlano del formato dei dati, tempo intercarattere, frame ecc. ecc., ma non mi sembra determinante, perche il PIC è liberamente configurabile per queste cose, per altro standard nelle comunicazioni seriali.

Quando il master invia una richiesta e lo slave la elabora con successo allora risponde immediatamente, se il tempo di polling del master è molto veloce potrebbero magari insorgere dei problemi, ma se si tratta di domotica allora credo che il polling veloce non sia determinante e quindi il prot. modbus RTU va benissimo e direi che non ci sono problemi! O no?

Come ti ho detto il codice che ho realizzato è semplicemente quello che serve per far fare al PIC un modbus slave RTU con il solo telegramma 03 (Read holding register, se ricordo bene) che a mio parere per fare acquisizioni con pochi dati è più che sufficente, potrei anche postarlo se vuoi, anche se mi vergono un pochino in quanto questo software è il risultato di un mio primo approccio al C ed ai PIC, ma comunque, se ti interessa (usi anche tu il C? o programmi in assembler?), rivedendolo un pò posso farlo e magari insieme si può migliorare...

Ciao!

[luciopro]

ciao elsabz,

hai indovianto in pieno!!!!PLC Twido come master, e pensavo rete ethernet per scambiare dati tra i vari PLC.

La supervisione la vorrei fare in due modi: modo 1- pannello touch 5''

modo 2- Web server, è da poco uscito per il twido,ma aumentano molto i costi, sia per il costo del web server sia per il sitema di visualizzazione.

Anche noi programmiamo in c, o meglio, il mio compagno di disavventure lavora in una grossa ditta di progettazione software micro, ed una sera al pub dopo avere bevuto non so quante birre ci è venuta in mente questa idea. In commercio non esiste niente di simile, ma a parte questo ci si è appassionati anche per il fatto di passare un po di tempo insieme.

Cosi lui si occupa della programmazione in c, io gli faccio molto da palla al piede e mi occupo del lato PLC.

Quindi come ti dicevo ci siamo procurati tutto il necessario, fatto lo scheletro del software (dialogo con il display, acquisizione della temperatura, ecc) ed ora si passa alla realizzazione del modbus.

Ci siamo studiati le specifiche, a dire il vero lui è sceso molto + nel dettaglio di me, e ora si va a scrivere il codice.

Rimaneva solo il fatto di sapere se implementare il modbus in dettaglio oppure semplificarlo un poco.

Se un domani qualcuno ci chiedesse delle schedine (eventuale vendita a terzi, non è da trascurare) sarebbe meglio rispettare alla lettera il protocollo , oppure barare un po e magari evitare di perdere giustamente dei pacchetti se non corrispondono alle specifiche. Sempificare il protocollo può ache avere il vantaggio di potere utilizzare un micro + piccolo, quindi costi inferiori, oltre che ad un risparmio di tempo nella stesura del software e nella fase di debug.

S elo posti e ti interessa, possiamo confrontarci, e non ti preoccupare sono anche io ai primi approcci al C, ma magari confrontandoci ed avendo qualcuno che lo fa di mestiere si possono imparare tante cose nuove. Ciao e tiemi informato.

[elsabz]

Ciao a tutti,

ecco questo è il codice per far fare al PIC lo slave modbus RTU con il solo telegramma 03 (Read Holding Register). Quindi il master fa una richiesta e il PIC se la richiesta è indirizzata a lui e non ci sono errori di cek-sum, risponde alla richiesta immediatamente. L'area dati complessiva prevista per questa applicazione è di 8 byte complessivi 4 valori di registro 16bit, nei quali è possibile scrivere i dati desiderati da inviare al master (Vedi blocco Trasmissione MODBUS>Valore registroX). Importante sapere che nella configurazione del telegramma del master, la richiesta deve sempre partire dal primo registro quindi 0 (questo è un limite del codice sottoriportato!).

Spero sia comprensibile, consiglio di provarlo e poi se c'è qualche dubbio resto a disposizione.

Buon lavoro, ciao!

#include <pic.h>

#include "delay.c"

unsigned int crc_calc(char *pcode , unsigned int len);

unsigned char C1,C2,C3,C4,RxPos,Flags;

char rx_ok=0;

static bank1 unsigned char rx_buf[10]; //Buffer ricezione USART

static bank1 unsigned char tx_buf[10]; //Buffer trasmissione USART

char i=0; //int

char xx=0; //int

char cc=0;

main()

{

//**************************************************************

// RC6= TX MAX485

// RC7= RX MAX485

// RC2= DE/RE MAX485 - DE/RE=0 > RX ATTIVA TX DISATTIVA; DE/RE=1 > RX DISATTIVA TX ATTIVA

//**************************************************************

TRISA= 0b00000000;

TRISB= 0b00000000;

TRISC= 0b10000000;

TRISD= 0b00000000;

TRISE= 0b00000000;

ADCON1 = 0b00000110; // set PORTA pin 0 for analog, rest forDIGITAL I/O

PORTA= 0b00000000;

PORTB= 0b00000000;

PORTC= 0b00000000;

PORTD= 0b00000000;

PORTE= 0b00000000;

//Inizializzazione interrupt

INTCON = 0; // Interrupt disabilitato

PIE1 = 0; // Interrupt di periferica disabilitati

GIE = 1; // Global Interrupt Enable

PEIE = 1; // Periferal Interrupt Enable

RCIE = 1; // USART Receive Interrupt Enable

//Inizializzazione uart

TXSTA= 0x00; // TX abilitato

RCSTA= 0X90; // Registro RX USART

BRGH = 1; // USART High velocity

SPBRG= 25; // Baud Rate Generator (25=9600 baud)

RxPos=0;

Flags=0;

RC2=0;

while(1) //ripete il ciclo all'infinito

{

//Valutazione telegramma MODBUS ricevuto

if(Flags) {

if(rx_buf[0]==0x02) { //Numero di slave cui è stata fatta la richiesta

if(rx_buf[1]==0x03) { //Tipo di incarico (03=read holding registers)

if(rx_buf[2]==0x00) { //Indirizzo di partenza (byte alto)

if(rx_buf[3]==0x00) { //Indirizzo di partenza (byte basso)

if(rx_buf[4]==0x00) { //Numero di word richieste (byte alto)

if((rx_buf[5]<=0x04)&&(rx_buf[5]!=0x00)) { //Numero di word richieste (byte basso)

cc=crc_calc(rx_buf,6);

if(rx_buf[6]==cc) { //(rx_buf[6]==0x84) //CRC (byte basso)

cc=(crc_calc(rx_buf,6)>>8);

if(rx_buf[7]==cc) { //(rx_buf[7]==0x39) //CRC (byte alto)

rx_ok=1;

Flags=0;

}

}

}

}

}

}

}

}

}

if(rx_ok) { //Trasmissione MODBUS

RC2=1;

rx_ok=0;

tx_buf[0]=0x02; //Indirizzo MODBUS

tx_buf[1]=0x03; //Funzione 03

tx_buf[2]=(rx_buf[5]*2); //Numero di byte dati di ritorno

tx_buf[3]=1; //Valore registro1 (byte alto)

tx_buf[4]=2; //Valore registro1 (byte basso)

tx_buf[5]=3; //Valore registro2 (byte alto)

tx_buf[6]=4; //Valore registro2 (byte basso)

tx_buf[7]=5; //Valore registro3 (byte alto)

tx_buf[8]=6; //Valore registro3 (byte basso)

tx_buf[9]=7; //Valore registro4 (byte alto)

tx_buf[10]=8; //Valore registro4 (byte basso)

tx_buf[(3+(rx_buf[5]*2))]=(crc_calc(tx_buf,(3+(rx_buf[5]*2)))); //CRC (byte basso)

tx_buf[(4+(rx_buf[5]*2))]=(crc_calc(tx_buf,(3+(rx_buf[5]*2)))>>8); //CRC (byte alto)

for(xx=0; xx <= (4+(rx_buf[5]*2)); xx ++) { // ciclo di 8 caratteri da iviare

TXREG=tx_buf[xx]; // scrive il registro TXREG

TXEN=1; // abilita la trasmissione

while(!TRMT) {} // aspetta che il registro TSR sia vuoto

TXEN=0; // disabilita la trasmissione

}

xx=0;

RC2=0;

}

}

}

//*************************************************************************************************//

//** Funzione per il calcolo del CRC **************************************************************//

//*************************************************************************************************//

unsigned int crc_calc(char *pcode , unsigned int len) {

unsigned int crc=0xFFFF; //Inizializzazione del registro CRC con tutti '1'

int z=0;

int y=0;

for(z=0;z < len; z++) {

crc=crc^pcode[z];

for(y=1;y<=8;y++) {

if(crc&0x0001) {

crc=crc>>1;

crc=crc^0xA001;

}

else crc=crc>>1;

}

}

return crc;

}

//*************************************************************************************************//

//*************************************************************************************************//

//*************************************************************************************************//

//** Ricezione di un byte per volta con interrupt *************************************************//

//*************************************************************************************************//

void interrupt SerChar(void) //prototipo ricezione

{

if(RxPos>7) RxPos= 0;

rx_buf[RxPos]=RCREG;

RxPos++;

if(RxPos>7) Flags=1;

}

//*************************************************************************************************//

//*************************************************************************************************//

[luciopro]

ciao grazie elsabz, appena posso lo facco vedere al mio collega e poi ti tengo informato.

ciao

[omar]

Intervengo nella discussione (spero non a sproposito) perchè sto giusto provando uno slave modbus RTU implementato su un ATMega128. All'indirizzo http://www.modbus.org troverai le specifiche per implementare il protocollo su seriale (Modbus_over_serial_application.pdf) che toccano anche la problematica relativa ad esempio al ritardo tra un carattere e l'altro etc. Per quello che riguarda il timing per il fine frame ti consiglio di implementarlo bene, rischi altrimenti di non riuscire a capire perchè a volte il frame è ok e altre no. per il test ti consiglio il pacchetto modbus tester che puoi trovare all'indirizzo http://www.modbus.pl, è semplice ed efficace.

Saluti

[suibaf]

Intervengo nella discussione (spero non a sproposito) perchè sto giusto provando uno slave modbus RTU implementato su un ATMega128

[omar]

Ciao che linguaggio usi per programmare gli ATMega

Modificato: 8 marzo 2005 da omar

[luciopro]

grazie ragazzi,

stasera inizio a scrivere il codice.

Accetto i consigli e provo ad implementare il protocollo "a regola d'arte" (sono ottimista).

Vi farò sapere

ciao

[luciopro]

salve ragazzi,

come vedete vi torno a disturbare.

Abbiamo iniziato a scrivere la macchina a stati per la comunicazione modbus rtu e ci sono sorti i primi due quesiti. Vediamo se qualcuno mi può aiutare.

punto 1: sempre per risparmiare memoria, non vogliamo implementare tutti i comandi, ma solo alcuni (i primi 10 +o-).

Quindi per realizzare questi comandi è sufficiente predisporre un buffer di ricezione di 8 byte.

La domanda è questa: se un modbus-master, manda una richiesta al mio slave, con un comando errato (errato nel senso che l'indirizzo dello slave è corretto, ma il comando non è supportato, e soprattutto ha un alunghezza maggiore del mio buffer) come mi devo comportare?? Poso fregarmene di quello che mi sta dicendo (attraverso la gestione del buffer-full) e non riportargli nessun codice di errore??? In caso contrario che codice di errore devo spedire al master??

punto 2: tempistiche.

Premessa: abbiamo reaizzati due macchine a stati: la prima ad interrupt, controlla i time-out e la ricezione sulla seriale. La seconda ciclica che elabora il comando e formatta la risposta.

Vediamo se riesco a spiegarmi. Nella trasmissione modbus esistono due controlli sul tempo: il primo controllo rappresenta la distanza massima tra 2 caratteri consecutici (tempo pari a 1,5x tempo durata carattere), ed i tempo minimo tra 2 comandi successivi (tempo pari a 3,5 x tempo di un carattere). Supponiamo che mi arrivi un comando corretto (CRC ok, parity ok, adress ok9. A questo punto il comando viene passato alla seconda macchina che si occupa di preparare la risposta.

Fin qui nessun problema. Il quesito è il seguente: mentre la seconda macchina (quella ciclica che formatta la risposta) sta lavorando, devo rimanere in ascolto sulla seriale o posso disabilitare gli interrupt, in modo da non ricevere un altro comando mentre sto rispondendo al primo??? Se mi arrivano più comandi mentre sto ancora rispondendo al primo, li devo memeorizzare e rispondergli in seguito, oppure posso non considerali??

grazie a tutti

[elsabz]

Ciao Luciopro,

direi che è meglio che torni al pub a bere birre con il tuo collega!!!

Scherzi a parte: hai provato il codice che ti ho postato?

punto 1: sempre per risparmiare memoria, non vogliamo implementare tutti i comandi, ma solo alcuni (i primi 10 +o-).

[omar]

La domanda è questa: se un modbus-master, manda una richiesta al mio slave, con un comando errato (errato nel senso che l'indirizzo dello slave è corretto, ma il comando non è supportato, e soprattutto ha un alunghezza maggiore del mio buffer) come mi devo comportare?? Poso fregarmene di quello che mi sta dicendo (attraverso la gestione del buffer-full) e non riportargli nessun codice di errore??? In caso contrario che codice di errore devo spedire al master??

[luciopro]

Ciao Luciopro,

direi che è meglio che torni al pub a bere birre con il tuo collega!!! tongue.gif biggrin.gif tongue.gif

Scherzi a parte: hai provato il codice che ti ho postato?

[luciopro]

a scusate, sono maleducato...grazie per l'interessamento.

[omar]

omar come vedi ti rompo un po le scatole

Modificato: 17 marzo 2005 da omar

[elsabz]

S elo posti e ti interessa, possiamo confrontarci, e non ti preoccupare sono anche io ai primi approcci al C, ma magari confrontandoci ed avendo qualcuno che lo fa di mestiere si possono imparare tante cose nuove. Ciao e tiemi informato.

[luciopro]

grazie ragazzi per le risposte.............

omar sei stato chiarissimo......grazie

elsabz, mi scuso se non ho provato il tuo software..non è per mancanza di fiducia o perchè penso che il tuo software non funziona, ma solo per mancanza di tempo.

come detto in precedenza e anche come ribadito da omar, vorremo cercare di implementare il protocollo modbus RTU alla lettera, rispettando il + possibile e specifiche.

Modbus RTU richiede OBBLIGATORIALMENTE oltre alle rispetto delle tempistiche, anche l'implementazione di alcuni comandi o caratteristiche (ad esmpio la parità pari deve essere obblicatoriamente implementata).

Se ti può interessare ti consiglio, come ha già detto omar di scaricarti le specifiche del protocollo (...ma penso che li hai già dal sito www.modbus.org).

in particolare le due macchine a stati di cui parlavo stamattina non sono altro che l'implementazione del "diagramma di flusso" (penso proprio che non sia il termine corretto) che trovi a pag.10/44 e 14/44 delle specifiche "Modbus_over_serial_line_V1.pdf" .

In aprticolare la macchina a stati implementata a pag.14/44 è quella che funziona ad interrupt sulla seriale e controlla il time-out. LA macchina a stati del main è quella a pag.10/44 che si occupa di formattare la risposta ed altri controllo.

Ogni stato di tale macchina è rappresentato dal quadrato del diagramma e la transizione avviene solo con le condizioni specificate dal diagramma.

Scusami se non sono stato chiaro, ma forse è un po difficile da spiegare.

Non ho messo codice perchè lo stiamo ancora implementato (lo abbiamo già rifatto 2 volte!!!!!), e anche perchè sinceramente io fungo da palla al piede.e molte cose le devo ancora capire

Per il momento sto cercando di capire come andrebbe implementato un progetto in c, in modo corretto (strutture, directory, file...) ma non è affatto semplice.

Comunque sto costringendo il mio collega ad iscriversi al forum e lui sicuramente potra essere molto più chiaro di me.

Comunque non ti preoccupare penso che si stia collaborando,e anche omar ne sa a pacchi...quindi elsabz, approffittiamone, svisceriamo questo protocollo. Avanto con le domande, io ne ho un sacco da fare

ciao

[elsabz]

Beh dopo che ti ho postato il codice ho aspettato circa 10 gg per darti il tempo di provarlo, quindi mi aspettavo un commento, del tipo: "l'ho provato e funziona..." oppure "l'ho provato e funziona ma........". Quando, dopo tanto tempo, non hai nemmeno accennato al codice che ti ho postato, non mi sembra che c'è l'intenzione di fare un confronto. comunque non ti preoccupare fai quello che credi e prenditi il tempo che vuoi!

Mi pare che abbiamo parlato di una piccola parte del protocollo modbus con qualche funzione implementata per piccole schede per fare domotica o acquisizione dati decentralizzata. Mi sembra che 10 funzioni sia esagerato, sopratutto penso che il PIC in questione 16F877 , in questo modo sia sovracaricato (14,3k max di programma). Non so se lo sai ma oltretutto con il compilatore PICC Lite sei limitato, mi sembra a 2k di programma, sempre che usi questo e se no che compilatore C usi?

Se tu implementi la funzione 03 read-holding register e la 04 write, penso che puoi fare tutto quello che serve, non sei obbligato ad implementare tutte le funzioni! Il discorso di omar sicuramente è corretto, ma ti assicuro che anche se non gestisci i codici di risposta illegali, funziona benissimo lo stesso, c'erto non è il massimo ma per pochi byte di dati va più che bene!!!!

Ciao!

[luciopro]

ciao elsabz, purtroppo questo è un progetto che realizziamo a tempo perso, il che significa un paio d'ore a settimana il mercoledi sera, sempre che io non sia fuori per trasferte, altrimenti si salta alla settimana successiva..............quindi i tempi sono lunghi.

Come compilatore stiamo usando il PICC versione demo (non il lite) e forse in futuro lo acquisteremo. Mi riferivo ai primi 10 comandi, perchè sono quelli con il frame + corto, non è detto che li implementeremo tutti e 10, questo si vedra in seguito.....

comunque a parte tutto penso che non sia una discussione molto sterile, tu hai postato come lo hai realizzato, omar ha postato la sua strategia ed io ho cercato di spiegare la mia. Penso che anche questo sia cofrontarsi, si sta secondo me entrando abbastanza in specifico nel Protocollo, e come si possono realizzare quei controlli che ti richiede (tempistiche, ceck e....). Prima di partire con il codice è necessario capire esattamente la cosa realizzarlo e come valutare le varie condizioni di allarme ( ad esempio cosa rispondere ad un comando errato ecc).

Capisco benissimo che funzioni anche senza tutti sti controlli, ma forse come dice omar è meglio rispettarle le specifiche altrimenti in casi di problemi come si fa ad individuare la causa.

grazie ragazzi,

stasera inizio a scrivere il codice.

Accetto i consigli e provo ad implementare il protocollo "a regola d'arte" (sono ottimista).

Vi farò sapere

ciao

[elsabz]

Come compilatore stiamo usando il PICC versione demo (non il lite)

[luciopro]

salve ragazzi si sta proseguendo ed il modbus ora funziona. A questo punto (anche se avremmo dovuto farlo prima) ci siamo messi ad analizzare le tempistiche di risposta del sistema e purtroppo abbiamo trovato dei limiti assurdi.........

Supponiamo di comunicare a 19200 bit/s.....

il frame di comndo supponiamo sia compostao da 10 caratteri (può variare a seconda del comando..ma facciamo finta di niente). Ogni carattere è formatoda 11 bit (frame+start+stop+paryta) e supponiamo che la risposta sia sempre di 10 caratteri. Ad ogni frame sia in risposta che in trasmissisione devo aggiungere il tempo di time out pari a 3,5 x tempo di carattere

Quindi in 1 sec ho la possibilità e di ricevere risposta al amssimo da:

Tempo trasmissione bit= 1000/19200= 0,05208333333

bit frame di interrogazione/ risposta = (10 caratteri + 3,5 x duratta di un carattere)x11 bit= 148,5 bit

termpo trasmissione frame interrogazione/risposta = 148,5 x 0,05208333333= 7,734 ms

quindi la comunicazione con lo slave comporta un tempo pari a 15,5 ms

In un secondo al massimo posso scambiare informazioni con 64,5 slave nelle migliori delle ipotesi!!!!

Ciò significa che se uso uno slave per leggero lo stato del pulsante ed un altro per comandare l'accensione di una lampada mi trovo un tempo di latenza da quando acquisisco il comando, a quando attivo l'uscita di 1 sec, e quindi non accettabile!!!!

Sbaglio qualcosa o effettivamente è un limite del protocollo...

grazie a tutti.......

[andrea.fa]

+ o - direi che c'e' poco da fare se non quello di aumentare la velocità e/o diminuire il numero di slave da pollare...

Tempo fa la mia azienda ha installato (su specifica del cliente) un sistema per l'accensione delle lampade in un grande magazzino basato su dei modulini che comunicano su un bus seriale "proprietario", e in effetti, nonostante il numero di slave mi pare non superasse la decina, c'era un ritardo notevole tra pressione di un pulsante e accensione del relativo banco di lampade tanto che l'iniziale comando premi-on/premi-off è stato sostituito da comandi separati di accensione e spegnimento altrimenti era da esaurimento nervoso riuscire ad utilizzarlo !

ciao

Andrea

[ifachsoftware]

Ciò significa che se uso uno slave per leggero lo stato del pulsante ed un altro per comandare l'accensione di una lampada mi trovo un tempo di latenza da quando acquisisco il comando, a quando attivo l'uscita di 1 sec, e quindi non accettabile!!!!