Consigli su nuovo software

[salva95]

Buonasera a tutti

 

È da un po' di tempo che devo realizzare un piccolo software che mi gestisce il carico di 5 tramogge che sono strutturate così:

 

 

5 tramogge con 5 livelli che mi indicano "tramoggia piena"

Le tramogge vengono riempite da un nastro con 5 aperture pneumatiche (quindi posso riempire solo 1 tramoggia alla volta)

 

Quello che mi arrovella il cervello e come creare una sorta di sistema di "prenotazione" , mi spiego meglio:

 

Tramoggia 3 basso livello, apro la Portella e inizio a riempire, mentre riempio la 3 la 2 va in basso livello ma resta in standby perché sto riempiendo la 3, anche la 5 va in basso livello

Per logica devo riempire prima la tramoggia 2 appena finisco la 3 altrimenti si svuota troppo, poi dopo fatta la 3 vado sulla 5.

 

 

Voi cosa ne pensate? 

[thinking]

Ciao,

 

In questo video puoi trovare spunto per quello che vuoi fare. Non è esattamente la stessa cosa ma penso che ti permetterà di risolvere il problema:

 

video

 

ciao

[max81]

Io implementerei una coda, detta anche Fifo (first In first out), quindi appena una tramoggia si svuota si inserisce la richiesta in coda, poi aspetterà il suo turno.

Ciao

[Roberto Gioachin]

5 ore fa, max81 scrisse:

Io implementerei una coda, detta anche Fifo (first In first out)

Questo è il metodo più adeguato al tipo di lavoro.

Non so quale plc usi, ma molti plc hanno già le istruzioni per il registro FIFO, 3 o 4 network ed hai fatto.

[salva95]

31 minuti fa, Roberto Gioachin scrisse:

Questo è il metodo più adeguato al tipo di lavoro.

Non so quale plc usi, ma molti plc hanno già le istruzioni per il registro FIFO, 3 o 4 network ed hai fatto.

Sto infatti studiando la FIFO di Siemens, userei una 314 che ho in magazzino 

 

Ho fatto un po' di logica ora faccio qualche prova vediamo che ne esce

[84paolo]

io normalmente in casi come questi uso dei contatori. a livello coperto resetto il contatore e a livello scoperto inizio a contare. fai N contatori quante sono le tramogge e poi quella con il contatore più alto é quella che é da più tempo che aspetta. se mentre ne riempi una, una che era vuota e stava già contando viene per esempio riempita a mano, si azzera il contatore e non andrai più a riempirla.

[batta]

2 ore fa, 84paolo scrisse:

io normalmente in casi come questi uso dei contatori. a livello coperto resetto il contatore e a livello scoperto inizio a contare.

Sistema semplice e funzionale.

[salva95]

10 ore fa, 84paolo scrisse:

io normalmente in casi come questi uso dei contatori. a livello coperto resetto il contatore e a livello scoperto inizio a contare. fai N contatori quante sono le tramogge e poi quella con il contatore più alto é quella che é da più tempo che aspetta. se mentre ne riempi una, una che era vuota e stava già contando viene per esempio riempita a mano, si azzera il contatore e non andrai più a riempirla.

 

Bella idea!!

 

Ma con quale funzione posso confrontare 5 temporizzatori e tirare fuori quello con il valore più alto?

[batta]

Per i contatori non usare la funzione "contatore", ma incrementa e azzera semplicemente delle variabili.
Potresti usare il fronte salita del merker di sistema con clock a 1 secondo per incrementare le variabili delle tramogge vuote.
Poi, per iniziare il carico, se metti le variabili in un array, in SCL ti basta un ciclo FOR per individuare la tramoggia da caricare.
In KOP diventa un po' meno semplice, ma bastano comunque poche comparazioni.

[salva95]

Ragazzi ho impostato un pezzo di codice per fare qualche test

 

 

U  Liv_1

L s5t#10s

 

SE T1

 

 

U  T1

U  Merker_1s

L Tempo_ATTESA

L L#1

+D

 

T TEMPO_ATTESA

 

 

 

 

quello che dovrebbe fare ora nella mia testa è questo: se c'è l abilitazione dal livello attiva T1, dopo 10s tramite il merker di clock mi incrementa il tempo ogni secondo.

Ho fatto qualche boiata nel codice, complice il caldo le continue chiamate all' interno non riesco a vederlo, praticamente la somma va avanti in continuo, senza rispettare le condizioni sopra descritte 😕

[batta]

In AWL le operazioni vengono eseguite indipendentemente dallo stato dell'RLC. Devi mettere un salto.

Esempio:
 

U T1
U Merker_1s
SPBN _000
L Tempo_Attesa
+ 1
T Tempo_Attesa
_000: NOP 0

Visto poi che l'AWL (purtroppo) è tenuto sempre meno in considerazione, se stai usando una CPU 1500 forse sarebbe meglio scrivere in SCL.
Esempio:

IF T1 THEN
	IF Merker_1s THEN
		TempoAttesa += 1;
	END_IF;
END_IF;

 

Attenzione poi che Merker_1s deve rimanere attivo una sola scansione ogni secondo. Se usi il merker di clock del sistema, devi rilevarne il fronte di salita.

Modificato: 24 luglio 2019 da batta

[batta]

18 minuti fa, batta scrisse:

Visto poi che l'AWL (purtroppo) è tenuto sempre meno in considerazione, se stai usando una CPU 1500 forse sarebbe meglio scrivere in SCL.

Mi correggo.
Ho scritto "se stai usando una CPU1500".

Invece volevo dire "se stai usando TIA".
l'SCL va benissimo anche con le CPU 300/400.

In realtà si può usare SCL anche con il "vecchio" Simatic Manager, ma l'editor è molto meno pratico di quello del TIA.
 

Quello che invece si può fare con il 1500 ma non con il 300, è inserire un segmento in SCL all'interno di un blocco di programma in KOP.

 

[salva95]

1 ora fa, batta scrisse:

In AWL le operazioni vengono eseguite indipendentemente dallo stato dell'RLC. Devi mettere un salto.

Esempio:
 

U T1
U Merker_1s
SPBN _000
L Tempo_Attesa
+ 1
T Tempo_Attesa
_000: NOP 0

Visto poi che l'AWL (purtroppo) è tenuto sempre meno in considerazione, se stai usando una CPU 1500 forse sarebbe meglio scrivere in SCL.
Esempio:

IF T1 THEN
	IF Merker_1s THEN
		TempoAttesa += 1;
	END_IF;
END_IF;

 

Attenzione poi che Merker_1s deve rimanere attivo una sola scansione ogni secondo. Se usi il merker di clock del sistema, devi rilevarne il fronte di salita.

Domattina apporto le modifiche: salto sulla funzione e fronte di salita sul merker di clock e provo 😊

 

 

L'SCL è sempre stato un mistero per me 🤔 dopo aver realizzato questa funzione di "tempo di richiesta " vedo si studiare il tuo consiglio sul ciclo for in SCL per individuare il temporizzatore più alto 😎

[salva95]

Eccoci qua!

 

 

Modifiche effettuate, la funzione di conteggio ora conta, quando il livello torna OK mi resetta la doppia Word mettendo 0

 

 

Ora ho 2 dubbi, sto usando un clock di 2s (l idea era quella di non fare resettare il contatoreanche un conteggio abbastanza lento mi dà idea di quale tramoggia ha iniziato prima la richiesta di carico), ma anche rilevandone il fronte di salita il conteggio non scatta di 1 unita al secondo ma molto di più. Penso che questo abbia a che fare con il ciclo del PLC che sarà molto più rapido del clock da me scelto quindi va a sommare 1 alla Word molte volte.

C'è modo di ovviare alla cosa? 🤔

[step-80]

A parte che se usi un clock di 2 secondi non puoi aspettarti un incremento al secondo,non puó essere assolutamente..o hai usato male il fronte, o il clock non è di 2 secondi. 

Modificato: 25 luglio 2019 da step-80

[salva95]

19 minuti fa, step-80 scrisse:

A parte che se usi un clock di 2 secondi non puoi aspettarti un incremento al secondo,non puó essere assolutamente..o hai usato male il fronte, o il clock non è di 2 secondi. 

Con il clock di 1s il conteggio schizzava, per questo ho optato per un conteggio a 2s, il problema è che in quel momento che rilevo il clock il conteggio viene incremento di X unità quando nella mia testa pensavo che si incrementasse di 1 unita, penso che la CPU sia più veloce nel conteggio del clock stesso, in 1s riesce a fare X addizioni invece che 1 sola 🤔

[batta]

Ma come generi il clock? Se incrementa per più di una unità significa che il clock rimane alto per più di una scansione.
Se usi direttamente il merker di clock di sistema, ricorda che questo merker è definito, in modo secondo me improprio come "clock". In realtà di tratta di un oscillatore.
Per esempio, il merker di clock 1 secondo rimane alto per 500 ms e basso per 500 ms.
Se tu usi questo merker per l'incremento, nei 500 ms che è alto incrementa di una unità ad ogni scansione.
Devi rilevare il fronte di salita di questo merker.

 

Dato che nei programmi è abbastanza frequente dover usare dei flags di clock (molto più frequente rispetto agli oscillatori forniti dal sistema), in tutti i miei programmi metto sempre le seguenti righe:

//Generazione fronti salita da merker di clock
"OS_Byte" := "Clock_Byte" AND "XOS_ClockByte";
"XOS_ClockByte" := NOT "Clock_Byte";

Dove:

"Clock_Byte" è il byte dei merker di clock impostato nella configurazione hardware

"XOS_ClockByte è un byte (nell'area merker, o in un DB, a piacere) con i bit per il rilevamento dei fronti di salita

"OS_Byte" è un byte (nell'area merker, o in un DB, a piacere) i cui bit sono dei veri clock, e non degli oscillatori.
 

[salva95]

Il clock lo prendo dal merker di clock generato dal sistema leggendone il fronte di salita 🤔

[step-80]

prova a postare il codice

[DavideDaSerra]

'Teoricamente' potresti creare un sistema ad asta (googlola: auctions in distributed computing) c'è un po' di teoria dietro ma minimizza i downtime.

Auction:

Il succo è questo: ogni tramoggia "offre" al "tappeto" in proporzione a quanto è piena (più è piena meno offre).

Ogni x secondi c'è una nuova asta, se a quell'asta un'altra tramoggia ha valore più basso ecco che quella 'vince' il carico e così via.

 

In questo modo il meccanismo si autoregola e riduci al massimo i vuoti.

 

L'importante è che le aste non siano troppo frequenti (in quel caso sarebbe uno switch continuo) ne troppo rade (si oscillerebbe tra tutto pieno/tutto vuoto)

 

Poi dovrai gestire il "troppo pieno" in cui una tramoggia forzerà la richiesta (all'arbitro) che si faccia un altra asta per non straripare.

 

 

Ovviamente ogni tramoggia potrà gestire diversamente le offerte: magari una macchina che intrinsecamente è più lenta, anche se non è pienissima potrebbe offrire meno di quello che offre una macchina più veloce.

 

Io calcolerei le offerte in base ai tempi di svuotamento delle singole tramogge (se una passa da troppo pieno a metà in 5 minuti e l'altra ne impiega 8, la prima, in linea di massima, dovrà fare un'offerta più alta della seconda per la medesima condizione)

Modificato: 27 luglio 2019 da DavideDaSerra

[Ctec]

Cavolo, ancora l'orrendo AWL (assimilabile all'Assembler dei processori). Inguardabile.

Ma poi, dato che la IEC1131-3 definisce con termini UNIVERSALI (eccetto per i boriosi Siemens) i linguaggi:

LD Ladder Diagram (e non KOP),

ST Structured Text (e non SCL)

IL  Instruction List (e non AWL)

FBD Function Block Diagram

SFC Sequential Function Chart

non è possibile uniformarsi a queste terminologie NORMALIZZATE?

[batta]

5 minuti fa, Ctec scrisse:

Cavolo, ancora l'orrendo AWL (assimilabile all'Assembler dei processori). Inguardabile.

Su questo non sono d'accordo.
L'AWL (che è diverso da IL), in certi casi è ancora il linguaggio più efficiente. Tutto sta ad usarlo solo nei casi dove offre vantaggi.
Per dire, il testo strutturato è ottimo per certi compiti, ma la tendenza di alcuni di fare tutto in testo strutturato, compresa la logica booleana, a me pare tanto da masochisti.

Vista la tendenza anche in casa Siemens di riporre l'AWL in un cassetto, cerco anch'io di adeguarmi e lo uso sempre meno ma, ogni tanto, un segmento in AWL mi scappa ancora ;-)

I linguaggi Siemens, oggi (AWL a parte), rispondono alla normativa IEC1131-3. Perché sostieni che non sia così?
Ti do poi ragione per i nomi dei linguaggi: dovremmo parlare di LD e ST, e non di KOP e SCL.
Diversa invece la questione AWL e IL, che sono due linguaggi diversi. Entrambi si basano su una "lista istruzioni", ma l'IL di un Omron è completamente diverso dall'AWL di un Siemens, non solo come istruzioni, ma proprio come filosofia di base.

[Ctec]

Intendevo solo i nomi. Il fatto di chiamarli in modo alternativo mi urta i nervi.

Io mischio solitamente LD e ST (anche in TIA portal) proprio per quello che dici tu.

Lo AWL non l'ho mai potuto soffrire, sinceramente, e l'uso dei registri e stack mi fa pensare in automatico all'assembler, che oramai ho abbandonato da una 20ina d'anni.