Nuovo Progetto On-line / Il Plc Di Plc Forum (e Non Solo...)

[Livio Orsini]

Io userei il terminalino come master di Modbus ASCII.

Questo dispositivo non ha praticamente nulla da fare.

Gestire 4 tasti 8 LEDS ed un display 2x16 è praticamente una sinecura . Ha tutto il tempo di gestire il bus come master.

In questo modo usiamo un bus standard e molto diffuso.

Al limite si tratta di dover scrivere 2 righe di specifiche sui comandi.

[Gabriele Riva]

Il PIC comunica col Cubloc in I2C

La stessa I2C, tramite driver P82B715 è portata in morsettiera.

In questo modo possono coesistere più display.

Livio, ma sull'I2C puo' passarci Modbus?

[Livio Orsini]

Livio, ma sull'I2C puo' passarci Modbus?

I2C è un protocollo ben preciso, messo a punto da philips.

Il limite è la distanza del collegamento; non lo ricordo a memoria ma credo sia di circa un paio di metri.

Se invece si usa Modbus, magari con RS485, si può andare anche molto più lontano.

Bisogna che mi riguardi gli schemi del tastierino

[Gabriele Riva]

Avevamo messo apposta il driver P82B715 per potare l'I2C a lunga distanza, ricordi?

Mentre il PIC in locale è collegato diretto al Cubloc in I2C

[sandro66]

Dallo schema (foglio 8) il collegamento sembra fatto in I2C.

Io sfrutterei la capacità dei utilizzare contemporaneamente le capacita Master e Slave del Cubloc.

IL PLC è master verso la sua rete modbus e slave verso un eventuale Master esterno (PC/SCADA)

Io proporrei di usare una delle seriali disponibili eccetto la COM1 che e' l'unica utilizzabile come modbus slave.

E' sicuramente possibile implementare la comunicazione del tastierino in I2C, ricordando pero' che il cubloc e' sempre un master, personalmente la sconsiglierei per il fatto che è una comunicazione sincrona, seppur molto veloce si rischia di caricare la cpu del cubloc di tempo computazionale sprecato.

L'utilizzo di una delle seriali permette la gestione su interrupt e si puo' sfruttare il buffer a disposizione, il protocollo potrebbe essere ad hoc molto semplificato.

Come suggerito da Livio il tastierino potrebbe essere uno slave della rete modbus, ma vista la natura della comunicazione prettamente ASCII sarebbe necessario scrivere molto codice per trasmettere una semplice stringa (byte a byte).

Rimane il problema dei PCB gia' fatti!!

Utilizzare il tastierino come master si preclude la possibilita' di utilizzare uno SCADA esterno come master, o anche una semplice applicazione scritta in VB con driver modbus, la roba che si trova in giro per il PC e quasi tutta in modalita' master.

Modificato: 6 febbraio 2010 da sandro66

[Gabriele Riva]

Come puoi vedere sono anche previste 2 seriali 485 che vanno verso l'esterno, si possono usare quelle.

La linea seriale tra PIC e Cubloc si puo' dirottare facendo 2 filini... (sono comunque dei prototipi)

[Ing_DeMA75]

non conosco il vostro progetto ma tempo addietro avevo visto su un sito inglese un cublogic che gestiva la seriale verso un display touch da commercio, penso sia piu semplice gestire un ModBus Master lato cublogic (in teoria basterebbe anche una sola interrogazione in lettura /scrittura multipla per scambiare sino a 255byte), lasciando la parte slave al'Hmi

[sandro66]

sicuramente si'. Come accennavo prima, utilizzare la comunicazione modbus tra tastierino e CUBLOC non porterebbe nessun vantaggio.

Inoltre si rischia di inchiodare il bus alle caratteristiche del tastierino (velocita' e modalita' ASCII/RTU), sarebbe sempre necessario "pollarlo" per sapere se ci sono dati da scambiare.

Con una semplice connessione seriale invece, (anche a livello TTL) quando il tastierino invia dati si scatena l'interrupt nel cubloc, se poi il processore e' impegnato bufferizza il tutto e lo riprende successivamente.. Stessa cosa lato Pic, quando il cubloc deve trasmettere qualcosa al tastierino invia i dati sulla seriale e poi il Pic si arrangia per il resto.

A me sembra abbastanza efficiente, Livio cosa ne pensi?

[Livio Orsini]

Usare RTU è più efficiente di ASCII, l'unico inconvemiente è il CRC più pesante.

Detto in italiano corrente.

Io penso di tenere Master i tastierino perchè non ha molto da fare, mentre la CPU del Cubloc deve fare un sacco di cose e la sua potenza non è poi eccezionale.

Se e dove fosse necessario usare un dispositivo HMI potente, come un PC, potrebbe diventare master ed il tastierino essere usato come uno degli slave modbus. E' abbastanza semplice. Basta caricare sia il firmware master, sia quello slave. Di default parte in master poi con un parametro, selezionabile localmente, si passa al modo slave. Il parametro lo si può memorizzare in EEProm ed è testato sul Power On - reset. E' un metodo che ho gia usato fin da almeno un.... bidecennio

Il bus I2C lo lascerei ad uso esclusivo degli I/O di campo; per esperienza è sempre meglio tenere separati i gruppi funzionali.

[Ing_DeMA75]

penso che lo slave (cublog) sia più oneroso da gestire perchè si devono considerare i time out del master e quindi in pratica si deve rispondere "subito" se si utilizzano prodotti terzi.. invece la funzione di master , potrebbe cadenziare le interrogazioni anche in modo più blando..se vogliamo essere stringati, identificando un solo vettori dati in lettura/scrittura , il calcolo del crc per la lettura potrebbe essere parametrizzato, non possibile invece nella scrittura, ma qui lo si calcola solo se cublog DEVE comunicare il dato al touch.

[Livio Orsini]

<u>ma qui lo si calcola solo se cublog DEVE comunicare il dato al touch</u>.

<br>Al termine di ogni trasmissione, l'ultimo byte è la firma o CRC, quindi il confronto va fatto sia in trasmissione che in ricezione. Se è protocollo ASCII è molto più leggero. Se la parte HMI è limitata a tastierini sul tipo di quello proposto la stringa più lunga è un 2x16 caratteri, quindi 32 bytes se si usa il protocollo ASCII.<br><br>

..<span class="postcolor">in pratica si deve rispondere "subito" ...</span>

<br>No, questo non è obbligatorio. Oltre ad un tempo limite impostabile, la risposta può essere frazionata su più pacchetti. E' una tecnica abbastanza usata.<br>Inoltre un dispositivo master deve gestire tutte le comunicazioni tra i vari dispositivi.<br>Pensa al caso di 3 displaies remotati; uno funge da master e gestisce lo scambio dati con CPU accollandosi tutto il traffico.<br>Nel caso di un dispositivo HMI più potente, come un PC, è anche più logico che sia lo stesso HMI a fungere da master di comunicazione.<br>Ricordiamoci che la CPU PLC, come compito prioritario, deve gestire l'automazione, non l'interfaccia uomo-macchina.<br>Avviene solitamente così, anche se non lo si dice in chiaro, nei sistemi PLC con HMI su porta seriale. Il PC, o altro dispositivo HMI, interroga o invia i dati al PLC, non viceversa. <br>Differente è il caso in cui si usa un field bus, dove viene impiegata un'apposita unità di comunicazione anche se, a volte, non appare perchè integrata nello Hw di cpu. C'è sempre e comunque un processore dedicato alla comunicazione che lavora in modo indipendente ed asincrono dal processore dedicato all'automazione.<br><br>

[sandro66]

Una delle comodita' nel gestire il cubloc come slave modbus (ricordo esempre che solo sulla porta com1) e' che non bisogna scrivere una riga di codice sul cubloc, la gestione del protocollo e' integrata nel firmware e del tutto trasparente e asincrona rispetto al programma(i) che girano su di esso, come pure le temporizzazioni.

Per quanto riguarda il master/slave dinamico si puo' fare sicuramente.

PS

uno dei motivi per il quale consigliavo la seriale e' quello di poter sfruttare la porta do download, e con essa tutta la potenza dei comandi di debug del cubloc, una sorta di hyper terminal su pic.

Modificato: 7 febbraio 2010 da sandro66

[Gabriele Riva]

ricordo esempre che solo sulla porta com1

Sandro,

la com1 del CB405 sono i pin57-58 (P42-P43) giusto?

[Livio Orsini]

Una delle comodita' nel gestire il cubloc .....

Altro motivo che condivido in pieno.

[sandro66]

Si Gabriele le porte sono P42 e P43 ma ricorda che sono a livello TTL, il driver integrato e' stato sfruttato nel tuo caso dalla com3 (TTL su pin 61/62 e Rs232 su pin 41/42.

Per chiarezza ti invio per posta lo schema della cubase40 che adotta il CB405.

[Gabriele Riva]

Si, grazie Sandro

lo schema era gia' tra le mie stampe che ho utilizzato per il progetto,

se guardi lo schema trovi che i pin 57-58 vanno al driver SN75176 per poi andare in morsettiera.

Ora si tratta di stabilire la modifica per collegare anche il PIC integrato nel PLC.

Bisognerà interporre sulla linea seriale del PIC un'ulteriore SN75176 in modo che poi tutti i dispositivi (a bordo o remoti) siano tutti sullo stesso bus RS485, giusto?

Ma il driver integrato converte da TTL a RS232 a noi cosa serve?

[Livio Orsini]

Gabriele domani mi ristudio gli schemi del tastierino e del Cubloc versione PLCForum, poi faccio sapere il mio parere

[Gabriele Riva]

ok, Livio,

Sandro,

ora ricordo, lo schema che mi hai mandato, non l'avevo preso in considerazione in quanto ci dovrebbe essere un'errore in quanto i pin 41-42 sono l'uscita RS232 +/-12V del driver integrato e loro li hanno mandati al Max485 il quale ha gli ingressi TTL

o mi sono perso qualcosa?

[Livio Orsini]

Dunque cerco di ricapitolare le idee. Le scrivo qui invece che mandare una mail a Gabriele perchè potrebero servire per chiarire le idee anche ad altri partecipanti.

Ho riguardato gli schemi e ho ripensatoai ragionamenti fatti a suo tempo.

C'è una cosa, però, di cui non son sicuro (E' un anno che non lo riguardo). Il tastierino è collegato con un flat alla CPU Cubloc. Se non ho interpretato male lo schema, sul flat si portano 4 canali analogici per altrettanti A/D e le due linee per l'I2C.

A questo punto, quando si usa il tastierino a livello locale si è praticamente obbligati all'uso di questo bus. Sempre che la mia supposizione sia corretta.

Poi rimangono disponibili le porte per un'altra seriale, che andrebbe portata a morsettiere e andrebbe poi interfacciata estrenamente con un chip per 232 o per 485

Gabriele confermi?

[Gabriele Riva]

Si e no, ci sentiamo telefonicamente, è troppo lunga da spiegare.

Nel frattempo attendiamo Sandro per i chiarimenti sul driver 232 integrato nel CB305.

[sandro66]

domani faccio un rilievo dalla scheda cubase40 per controllare eventuali discordanze con gli schemi.

Ricapitolando, il CB405 ha 4 porte seriali, una a livello RS232 CH0 (download e debug) che puo essere usata anche come porta aggiuntiva standard, e 3 porte a livello TTL (CH1,2,3), solo la porta CH1 è utilizzabile come slave modbus sfruttando il firmware a bordo.

Da un veloce controllo fatto sugli schemi di Gabriele il collegamento tra il PIC e il CB405 risulta fatto con I2C, soluzione che sembra decadere.

Il driver a bordo del Cb405 potrebbe anche rimanere inutilizzato se si usano driver esterni.

Rimane da decidere modalita e protocollo tra CB405 e PIC. Dalle discussioni emergono 2 possibili alternative.

(ampia liberta a proposte alternative). La prima in parte condivisibile è quella di Livio, usare il CH1 il modalità modbus slave, usare il PIC come master Modbus e commutarlo in slave nel caso si conneta un PC Master. Questa soluzione ha però un lato negativo, quando si connette il PC il tastierino è praticamente escluso a causa del fatto che sia il tastierino (PIC) che il Cubloc sono entrambi slave, come sapete, 2 slave non possono dialogare direttamente ma solo tramite il master, a meno di scrivere codice specifico lato master PC. Questo però precluderebbe la possibilità di usare un master "commerciale" o comunque standard e comunque usciremmo fuori specifica modbus. La seconda strada è quella da me proposta, ovvero sfruttare il CH0 di programmazione per semplificare anche il firmware del pic, lo svantaggio è quello di dover definire un nuovo protocollo o appoggiarsi a qualcosa di esistente, e di dover dotare il PIC di un driver RS232 per agganciarsi al CH0 del CB405, che se non sbaglio è destinata attualmente solo per la programmazione del CB405. Rimarrebbero quindi a disposizione 3 porte, CH1 come slave Modbus, CH3 come master Modbus e CH2 come ulteriore master o porta specifica per altri usi.

[sandro66]

Gabriele,

ho ridato uno sguardo allo schema che ti ho mandato, la porta connessa al driver integrato è la CH1.

I pin 57/58 sono l'uscita a livello TTL della seriale,

essi sono connessi ai pin 61/62 che sono l'ingresso TTL del driver e l'uscita

del driver,pin 41/42 (TXE/RXE), e' connessa alla porta sub D9 di CH1.

A me sembra corretto.

[Gabriele Riva]

E' vero, Sandro, ho fatto confusione io, scusami

Per la gestione, sentiamo il parere di Livio, stasera telefonicamente mi diceva che per il display/tasti/led a bordo, potremmo lasciarli in I2C e gli altri pannelli operatori/PC/Scada eventuali in campo li colleghiamo ad una delle 2 RS485 a disposizione.

Faccio un po' di riepilogo delle seriali a bordo del PLC di PLC Forum per rinfrescarmi la memoria:

CH0 - RS232 (download e debug) portata sul frontale a destra su un DB9-F

CH1 - RS485 (utilizzabile come slave modbus sfruttando il firmware a bordo) portata in morsettiera M6

CH2 - RS485 portata in morsettiera M6

CH3 - RS232 (per la conversione TTL/RS232 utilizza il driver interno al Cubloc) portata sul conettore estraibile J8 a 4 poli (vi è anche l'alimentazione 5V e GND per collegare un'eventuale XPort)

I2C - portata in morsettiera M6 tramite driver P82B715 per permettere il collegamento di dispositivi I2C a lunga distanza (parlano di 2/3 miglia)

Cunet - portata in morsettiera M6 tramite driver P82B715

PS.: nel frattempo sto' preparando il materiale per montare altri 2 prototipi.

[Livio Orsini]

Sto rifacendo tutti i ragionamenti lasciati in sospese da più di un anno quindi, a volte, potrei anche contraddirmi.

..sia il tastierino (PIC) che il Cubloc sono entrambi slave, come sapete, 2 slave non possono dialogare direttamente ma solo tramite il master,...

Questo mi sembra un fastidio di poco conto. Se si decide di usare, in un'applicazione, un master esterno ne discende automaticamente che o il tastierino è a bordo della CPU o, se remotato, ha funzioni molto marginali, quasi di emergenza.

Nel primo caso non ci sono problemi. Se il tastierino è a bordo comunica in I2C.

Nel secondo caso c'è un problema esclusivamente quando il master è non funzionante, salvo un appesantimento dei telegrammi dis cambio dati. Nel caso di un crash del master si potrebbe prevedere una commutazione, con comando da tastiera, da slave a master.

[sandro66]

La cosa non mi è ancora del tutto chiara..

Il tastierino deve comunicare in I2C, in Modbus o altro?

1) in I2C è possibile, con qualche sacrificio computazionale dal parte de cubloc poichè necessariamente il cubloc deve essere master (la sola modalità possibile)

2) in modbus il tastierino dovrebbe essere master ma quando si collega un altro master sulla stessa seriale esso si scollega necessariamente

3) modalita' mista ? pulsanti e led in I2C e display in modbus?? o altro ??

Livio cerca di essere più chiaro, sono un po' duro di comprensione!!