Strano comportamento con un PLC s7-314

[AndreaBegolo]

Buon Giorno scrivo perché ho uno strano comportamento con un PLC s7314 che non riesco a spiegarmi…

 

 

In breve ho il rung nello screenshot allegato con un bit di sempre vero (FOTO1).

Come potete vedere anche se il bit è vero, il rung NON è VERDE e non esegue il codice!!!

 

Allora nelle mille prove ho pensato di fare come nella foto 2 (or dello stesso sempre vero) e come per magia il codice funziona!! Ma non ha senso essendo l’OR dello stesso bit.

 

Infine ho convertito il codice LAD in STL come in foto 3. Ho evidenziato che il RUNG entra con il registro RLO a 0!!! MA è una cosa impossibile (per quel che ne so)!

 

Onestamente non mi riesco a dare una spiegazione e non so proprio cosa controllare.

 

Se qualcuno ha qualche spiegazione è gradita.

 

[pigroplc]

semplice,

il segmento precedente NON è stato concluso dal punto di vista logico, quindi il risultato logico combinatorio è la combinazione di quanto c'è in precedenza.

Fai la prova del nove: crea un segmento in precedenza con l'AND di un flag non utilizzato e l'uguale di un altro flag non utilizzato.

Vedrai che funziona.....

 

infatti se metti l' OR di se stesso si mette in OR con tutta la catena in precedenza e quindi funziona.

 

[DesmoGiec]

Premesso che se m1.1 è true deve andare..

l'unica cosa che mi viene in mente è:

hai scritto in kop, poi switchato in awl per fare lavori in segmenti. avrai aggiunto variabili in temp che usano i bit creati dal kop per "visualizzazione".

 

In breve, controlla se L11.0 si frammischia con una variabile in temp.

 

[TravelMen]

La traduzione in AWL è la traduzione che fa STEP 7 del segmento in KOP, traduzione con "Visualizza => AWL" o più semplicemente CTRL+2

facendo questa operazione il programma usa l'area temp libera dopo quella usata da te

[DesmoGiec]

21 minuti fa, TravelMen scrisse:

La traduzione in AWL è la traduzione che fa STEP 7 del segmento in KOP, traduzione con "Visualizza => AWL" o più semplicemente CTRL+2

facendo questa operazione il programma usa l'area temp libera dopo quella usata da te

A volte capita che, su segmento kop si vada poi a switchare in awl, aggiungendo un campo in stat.

Ti esce l'avviso che l'area è già in uso, ma effettivamente non riesce più a generare la visualizzazione kop del segmento una volta che ritorni a visualizzazione kop, cosa che invece avviene in questo caso..

Non avevo letto il tuo commento @pigroplc pardon, sicuramente è come hai scritto tu! (stavo rispodendo ed ho lasciato la pagina sospesa, quindi il tuo commento non l'avevo ancora)

 

[TravelMen]

Quote

A volte capita che, su segmento kop si vada poi a switchare in awl, aggiungendo un campo in stat

 

 

Se parli di STAT il problema non si pone, penso che ti sei confuso, se aggiungi una TEMP allora non puoi tornare alla visualizzazione in KOP perché hai "sovrascritto"  l'area TEMP usata per la conversione in AWL, se devi farlo prima riconverti in KOP, aggiungi la tua variabile e riporti il tutto in AWL.

 

Concordo pienamente con quello che ti ha detto @prigroplc.

[freno85]

Sono un collega di Andrea che ha originariamente postato. 

Quanto dite voi mi tornerebbe se stessi all'interno di uno stesso rung (immagino scritto in AWL). Ovviamente la condizione logica precedente è falsa e da quel punto la "AND" restituirebbe falso...

 

Ma se cambio Rung, ancor di più se in KOP (ma anche AWL), non dovrebbe SEMPRE settare ad 1 l'RLO in modo da far funzionare il rung con quel sempre vero?

Altrimenti vorrebbe dire che in ogni possibile rung che inizia con un always on sarei dipendente dal rung precedente... E questa mi sembra molto strano. 

 

EDIT: aggiungo che la conversione in AWL del rung l'ho fatta solo per verificare l'RLO... il codice mi permette di tornare in KOP senza problemi. Riassumendo non ho toccato niente in AWL...

[DesmoGiec]

4 ore fa, TravelMen scrisse:

Se parli di STAT il problema non si pone, penso che ti sei confuso, se aggiungi una TEMP allora non puoi tornare alla visualizzazione in KOP perché hai "sovrascritto"  l'area TEMP usata per la conversione in AWL, se devi farlo prima riconverti in KOP, aggiungi la tua variabile e riporti il tutto in AWL.

Si scusa, avevo scritto temp nel post precedente ed ho poi fatto confusione ^^"

 

@freno85 in kop non puoi concludere un segmento senza bobina (o istruzione). in awl si, il plc lo interpreta come diretta prosecuzione del programma.

Nei segmenti da 1 a 5 che operazioni avete?

[freno85]

1 ora fa, DesmoGiec scrisse:

Si scusa, avevo scritto temp nel post precedente ed ho poi fatto confusione ^^"

 

@freno85 in kop non puoi concludere un segmento senza bobina (o istruzione). in awl si, il plc lo interpreta come diretta prosecuzione del programma.

Nei segmenti da 1 a 5 che operazioni avete?

 

aaah..questa tua ultima affermazione mi intriga.

Il codice è misto di AWL e KOP.

 

Allora vorrei capire capire meglio.

Se io ho un codice complesso in AWL e non chiudo con un operazione bobina o istruzione (immagino quindi =, S, R, JC) il network successivo è considerato come un proseguio e non mi setta l'rlo?? Mantenendo quindi ogni tipo di risultato logico precedente. 

 

Comunque l'iStruzione ultima del network precedente sono una serie di move come questa

//Net
      L     PID  508
      T     #Ws1_Aux_NW
 

ancora prima l'ultima istruzione logica è la seguente

      L     "INVERTER_CocSBBx".FromINV_LCR
      L     1
      <=I   
      JU    min1

      L     0
      T     "INVERTER_CocSBBx".FromINV_LCR

min1: NOP   0
 

Noto ora che nel codice ho un JU invece di un JCN...... quindi possibile che sia quel <=I che rompe le scatole??

Se ho inteso bene la tua affermazione allora penso di aver trovato una quadra. 

 

 

 

 

[DesmoGiec]

E' così, ma non è detto che sia dal segmento prima che rimanga rlc 0, può anche essere a distanza più ampia.

Se di mezzo ci sono solo istruzioni non modificanti l'rlc, la continuità l'avrai comunque.

Il tuo problema è che avete usato un salto assoluto, quel confronto non lo farete mai.

Che sia 1 o 0 l'rlc risultante, voi saltate comunque a min1.

 

ju equivale allo spa tedesco, e il salto assoluto non influenza l'rlc.

 

Il tuo rlc è influenzato in qualche segmento precedente, se ti va posta dal primo segmento.

(e poi sistemate quel salto, che è inutile così come l'avete usato )

[freno85]

1 ora fa, DesmoGiec scrisse:

E' così, ma non è detto che sia dal segmento prima che rimanga rlc 0, può anche essere a distanza più ampia.

Se di mezzo ci sono solo istruzioni non modificanti l'rlc, la continuità l'avrai comunque.

Il tuo problema è che avete usato un salto assoluto, quel confronto non lo farete mai.

Che sia 1 o 0 l'rlc risultante, voi saltate comunque a min1.

 

ju equivale allo spa tedesco, e il salto assoluto non influenza l'rlc.

 

Il tuo rlc è influenzato in qualche segmento precedente, se ti va posta dal primo segmento.

(e poi sistemate quel salto, che è inutile così come l'avete usato )

Chiarissimo.

Non sapevo della continuità tra network.. ed in qualche modo la vedo pure pericolosa...

Comunque ora che mi è chiaro ci starò attento. 

 

Ovviamente il JU è un baco. lo sto fixando mentre scrivo questo post.

 

grazie a tutti per l'aiuto.