Logiche di "pensiero" per testo strutturato

[sottobosco]

Ciao a tutti, sono un novellino della programmazione in PLC, fino ad ora con Allen Bradley serie micro 800.

Ho ottima dimestichezza con il linguaggio di programmazione in generale, e quindi mi piacerebbe approfondire alcune logiche, riporto un esempio contro cui mi sono scontrato:

ciò che io volevo tradurre era

img esempio.gif (8.94 KiB) Osservato 11865 volte

ed ho banalmente scritto così:

Codice: Seleziona tutto

if (commutazione) THEN
   Reset_counter := TRUE; (*RESETTO IL CONTATORE DI IMPULSI*)
END_IF;

Ma mi sono ben presto reso conto che non sono affatto la stessa cosa:

in LD se la condizione "commutazione" viene a mancare, anche l'uscita cade, diversamente in ST una volta assegnato "true" all'uscita, questa non viene modificata al mancare della condizione.
Risolvo aggiungendo un elseif:

Codice: Seleziona tutto

IF (commutazione) THEN
   Reset_counter := TRUE; (*RESETTO IL CONTATORE DI IMPULSI*)
ELSEIF
   Reset_counter := FALSE;
END_IF;

Ora la mia domandona è: questo è l'unico modo di operare sulle bobine? devo sempre avere una condizione e un ELSE per resettare l'uscita?

Se sì, risulta certamente molto più comodo il LD.... (relativamente a questo esempio)

[WALTERmwp]

Ciao sottobosco, quello che hai riportato in "ladder" è una semplice assegnazione che viene sempre eseguita (sempre stando a quanto hai riportato); è come se tu scrivessi:

Codice: Seleziona tutto

variabile_A := variabile_B;


... per cui il valore che assume variabile_B "passa" a variabile_A.
Se sono due variabili "digitali", lo stato di una viene assegnato all'altra, ma non si tratta di un test.

Saluti

[sottobosco]

grazie per l'intervento.
In Ladder (ovvero ove ora tutto funziona) all'attivarsi della variabile "commutazione" devo eccitare la bobina "reset_counter".
Nel momento in cui "commutazione" torna allo stato basso, anche "Reset_counter" lo segue.

Chiedevo conferma sul fatto che con il testo strutturato, queste due situazioni si realizzano con un IF e un ELSE, l'IF soltanto non è sufficiente perché in effetti nessuno assegnerà mai il False alla bobina "reset_counter"...

[WALTERmwp]

Come ti ho scritto, per come sto interpretando il discorso, l'equivalente del "ladder" lo riporti in codice come ho indicato nel Post [2].
Il fatto che tu voglia provare a "trasportare" in altra forma quello che hai proposto non significa che tu debba per forza ricorrere ad uno "statement" come "if/else" o if/then/else" o altro ancora.
La semplice assegnazione assolve al compito.

Saluti

[Candy]

Come ti hanno detto la trasposizione del tuo problema dal ladder allo strutturato è più semplicemente:

Codice: Seleziona tutto

Reset_Contatore := Commutazione;

La condizione IF, in quando condizione, in ladder si risolve tramite salti e la trasposizione, mentalmente, non è così immediata ad una mente poco allenata.

In ogni caso, non avviarti nell'inutile e dannoso esercizio di trasporre ladder e letterare strutturato. Hanno il loro significato, ciascuno, per compiti e problemi diversi tra loro.

[sottobosco]

Banalmente la mia richiesta si riassume così, forse più chiara:
Mi scrivete in st il codice per cui una uscita segue l'andamento di un ingresso?
O ancora, mi mettete in codice st questa funzione : la luce si accende quando l'interruttore è premuto e si spegne quando viene rilasciato.
E corretto (o addirittura è l'unica via ) passare per un "if then else "

[carlomariamanenti]

...E corretto (o addirittura è l'unica via ) passare per un "if then else "

sottobosco, non esiste quasi mai una unica via, l'utilizzo del linguaggio ST invece che LD non vincola l'utilizzo di alcune funzioni anziché altre: i blocchi funzionali presenti nel linguaggio LD sono comunque disponibili in ST; per questo motivo non mi è chiara la tua domanda.

[sottobosco]

Probabilmente le mie sono le classiche pippe mentali...
È utile per me comprendere come si ragiona, se lo si fa in modo uniforme, se esistono regole non scritte ma ormai approvate così che un programmatore che legge il codice di un altro ne abbia immediatamente chiaro l'intento.
O forse invece vige la regola del "se funziona allora tutto ok" e chi se ne frega della forma.

Vorrei avvicinarmi al vostro mondo e vorrei farlo secondo i vostri "usi e costumi".

[carlomariamanenti]

In questo "mondo" non vigono usi e costumi ma regole ben definite che sono la base di studio necessaria per scrivere codice.

Programmare sistemi multi-tasking magari deterministici utilizzando contemporaneamente differenti linguaggi pretende da parte dello sviluppatore il rispetto di regole e procedure standard e ben definite.

Accontentarsi di un programma "che gira" senza apparenti problemi è dal mio punto di vista sbagliato: magari sintatticamente ciò che hai scritto potrebbe risultare corretto ma semanticamente potrebbe contenere errori anche gravi.

Non conosco la tua preparazione tecnica e non mi permetto minimamente di giudicare il tuo operato, ma credimi quando ti dico che forse un approccio più scientifico non guasterebbe; faccio questo lavoro da troppi anni e ti assicuro che l'approssimare una soluzione non porta mai molto lontano.

L'utilizzo di un sistema prevede la conoscenza profonda delle funzionalità disponibili, non sto parlando solamente della sintassi ma anche delle funzioni e delle tecniche di utilizzo.
Tradurre quindi una funzione da un linguaggio ad un altro diventa semplice se gli aspetti sopra descritti sono noti.

Se lo desideri posso inviarti un po di documentazione tecnica relativa ai vari linguaggi di programmazione IEC e alle loro funzionalità.

[sottobosco]

Ecco, era esattamente questo che volevo sentirmi dire.
Prima di entrare in casa vostra vorrei conoscerne le regole! Ti mando in mp la mia mail è se vuoi mandami quello che ritieni utile!