Chiamata multistanza in KOP

[STEU]

Buongiorno

mi sto impiantando su una stupidaggine, ovvero in un FB (ottimizzato) non riesco ad inserire un fb(ottimizzato) dichiarato nelle statiche in KOP, mentre in AWL con la call #pompe funziona benissimo.

Nei proprieta nella tab degli attributi è flaggato il checkbox Multistanze.abbiamo messo la spunta

Siccome stiamo cercando di uniformarci eliminando l'AWL e facendo tutto in KOP dove sbaglio che non riesco a mettere un Box con l'FB dichiarato nelle statiche?

[drn5]

Scusami...ma se ti funziona nel segmento 2 DEVE funzionare anche nel segmento 1.

Dove sta il problema?

Dentro i ?? hai scritto pompa2?

[batta]

Se trascini il blocco nel segmento, ti chiede se vuoi inserirlo come istanza singola (nel qual caso crea un DB di istanza), una multiistanza (inserisce l'istanza nelle STAT), oppure istanza del parametro (inserisce l'istanza nei parametri IN/OUT).

 

Se hai già creato l'istanza nelle STAT ed inserisci il blocco manualmente (o trascinandolo, non cambia nulla), ti chiede sempre come lo vuoi inserire (stesse modalità descritte prima).
Gli devi dire "Multiistanza" e, come "Nome interfaccia", selezioni dalla lista che ti propone il nome che hai assegnato nelle STAT all'istanza.
O, ancora, se hai inserito il richiamo al blocco ma senza aver assegnato l'istanza, clicchi sui punti interrogativi in rosso, e ti propone la lista delle istanze possibili, sia di eventuali DB di istanza associati a quella funzione, sia di istanze dichiarate nelle STAT o come IN/OUT.

 

[STEU]

Sono riuscito

16 ore fa, drn5 ha scritto:

Scusami...ma se ti funziona nel segmento 2 DEVE funzionare anche nel segmento 1.

Dove sta il problema?

Dentro i ?? hai scritto pompa2?

dentro i ??? devo mettere il nome dell FB e non della statica che ho inserito prima e pompa 1 devo metterloal posto della multi istanza, a questo punto la multiistanza la faccio creare da tia e poi la rinomino

in pratica come ha detto Batta

 

Modificato: 3 marzo 2022 da STEU

[STEU]

si pu0 addirittura passare l'istanza come parametro I/O

 

 

[walterword]

io da stupido e profano dopo piu di 20 anni di plc preferisco gestire il tutto in FC con ogni singola logica "LIBERA" da FB annidati o porcate varie.

1- Se voglio vedere online , specialmente in cantiere, ogni singola logica la guardo a la modifico come voglio e velocemente.

2- Uso FC e DB globali e non devo ogni volta ricreare o aggiornare il DB di istanza.

3- Tutte le variabili sono globali ovunque nel codice senza usare , cosa che non ho mai fatto , le variabili statiche ne in giro nel programma e nemmeno nel hmi

4- Seguite pure il faldone di SITRAIN , che posseggo dal 2000 . 

5- I programmatori seri e VELOCI entrano, guardano e risolvono il problema 

6- I tedeschi sono bravi fino ad un certo punto , poi interviene la classe all'italiana , libera, democratica e soprattutto veloce.

Dimenticavo, quando cerco una variabile uso il classico metodo a disposizione, non faccio il CTRL+F per cercare una variabile statica.

Gli FB li uso solo per cose concrete, testate e mai più modificabili, lavoro come molti altri programmatori contro le indicazioni di Siemens.

FC per routine e funzioni. FB per funzioni speciali. Vai ad aprire un vecchio sw con FB annidati ....STAT in rosso , e tanta cacarella quando ci devi mettere le mani

comunque fate come volete. Il plc non è un pc e nemmeno un sistema embedded. Fossilizzatevi pure......

Per quanto mi riguarda, il mio problema è sempre stato capire cosa vogliono i tecnologi , processisti e clienti. 

Non devo far conto per capire dove punta un puntatore o diventare pazzo per capire le logiche di FB anndiati. 

Il compito del programmatore plc è lavorare sereno, libero e chiaro, scrivere commenti e commentare ogni singolo bit, ovviamente dell'area dati DB.

I merker ..uso solo quelli obbligatori per i clock , diversamente scrivo io i clock di sistema su DB.

ciao 

 

Modificato: 8 marzo 2022 da walterword

[walterword]

io se devo gestire 100 pompe copio e incollo 100 vole la logica di una pompa e sostituisco le variabili globali. 

Ogni pompa la gestisco a se. Non uso FB pompa....

Il tempo di esecuzione è lo stesso e  la memoria di caricamento non è mai stata un problema.

Definisco N tipologie di pompe , se poi sono uguali meglio ma comunque separate una dall'altra.  

 

[leleviola]

45 minuti fa, walterword ha scritto:

io da stupido e profano dopo piu di 20 anni di plc preferisco gestire il tutto in FC con ogni singola logica "LIBERA" da FB annidati o porcate varie.

1- Se voglio vedere online , specialmente in cantiere, ogni singola logica la guardo a la modifico come voglio e velocemente.

2- Uso FC e DB globali e non devo ogni volta ricreare o aggiornare il DB di istanza.

3- Tutte le variabili sono globali ovunque nel codice senza usare , cosa che non ho mai fatto , le variabili statiche ne in giro nel programma e nemmeno nel hmi

4- Seguite pure il faldone di SITRAIN , che posseggo dal 2000 . 

5- I programmatori seri e VELOCI entrano, guardano e risolvono il problema 

6- I tedeschi sono bravi fino ad un certo punto , poi interviene la classe all'italiana , libera, democratica e soprattutto veloce.

Dimenticavo, quando cerco una variabile uso il classico metodo a disposizione, non faccio il CTRL+F per cercare una variabile statica.

Gli FB li uso solo per cose concrete, testate e mai più modificabili, lavoro come molti altri programmatori contro le indicazioni di Siemens.

FC per routine e funzioni. FB per funzioni speciali. Vai ad aprire un vecchio sw con FB annidati ....STAT in rosso , e tanta cacarella quando ci devi mettere le mani

comunque fate come volete. Il plc non è un pc e nemmeno un sistema embedded. Fossilizzatevi pure......

Per quanto mi riguarda, il mio problema è sempre stato capire cosa vogliono i tecnologi , processisti e clienti. 

Non devo far conto per capire dove punta un puntatore o diventare pazzo per capire le logiche di FB anndiati. 

Il compito del programmatore plc è lavorare sereno, libero e chiaro, scrivere commenti e commentare ogni singolo bit, ovviamente dell'area dati DB.

I merker ..uso solo quelli obbligatori per i clock , diversamente scrivo io i clock di sistema su DB.

ciao 

 

Oh finalmente, ti quoto walterword,

anch'io finche possibile preferisco lavorare così, aggiungo inoltre che in passato con il simbolico fare una modifica online in assoluto era una sciocchezza, oggi dove quasi tutto non ha un indirizzamento assoluto fare modifiche on-line diventa un rischio per la funzionalità del processo o sei costretto a fare i salti mortali anche per una banale modifica, meglio non tagliare i ponti con le vecchie care abitudini del passato

[batta]

1 ora fa, walterword ha scritto:

quando cerco una variabile uso il classico metodo a disposizione, non faccio il CTRL+F per cercare una variabile statica.

Mai usato Ctrl+F per cercare una variabile. Dall'interno di una FB, già da anni, nel TIA, i riferimenti incrociati ti fanno vedere dove sono usate le STAT.
Io ho seguito il percorso opposto. Un tempo usavo uasi esclusivamente FC. Oggi uso sempre di più FB. Ogno blocco ha in pancia tutte le variabili che gli servono, senza doverle dichiarare in DB separati. Inoltre, sono variabili globali e, come appena scritto,rintracciabili facilmente con i rigferimenti incrociati.

 

1 ora fa, walterword ha scritto:

io se devo gestire 100 pompe copio e incollo 100 vole la logica di una pompa e sostituisco le variabili globali.

Io invece faccio una FB alla quale collego i parametri che mi servono. Se cambia la logica, modifico una sola FB e non cento FC.
Se la logica cambia per una sola pompa, faccio una FB diversa per quella pompa.

 

59 minuti fa, leleviola ha scritto:

aggiungo inoltre che in passato con il simbolico fare una modifica online in assoluto era una sciocchezza, oggi dove quasi tutto non ha un indirizzamento assoluto fare modifiche on-line diventa un rischio per la funzionalità del processo o sei costretto a fare i salti mortali anche per una banale modifica

Io sono dell'idea totalmente opposta: lavorando con indirizzi assoluti una modifica può compromettere il funzionamento, mentre lavorando in simbolico si è molto più liberi.

[STEU]

Sinceramente Siemens ha "copiato" Rockwell , ormai gli indirizzi si usano solo per le uscite ed ingressi.

Comunue l'esempio era appunto un esempio , il mio problema era una multi istanza per un timer e non volevo andare a scriverlo in una DB globale.

[walterword]

Quello che è rimasto in Siemens è che ogni FC, FB, DB , Timer etc lo devi sempre dichiarare come numero a differenza di Rockwell o comunque codesys in generale.

Oggi ho iniziato in una nuova azienda, ci sono FC per pompe , valvole ed altre funzionalità , non è un problema se funzionano nemmeno voglio aprirle per vederle.

Gli FB annidati di FB annidati etc non mi sono mai piaciuti , se usi FC e vuoi dati globali li passi come in-out e dichiari in un db di quella parte di impianto con all'interno le istanze, lo faccio per istanze di timer e fronti di salita. Generare DB di istanza qua e là con numeri casuali mi da fastidio. Io modello gli impianti e parti di macchina come oggetti , cartelle e sotto cartelle con loro fc e db ben dichiarati e disaccoppiati dal resto finchè possibile. Gli FB li uso per funzioni specifiche che una volta funzionanti non li tocco più , come il PID che ho scritto.

Si batta intendevo il vecchio step 7 le cui statiche le trovavi con CTRL + F ....

Le FC e FB per pompe e valvole vanno bene se tramite il loro udt le sfrutti nel hmi. E' chiaro che fuori passi i parametri e le differenze di logiche te le giochi fuori prima di passare il parametro.

 

 

se hai una parte di impianto ben definito crei un DB globale e dichiari un array di 100 istanze timer iec e poi li passi ai timer senza generare a livello globale 2000 db che poi rompono le palle perche diventano tanti e perche prendono numeri a caso , se non stai attento. 

 

[batta]

9 ore fa, walterword ha scritto:

e perche prendono numeri a caso , se non stai attento

È proprio questo il fatto: salvo casi particolari, ho smesso di preuccuparmi del numero che prendono FC, FB e DB. A me interessa solo il nome.

In alcuni casi anch'io uso FC e passo i parametri, organizzati in strutture, come IN/OUT. Ma trovo più comodo un blocco che ha in pancia tutto quello che gli serve, anche le STAT, non solo i parametri. Con una FC, anche le variabile statiche le devi passare come IN/OUT.

[walterword]

A me invece il numero messo a caso interessa perchè nei grandi progetti dove l'impianto è diviso in cartelle e sotto cartelle e soprattutto se si lavora in team .....il numero generato a caso mi rompe le scatole...se poi nei progetti futuri devo prendere parti esistenti ed utilizzarle con altre macchine già fatte ....il numero a caso mi rompe sempre le palle.....

 

 

[STEU]

Il numero non dovrebbe essere importante, ed ad ogni modo lo puoi cmbiare quando vuoi

[walterword]

Dipende....se è ottimizzato lo compili , lo cambi e lo ricompili....diversamente devi ricablare tutto e verificare anche dove viene usato in modo assoluto ovunque.

[batta]

1 ora fa, walterword ha scritto:

diversamente devi ricablare tutto e verificare anche dove viene usato in modo assoluto ovunque.

Nì...

Nel senso, se ci sono accessi dove si usa il numero del DB, ovviamente sì.
Ma l'indirizzamento assoluto è proprio ciò che sto cercando (riuscendoci) in tutti i modi di evitare come la peste (oggi, si potrebbe dire: "come il Covid" 😉 ).
Se si usa il nome del DB, allora il numero non conta, anche nel caso di DB/FB/FC NON ottimizzati. Oppure conta solo se uno SCADA o altri dispositivi devono accedere con indirizzi assoluti ma, in questo caso, di solito i dati da scambiare si organizzano in DB dedicati, e si parla di un numero ridotto.

[drn5]

È il cambio di generazione. Ai tempi delle EPROM scrivevi in assembler. Adesso spuntano linguaggi come funghi. O ci si adegua o si resta indietro. E se si resta indietro si smette di lavorare.

[walterword]

Quote

Adesso spuntano linguaggi come funghi

è gia da un po che esistono linguaggio di alto livello come il C ...decenni.

SCL lo avevo acquistato a parte nel 2001 quando ero libero professionista e l'ho sempre usato per calcoli, tabelle, inserimento dati ,estrapolazione etc. 

Lo uso anche nei master di missione che richiamano altre missioni sempre in scl. Poi pero uso il ladder per i comandi, le procedure automatiche etc, anche perche se il manutentore deve fare qualche pasticcio o capire la causa di un guasto lo vede velocemente.

Batta, sto usando un FB che ovviamente mi crea il DB di istanza e lo colloca negli oggetti globali del progetto. Io vorrei creare un DB globale all'interno del quale inserire tutti i DB di istanza di questo FB che verrà richiamato N volte. Sto provando ma non riesco a definire il tipo di dato del FB.

Magari non si può nemmeno fare , tu cosa dici? 

[batta]

No, non si può fare.
Potresti aggirare creando una FB dove dichiari, nelle STAT, tutte le tue istanze.
Poi, anche senza richiamare questa FB, generi il DB di istanza della FB.

Quando poi richiami le varie FB, fai riferimento alle diverse istanze contenute in questo DB.

 

Sinceramente però, non mi pare una buona soluzione, non solo perché devi fare delle operazioni in più che sarebbero automatiche, ma soprattutto perché racchiudendo tutte le istanze in un unico DB, quando modifichi anche una sola istanza viene reinizializzato tutto il DB.
Se fai modifiche online, questop potrebbe essere un grosso problema.

 

Non mi chiedere il numero preciso ma, nelle nuove CPU, puoi avere (compatibilmente con i limiti di memoria, ovviamente) alcune decine di migliaia di DB.
Non vedo dove sia il problema nell'avere le istanze in DB separati. Poi, per fare ordine, basta raggrupparli opportunamente nelle cartelle a proprio piacimento.

[walterword]

Si infatti non si può. 

Si potrei creare un FB e richiamare tutti gli FB dei drive ed utilizzare le istanze dichiarate nella tendina come STAT.

Oppure creare i DB di istanza nella cartella globale.

Era una cosa cosi per provare.

comunque grazie