Vai al contenuto
PLC Forum

Partecipa anche tu alla Live su Youtube martedì 28/01/2025 per festeggiare i 24 anni di PLC Forum

Per ulteriori informazioni leggi questa discussione: https://www.plcforum.it/f/topic/326513-28012025




marcia arresto con scl


Messaggi consigliati

Inserito:

Ciao a tutti mi sto approcciando all SCL non riesco a imbastire un marcia arresto con pulsante  e una bobina mi serve un esempio semplice

chiedo un aiuto grazie mille


Inserita:
marcia := (pbMarcia OR marcia) AND NOT pbStop;

Oppure:
IF pbMarcia THEN
	marcia := TRUE;
END_IF;
IF pbStop THEN
	marcia := FALSE;
END_IF;

Oppure:
if pbStop THEN
	marcia := FALSE;
ELSIF pbMarcia
	marcia := TRUE;
END_IF;

 

Non sono queste però le cose dove il linguaggio strutturato esprime il meglio.
Qui stiamo parlando di una logica molto banale, ma se dovessimo aggiungere molte condizioni, per rendere il codice leggibile dovremmo ricorrere ad appoggi a variabili intermedie.
Per quanto io non ami il ladder, ritengo che per questo tipo di logiche sia il linguaggio più adatto.
Se vuoi prendere confidenza con il testo strutturato, prova a fare calcoli e lavorare con array.

 

Inserita:

Beh fare un marcia arresto in SCL mi sembra eccessivo anche a me

ma pare bisognerà abituarcisi vista la tendenza a fare tutto in SCL o testo strutturato,

banalmente per chi viene dal mondo elettrotecnico il Ladder ha le sue convenienze visive e funzionali,

inoltre sei forse più sicuro della funzionalità,

spesso però mi trovo più a mio agio a usare il Ladder piuttosto che usare istruzioni SET RESET che se non usate con dovizia portano ad errori di funzionamento della logica voluta.

 

Inserita:
38 minuti fa, leleviola ha scritto:

ma pare bisognerà abituarcisi vista la tendenza a fare tutto in SCL o testo strutturato,

 

Se la tendenza è questa non mi pare che il mondo della programmazione stia evolvendo. A me pare invece che i nuovi editor stiando dando la possibilità di mixare i diversi linguaggi in modo che ad esempio nella stessa fc si possa  utilizzare ladder + scl: ecco questa la vedo come un'evoluzione...dare la possibilità al programmatore di adattarsi in funzione delle esigenze e di cò che deve fare utilizzando ciò che è congeniale. Ad esempio, al di là dello scopo formativo, fare un marcia arresto con scl non mi pare l'evoluzione...semmai il contrario....ma può essere che sbagli.

Inserita:
34 minuti fa, Lucky67 ha scritto:

Ad esempio, al di là dello scopo formativo, fare un marcia arresto con scl non mi pare l'evoluzione...semmai il contrario....ma può essere che sbagli.

No no non sbagli condivido in toto ciò che dici, più o meno tutti i marchi tendono ormai a farti usare ciò di cui hai bisogno, FBD, Ladder o STL nel medesimo ambiente o più o meno, è questo che giustamente è più utile, poi se uno vuole fare tutto in strutturato per riciclare il tutto da un marchio a un altro puoi farlo ma bisogna vedere uno cosa ha da fare, io per abitudine di lavoro sono spesso abituato a usare ciò che mi rende funzionale e comprensibile il software

Inserita:

e invece per i fronti la cosa e un po piu problematica in scl  perche devo sempre creare un programma in scl ma nel  main (OB1) devo inserire un  segmento con autoritenuta

vero?

Inserita: (modificato)

ops!

Modificato: da dott.cicala
Inserita:
6 ore fa, batta ha scritto:

marcia := (pbMarcia OR marcia) AND NOT pbStop;

Il pulsante di arresto non deve essere sempre normalmente chiuso?

Simone.Salarsi
Inserita:
2 ore fa, ottoz ha scritto:

e invece per i fronti la cosa e un po piu problematica in scl  perche devo sempre creare un programma in scl ma nel  main (OB1) devo inserire un  segmento con autoritenuta

vero?

guarda qui

 

 

Inserita:
3 ore fa, dott.cicala ha scritto:

Il pulsante di arresto non deve essere sempre normalmente chiuso?

La variabile che ho chiamato pbStop, non è detto che sia l'ingresso fisico al quale è collegato il pulsante di stop, ma potrebbe essere il cumulativo delle condizioni di stop.
Risulta molto più comodo ragionare senza invertire lo stato.

Inserita:
12 ore fa, dott.cicala ha scritto:

Il pulsante di arresto non deve essere sempre normalmente chiuso?

se fosse con logica negata dovresti collegare l'ingresso dello stop NO, penso sia più sicuro senza negare la logica dell'ingresso collegando l'ingresso NC rispetto al comune di alimentazione ingressi, quindi come giustamente dice batta meglio senza negare la logica

Inserita:

Se è un cumulativo non sarebbe opportuno evitare "pb" ed usare un altro simbolico?  Perché con pb davanti lascia supporre che sia un push button.

il pulsante di stop, se fosse tale, è  NC, quindi in stato di riposo, non azionato,  il suo ingresso è TRUE. Questo garantisce che in caso di rottura conduttore la marcia cada ed è prescritto dalla direttiva macchine.  Lo stesso non può avvenire se il pulsante è NO.

Se invece il pulsante è un touch switch proveniente da un HMI è necessario implementare degli accorgimenti che facciano cadere la marcia nel caso in cui l'hmi perda la comunicazione.

Una sorta di controllo rottura conduttore che, se la funzione marcia/arresto fosse realizzata in elettromeccanica, è già implicitamente presente.

 

Inserita: (modificato)
3 ore fa, dott.cicala ha scritto:

Se è un cumulativo non sarebbe opportuno evitare "pb" ed usare un altro simbolico?

Era solo un banale esempio.
In ogni caso, con "pbStop" posso definire una variabile che mi indica lo stato del pulsante (TRUE = pulsante premuto), non necessariamente lo stato dell'ingresso al quale il pulsante è collegato , ed evitare così di dover ragionare ogni volta su come sia stato cablato il pulsante.

La stessa cosa accade spesso con i finecorsa. Se devono arrestare un movimento, è più sicuro usare il contatto N.C. del finecorsa. Risulta però fonte di confusione dover poi scrivere il programma considerando che il movimento è arrivato sul finecorsa avanti quando NON ho il segnale dal finecorsa avanti.
Io mi giro sempre questi segnali.

 

3 ore fa, dott.cicala ha scritto:

Se invece il pulsante è un touch switch proveniente da un HMI è necessario implementare degli accorgimenti che facciano cadere la marcia nel caso in cui l'hmi perda la comunicazione.

Non mi risulta che questo sia un obbligo. Non dimentichiamo che non sono comandi di sicurezza. La sicurezza è altra cosa.
Inoltre, anche arrestare un ciclo potrebbe essere pericoloso.
Supponiamo poi il caso di un comando fatto da più pannelli operatore. Mi si guasta un pannello operatore, e non posso più operare?

Modificato: da batta
Inserita:
3 ore fa, batta ha scritto:

Supponiamo poi il caso di un comando fatto da più pannelli operatore. Mi si guasta un pannello operatore, e non posso più operare?

Non esiste un caso generico. Bisogna valutare che tipo di comando è e se è ammissibile che possa essere impartito contemporaneamente da più dispositivi di comando.

Questo lo si stabilisce durante l'analisi dei rischi.

3 ore fa, batta ha scritto:

Non mi risulta che questo sia un obbligo. Non dimentichiamo che non sono comandi di sicurezza. La sicurezza è altra cosa.

Dipende da che macchine fai

Inserita:

Stiamo parlando di comandi, non di dispositivi di sicurezza.
Poi, se su una macchina è richiesto che il comando di stop risponda a certi requisiti di sicurezza e, magari, anche di immediatezza, lo faccio con un pulsante fisico, non con un tasto su un HMI.

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...