Reset Dei Marker Informazione Sullo Stato Iniziale Dei Marker - il più presto possibile, se possibile :)

[Grandegiove]

Ciao a tutti,

mi servirebbe un informazione al più presto possibile, se possibile:)

Sono alla prese con l'interpretazione di un programma Ladder scritto con PLProg per un PL260 della Pixsys, ma se siete esperti di altri plc spero mi possiate aiutare comunque

Qualcuno mi sa dire se i valori iniziale dei marker dei PLC ,al primo ciclo macchina, sono alti, bassi o casuali?

Poi ho qualche dubbio sull'esecuzione sequenziale delle operazioni:

il contatto di un marker utilizzato per comandare un'uscita all'inizio del programma, se cambio lo stato del marker alla fine del programma:

all'inizio accenderà o meno la bobina a seconda del valore del ciclo precedente, o sbaglio?

Scusate se son stato contorto.

Spero mi possiate dare una mano specialmente sul primo punto

grazie mille

[Livio Orsini]

Qualcuno mi sa dire se i valori iniziale dei marker dei PLC ,al primo ciclo macchina, sono alti, bassi o casuali?

Se quel PLC non prevede un iniziale reset Hw della RAM, caso non frequente, i valori sono casuali.

il contatto di un marker utilizzato per comandare un'uscita all'inizio del programma, se cambio lo stato del marker alla fine del programma: all'inizio accenderà o meno la bobina a seconda del valore del ciclo precedente, o sbaglio?

Le uscite fisiche del PLC sono aggiornate solo al termine del ciclo di programma. Se durante il programma cambia lo stato di un'uscita questa variazione non ha effetto sull'uscita fisica. Solo al termine del ciclo la tabella immagine delle uscite viene copiata sulle uscite fisiche. Similmente lo stato degli ingressi fisici viene copiato nella tabella immagine degli ingressi; il programma userà questo stato "congelato".

PS Evita di sollecitare risposte, specialmente nel titolo; rischi di ottenere l'effetto contrario.

Modificato: 23 settembre 2010 da Livio Orsini

[Grandegiove]

Salve

innanzitutto mi scuso per aver sollecitato la risposta, solo che ero in un attimo di panico e non avevo pensato che la cosa risultasse "antipatica", non capiterà più.ù

Per le uscite fisiche ok, vengono aggiornati alla fine. Ma per i marker vale la stessa cosa?

Grazie mille

[andrea.fa]

No

i marker sono scritti immediatamente.... quindi se all'istruzione/riga 20 alzi il marker PIPPO all'istruzione/riga 21 lo trovi già alto....

Non conosco il plc di cui parli ma "normalmente" tutti i marker sono inizializzati a zero all'accensione eccetto quelli appartenenti ad una eventuale area di memoria retentiva che ovviamente mantengono lo stato che avevano prima dello spegnimento....

[Grandegiove]

Davvero grazie mille Andrea,

partendo da questi due punti saldi cercherò di districarmi nel codice.

E' che non riuscivo a capire come potesse usare già dall'inizio dei marker come contatti, quando ancora non li aveva settati.. con tutta probabilità all'inizio li considera a 0.

Ne approfitto per un'altra domanda: Il PLC gestisce una comunicazione seriale RS485 con uno slave: quando avviene effettivamente la trasmissione dei dati rispetto al ciclo macchina? Durante e non va avanti finchè non finisce oppure alla fine oppure indipendentemente dal ciclo.. Non mi è molto chiaro questo aspetto.

Lo stesso discorso vale per la comunicazione con un pannello touchscreen di cui il plc è slave.

Spero che la domanda non sia malposta, grazie mille di nuovo

[Livio Orsini]

...quando avviene effettivamente la trasmissione dei dati rispetto al ciclo macchina? ....

Normalmente la trasmissione, e la ricezione, avviene ad interrupt. In altre parole carichi la stringa o il dato nel buffer, spedisci il primo byte. Qunando il buffer di trasmissione è vuoto, cioè il dato è fisicamente uscito, scatta l'interrupt e nella routine di servizio ripeti l'operazione inserendo il prossimo byte; si ripete n volte sino ad aver trasmesso tutto il buffer.

Similmente in ricezione. Appena un dato è presente nel buffer dell'USART scatta l'interrupt di ricezione; la routine di servizio scarica il dato nel buffer di ricezione nell'USART ed il dispositivo è pronto a ricever il prossimo dato.

Se si tratta di una seriale di "sitema", come la porta di programamzione, questa operazione è trasparente per l'utente. In altri termini è gestita dal firmaware di macchina.

Ovviamente se si fa un uso pesante della seriale c'è il rischio di rallentare il ciclo macchina.

[Grandegiove]

In termini pratici se in una istruzione faccio una read di una word dello slave, il ciclo macchina si interrompe e d esegue la trasmissione.

Dall'istruzione successiva ho quindi disponibile la word richiesta? Corretto?

Grazie mille

[Livio Orsini]

In termini pratici se in una istruzione faccio una read di una word dello slave, il ciclo macchina si interrompe e d esegue la trasmissione.

No!

Devi pensare a due programmi che evolvono in contemporanea.

Con la "READ" probabilmente verrà attiviata una funzione che invia il comando allo slave. Il coma do sarà composto da due o più bytes che verranno inviati con la modalità che ho descritto prima.

Lo slave riceve il comando, lo riconosce e risponde con i dati richiesti. Ci saranno come minimo 4 bytes: inizio, 2 per il dato (WORD) ed uno per la fine.

Il master li riceve con la modalità descritta in precedenza. Al termine della ricezione il dato è disponibile. La segnalazione avviene alzando un flag (merker).

Durante tutte queste operazioni il programma utente fluisce regolarmente anche se un poco rallentato dalle interruzioni di trasmissione e ricezione.

Questo se il sistema, e la programmazione, lavorano in modo decente.

Poi c'è anche la modalità che hai descritto tu. Invio un comando allo slave, il programma applicativo si ferma in attesa della risposta. In questo modo se c'è un po' di scambio dati il programma evolverebbe a ritmo di ere geologiche.

Modificato: 23 settembre 2010 da Livio Orsini

[Grandegiove]

Caspita.. qui la faccenda si complica..

Ad un certo punto devo dialogare con uno slave per dirgli di eseguire una scansione e apssarmi 11 bit e poi proseguire con il programma...

Solo che non sò come sincronizzare le cose.. sul manuale non parla di flag di avvenuta ricezione.. mannaggia

[Livio Orsini]

Scusa ma che tipo protocollo usa? E' un protocollo standard tipo, ad esempio, Modbus o propietario?

Se è standard devi leggerti le specifiche del protocollo, altrimenti ci deve essere una descrizione con specifiche del protocollo.

Comunque, se c'è un minimo di decenza nel protocollo, ci deve essere un indicatore di comando eseguito e dati pronti.

Certo che se il programma si ferma aspettando che lo slave esegua la scansione e poi risponda......

[Grandegiove]

Scusa ma che tipo protocollo usa? E' un protocollo standard tipo, ad esempio, Modbus o proprietario?

Se è standard devi leggerti le specifiche del protocollo, altrimenti ci deve essere una descrizione con specifiche del protocollo.

Comunque, se c'è un minimo di decenza nel protocollo, ci deve essere un indicatore di comando eseguito e dati pronti.

Certo che se il programma si ferma aspettando che lo slave esegua la scansione e poi risponda......

Utilizza MODBUS su RS485.

Mi sono letto i principi del protocollo Modbus con la struttura dei frame di domanda e risposta delle istruzioni di read e write

Può essere una buona idea lanciare la read, mettere un temporizzatore nell'ordine dei centesimi di secondo, e quindi elaborare il dato, supponendo che nel frattempo sia arrivato? E' quel supponendo che non mi piace..

E' che non ho le idee chiare sui sincronismi delle due cose.

Come faccio a sapere quando ho ricevuto i miei 11 bit?

Un'idea può essere fargliene inviare un dodicesimo e utilizzarlo come flag?

Davvero grazie mille per la pazienza.

**

inserita correttamente citazione

Modificato: 24 settembre 2010 da Livio Migliaresi