Impianto Terra Su Condominio Privo

[Malis]

Premetto di non essere espsertissimo nella programmazione di plc la mia domanda è la seguente:

Posso realizzare due programmi all'interno di una cpu 224 e richiamarli singolarmente.

Ovviamente uno esclude l'altro.

Sono sicuro che si possa fare ma non riesco a capire come.Se qualcuno di voi puo indirizzarmi ne sarei grato.

Grazie.

Praticamente devo realizzare una macchina reversibile.

Grazie a tutti coloro che risponderanno.

[Dario Valeri]

ciao

un plc puo' "contenere" piu' programmi senza nessun problema.

non capisco cosa significa "macchina reversibile" puoi essere piu' chiaro?

magari con un esempio , forse la soluzione del tuo problema e' a portata di mano

ciao

dario

[Lucky67]

I due programmi possono essere ad esempio due subroutine che vengono richiamate da un selettore che fa capo ad un ingresso uscita del plc...semprechè abbia capito bene la domanda. Nel plc non puoi richiamare dei file distinti in funzione delle tue chiamate. Se utilizzi però i sottoprogrammi è come se fossero due programmi in un programma principale che deve selezionare quale dei due deve essere utilizzato.

[Malis]

Ok quella della sub routine mi sembra mi sembra la soluzione migliore;quindi basterebbe comporre un altro programma e richiamarlo con in contatto.

Domanda: il secondo programma lo creo sulla finestra SBR_0 e lo abilito con il blocco SBRO/EN tramite un contatto?

Il primo programma creato sulla finestra MAIN si disabiliterà automaticamente?

Ultima domanda l'ingressi e le uscite potranno essere comandati dal programma che al momento è selezionato?

Vi ringrazio per l'aiuto che mi avete dato e se potete toglietemi pure questi ultimi dubbi.

Grazie

In risposta a Dario Valeri:La macchina che stiamo progettando deve trasportare del materiale dal basso verso l'alto con vari controlli.Ora il cliente mi chiede se può caricare la macchina anche dall'alto verso il basso eseguendo gli stessi controlli. Reversibile

Grazie

[JumpMan]

Domanda: il secondo programma lo creo sulla finestra SBR_0 e lo abilito con il blocco SBRO/EN tramite un contatto?

Il primo programma creato sulla finestra MAIN si disabiliterà automaticamente?

No.

Se proprio vuoi, creati una SBR0 e una SBR1 e richiama o una o l’altra da OB1/MAIN (PRINCIPALE) in base allo stato (normale per SBR0 e negato per SBR1) di un bit.

Comunque non è detto che sia la soluzione migliore, in genere, anche se la macchina facesse 2 (o più) cicli diversi, molte parti possono essere in comune (consensi, anomalie, comandi manuali) e scrivere 2 (o più) SBR quasi simili pilotando 10 volte le stesse uscite non mi sembra il caso.

Personalmente non scrivo mai più di una volta la stessa uscita, anche se si fa uso di salti ecc. ci si complica molto la vita in fase di debug o xref (esempio tipico: “....quale sarà stata mai l’istruzione che mi ha mandato a 1 l’uscita tal dei tali ??? ora vado in stato......ma dove? Su quale delle 10 assegnazioni?.....”)

Chiaro che questo è un’esempio estremo, ci sono altri 1000 modi di programmare e migliaia di programmatori che usano quel sistema con soddisfazione, può benissimo essere che nel tuo caso sia azzeccato (hai solo 2 varianti..... per ora).

Modificato: 7 settembre 2004 da JumpMan

[Malis]

ok per sbro e sbr1.

Tu mi consigli quindi di utilizzare uscite diverse per programmi diversi esempio per SBRO il contattore KM1 azionato da Q0.0 e per SBR1 il lo stesso contattore KM1 azionato da Q3.0 ?

Se cosi posso farlo,tranquillamente un modulo in più non costa tanto;Con gli ingressi se sono in comune ho problemi?

Tu che ne pensi?

Grazie.

[Livio Orsini]

Attenzione! SBR0 viene creata automsticamente dal compilatore e si intende ad uso esclusivo per settare le condizioni iniziali.

E' preferibile, per tutti i programmi applicativi, creare altre sub. Nel tuo caso, se sono sufficienti due sottoprogrammo, ti conviene usare SBR1 e SBR2. La scelta verrà fatta in OB1 in funzione dei coamdi esterni.

Se devi azionare un medesimo comando, per esempio KM1, in due programmi diversi, usa sempre le medesime uscite, eviterai confusioni ed errori. Idem per gli ingressi.

[wnc]

Attenzione! SBR0 viene creata automsticamente dal compilatore e si intende ad uso esclusivo per settare le condizioni iniziali

Ma le seguenti istruzioni funzionano lo stesso:

ld sm0.1 //ON al primo fronte

call sbrN //N numero qualsiasi compreso tra 0 e 127

In "sbrN" setti le condizoni iniziali. Non riesco a capire l'affermazione precedente.....

Saluti

[Slims83]

Io ho fatto una cosa simile x uno scherzo ad un collega...

richiamava x SBR nel MAIN, le ho duplicate e scambiato un po di uscite, con un confronto dell'ora, alle 4 di mattina ho fatto richiamare il "nuovo" programma.. è stato divertentissimo!!!

( e funziona )

[Paolo.tn]

Ma le seguenti istruzioni funzionano lo stesso:

Sono anchio della stessa opinione, utilizzo spesso SBR_0 ( e anche tutti gli altri) nei miei programmi e non ho probemi, non credo ci sia alcun problema ad utilizzarlo.

MicroWin all'apertura di un nuovo progetto crea in automatico SBR_0 e INT_0 ma nessuno è obbligato ad utilizzarli o non modificarli

Ciao

Modificato: 9 settembre 2004 da Paolo.tn

[Livio Orsini]

Ma le seguenti istruzioni funzionano lo stesso:

Certo che funzionano! L'uso di SBR0 come sub per inizializzazione è un formalismo.

Si può progettare un programma secondo logica e seguendo regole formali, oppure si possono martellare istruzioni fintanto che la macchina fa più o meno quello che dovrebbe fare...

Seguire determinate regole non solo inutile formalismo, ma semplifica il lavoro e, sopra a tutto, consente di avere programmo più affidabili e di più facile manutenibilità.

[Malis]

Ragazzi grazie per l'aiuto ma iniziate un pò a confondermi le idee.

tra qualche di farò un po di prove...vi sapro dire.

Grazie ancora

[JumpMan]

ok per sbro e sbr1.

Tu mi consigli quindi di utilizzare uscite diverse per programmi diversi esempio per SBRO il contattore KM1 azionato da Q0.0 e per SBR1 il lo stesso contattore KM1 azionato da Q3.0 ?

Se cosi posso farlo,tranquillamente un modulo in più non costa tanto;Con gli ingressi se sono in comune ho problemi?

Tu che ne pensi?

Grazie.

Mi hai frainteso, e mi rendo conto che ti sto mettendo confusione in testa.

Non devi usare 2 uscite per la stessa funzione!

Intendo dire che l’uscita Q0.0 (che accende KM1) può benissimo essere programmata una sola volta, basta che la comandi diversamente a seconda se è in esecuzione il ciclo_1, o il ciclo_2, (o il ciclo_n), o il manuale (in Kop avrai una diramazione per ogni ciclo previsto).

Se preferisci invece fare 2 SBR distinte, e programmare 2 volte tutte le uscite, nulla ti impedisce di farlo:

- userai solo un po’ di memoria in più

- dovrai stare attento che venga elaborata una sola SBR per volta

- dovrai stare attento anche al cambio del tipo di ciclo “al volo” (potresti avere delle situazioni impreviste se qualcuno gira il selettore mentre la macchina sta lavorando, il ciclo iniziato da SBR0 continuerebbe in qualche modo in SBR1).

[wnc]

Si può progettare un programma secondo logica e seguendo regole formali, oppure si possono martellare istruzioni fintanto che la macchina fa più o meno quello che dovrebbe fare...

Non si tratta di martellare le istruzioni.... Non ragioniamo sempre in logica binaria noi umani.....

La cosa importante è che il programmatore abbia il proprio formalismo che può essere diversa da un altro. Il tutto deve essere documentato all'interno del programma stesso per una facile manutenibilità del programma stesso.

Ciao

[Livio Orsini]

.... Non ragioniamo sempre in logica binaria noi umani.....

Ci sono solo due modi di progettare: quello corretto e quello sbagliato. ! Può sembrare manicheo ma, purtroppo è così. I formalismi non sono personali ma seguono precise regole, regolamentazioni e standard.

Poi uno può decidere che invece di un protocollo standard di comunicazione ne usa uno suo personale.

Lo capirà solo lui ma i due op più dispositivi connessi riescono a scambiarsi le informazioni.

Peccato che se un domani si voglia aggiungere un nodo solo lui sa come fare.

Identico discorso piò essere fatto per la progettazione Sw.

Si può fare un programma rispettando certe convenzioni in modo tale che possa essere manutenuto da diverse persone. Questa è la prassi corretta. Così lavorano tutte le aziende serie dove i progetti sono indipendenti da chi li esegue materialmente.

Poi si può realizzare un programma, che funziona, ma può essere manutenuto solo dal programmatore che lo ha realizzati. Questo non è il modo corretto di lavorare!

[JumpMan]

Ci sono solo due modi di progettare: quello corretto e quello sbagliato.  ! Può sembrare manicheo ma, purtroppo è così. I formalismi non sono personali ma seguono precise regole, regolamentazioni e standard.

Poi uno può decidere che invece di un protocollo standard di comunicazione ne usa uno suo personale.

Lo capirà solo lui ma i due op più dispositivi connessi riescono a scambiarsi le informazioni.

Peccato che se un domani si voglia aggiungere un nodo solo lui sa come fare.

Identico discorso piò essere fatto per la progettazione Sw.

Si può fare un programma rispettando certe convenzioni in modo tale che possa essere manutenuto da diverse persone. Questa è la prassi corretta. Così lavorano tutte le aziende serie dove i progetti sono indipendenti da chi li esegue materialmente.

Poi si può realizzare un programma, che funziona, ma può essere manutenuto solo dal programmatore che lo ha realizzati. Questo non è il modo corretto di lavorare!

Mi permetto di dissentire Livio, non è detto che (per esempio) un FB personale sia meno “user-friendly” di uno standard (specialmente se quello standard è by Zimenz). Tu stesso ti sei creato il tuo blocco PID perché quello standard non ti soddisfava. Rimango parzialmente d’accordo con te che alcune regole bisogna seguirle ed’è utile che ci siano degli standard, soprattutto all’interno di ditte molto grosse, ma a patto che questo non limiti “l’evoluzione della specie” (e per specie intendo, in questo caso, i programmatori).

Modificato: 10 settembre 2004 da JumpMan

[Livio Orsini]

non è detto che (per esempio) un FB personale sia meno “user-friendly”

Probabilmente non sono riuscito a spiegarmi chiaramente. Provo a chiarire con un esempio.

Posse costruire un programma completo in OB1, senza usare SBRn, o FB od altri OB. La macchina funziona correttamente, il blocco è documentato. Però non si può affermare che il lavoro sia stato eseguito a regola d'arte.

Anche se non ci sono delle norme vincolanti, ma solo direttive generiche, l'architetettura del programma dovrebbe seguire alcune regole fondamentali: OB1 (per Siemens ovviamente) è il MAIN Program (per chi sa di cosa si tratta), che deve richiamare alltri OB, FB o SBR.

Poi il progettista può decidere di usare una funzione di libreria o crearsene un'analoga se ritiene la funzione meglio ottimizzata.

Questo non inficia la validità della struttura del progromma. La funzione personale deve solo rispettare le convenzioni di chiamata e ritorno, deve essere documentata e, sopra a tutto, deve esssere esente da malfunzionamenti.

Se queste regole vengono rispettate si può sostenere che si è progettato a regoal d'arte.

[tonymt]

Salve, nelle fc uso delle variabili locali, es. Lw 30, in modo da poterle chiamare allo stesso modo in varie fc e non vanno in sovrappposizione.

ora se devo fare un fronte all'interno di una fc, per il bit di memoria non posso usare l'are di memoria L perchè viene riscritta a ogni ciclo di esecuzione del programma.....

Ora pero usando i merker (es. fp m 10.0) non posso richiamare piu istanze della stessa funzione perche andrebbero a usare lo stesso merker....

c'è un modo per avere all'interno di una fc un area di memoria locale ma non volatile a ogni scansione del programma ?

attualmente dichiaro i bit che mi servono come in/out e poi quando chiamo la fc li assegno a merker via via diversi...

Grazie.

[lucios]

Trasforma le tue FC in FB con DB di istanza.

Ciao

[peopeo]

Oppure, se devi personalizzare le DB, puoi crearti una DB per ogni FC e creare una struttura di dati uguale ai tuoi dati locali e all'inizio dell' FC copi il contenuoto della DB nella struttura delle variabili locali e poi a fine FC fai il contrario e cioè copi le variabili locali nella struttura della DB.

Se fai così puoi aggiornare i tuoi programmi vecchi senza riscrivere gli FC già creati.

Il funzionamento è simile alle FB ma ti permette di aggiungere ulteriori dati alle DB perchè non sono istanziate ed in oltre appesantiscie meno il ciclo della CPU.

[tonymt]

ma se trasformo in fb devo dargli un db di istanza per ogni istanza della stessa fb ?

quanti possono essere massimo i db in una 315 2dp ?

Grazie dell'aiuto

[cisio]

1023 db, 1023 fc, 1023 fb

più che in termini di numero di blocchi devi pensare alla quantità di memoria di lavoro

ovvero 128kB totali

ciao

[acquaman]

Oppure metti la tua variabile locale del on shot come variabile in ingresso/uscita e ogni volta che lanci il tuo fc gli associ un merker diverso che ti fa da on shot.

[lucios]

ma se trasformo in fb devo dargli un db di istanza per ogni istanza della stessa fb ?

Si, questo è il metodo più corretto, ma anche gli altri suggerimenti funzionano.

Ciao

[rev56]

Utilizza assolutamente delle FB, sono degli strumenti molto potenti ed associa al' fb da te creata 1 le db di istanza che ti servono...

Se ti crei delle altre db richiamate all'interno della tua o delle tue fc fai sl della gran confusione