S7 200 - Richiamo di programma

[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

[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!

[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

[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.

[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.

[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

[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.

[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

[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

[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.

[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

[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

[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