Conversione Awl In Kop

[bluetooth]

Salve a tutti,

avrei bisogno di convertire questo listato scritto in awl in uno di tipo kop: uso un siemens s7300.

***************************************************

// RESET CONTROLS

SET

R #Broken_cable

R #Overflow

R #Over_limit

R #Under_limit

//;

// Limits confrontation

L #PEW_input

L 32767

==I

O(

L #PEW_input

L W#16#8000

==I

)

= #Broken_cable

SPB chk

TAK

L 32511

>I

= #Overflow

SPB chk

TAK

L 27648

>I

= #Over_limit

SPB hl

TAK

L 0

<I

= #Under_limit

chk: L 0

U #Broken_cable

O #Under_limit

SPB load

hl: L 27648

U #Over_limit

SPB load

L #PEW_input

load: T #Pew_value

//;

// Integer to real conversion

L #Pew_value

DTR

L 2.764800e+004

/R

T #Value_0_1

//;

// Scaled value

L #HIGH_range

L #LOW_range

-R

L #Value_0_1

*R

L #LOW_range

+R

T #Output_value_read

L #Output_value_read

L #offset

+R

T #Output_value_offset

//;

// Out

SET

SAVE

*************************************************************

Grazie a tutti per la vostra disponibilità, come sempre ringrazio anticipatamente.

Saluti Luca.

[Livio Orsini]

Te lo fa direttamente Step7

[bluetooth]

Ciao Livio,

lo so in genere ci riesco, vado nella finestra visualizza e faccio kop.

Questa volta non riesco a capire il perchè ma non me lo converte.

[kamikaze]

Tutto quello scritto in KOP e' convertibile in AWL , ma non viceversa, esistono delle convenzioni in KOP , che di norma non vengono prese in considerazione , salvo quando poi non lo converti in AWL, se poi fai modifiche in AWL senza rispettare quelle convenzioni, in KOP non ci ritorni piu'.

Analizzando il tuo AWL:

In un certo punto hai scritto ,

L #HIGH_range

L #LOW_range

-R

L #Value_0_1

*R

Questo segmento non lo tradurrai mai, perche per essere ritradotto in KOP deve essere:

U(

L #HIGH_range

L #LOW_range

-R

T #Dummy........... inserire variabile TEMP real

UN OV

SAVE

CLR

U BIE

)

SPBNB _002

L #Dummy

L Value_0_1

*R

T #Dummy........... inserire variabile TEMP real

_002: NOP 0

In questo caso ho messo i due box operazionali -R e *R , in serie sul ramo.

Se li avessi messi a scalare nel ramo sarebbe stato ancora diverso.

Se lo vuoi in KOP te lo devi riscrivere in KOP

Ivan

[Ecup]

Te lo fa direttamente Step7

Te lo fa se ha tutti i riferimenti necessari e non ci sono istruzioni o passaggi "particolari".

Non so se hai provato a fare il contrario, cioè da KOP a AWL... riempie il codice di un sacco di istruzioni inutili, che però servono per poter risalire al KOP (tant'è che se togli quelle non riesci più a tornare indietro)

Tornando al problema originario, perché hai bisogno di trasformarlo in KOP? Da un'occhiata veloce mi pare ben leggibile anche in AWL (se è questo il problema)

ciao

[bluetooth]

Volevo ringraziarvi per le vostre cortesi e chiare risposte.

Tornando al problema originario, perché hai bisogno di trasformarlo in KOP? Da un'occhiata veloce mi pare ben leggibile anche in AWL (se è questo il problema)

Il programma è chiaro anche scritto cosi, solo che in fase di simulazione lo seguo meglio se fosse scritto in kop, anche perchè ho sempre usato il linguaggio kop.

Provo a scriverlo in KOP se ci riesco

Saluti Luca.

[kamikaze]

Dalla mia esperienza , e' piu' facile tradurre "a mano" dal AWL al KOP che viceversa, anche senza considerare le convenzioni per la leggibilita'.

Forza e coraggio, vedrai che ce la farai!

Ad un buon programmatore, quello che non deve mai mancare sono, il coraggio e la pazienza.

Ivan

[Livio Orsini]

Ad un buon programmatore, quello che non deve mai mancare sono, il coraggio e la pazienza.

Parole sante, kamikaze (anche se, con quel nick, qualche sopsetto mi viene )

[lucios]

Non so se hai provato a fare il contrario, cioè da KOP a AWL... riempie il codice di un sacco di istruzioni inutili

Ecco un'altra di quelle ragioni per le quali la gente "ama" Siemens e il suo beneamato AWL :lol: .

Ciao

[kamikaze]

kamikaze (anche se, con quel nick, qualche sopsetto mi viene biggrin.gif )

E' vero Livio, ma e' un nomigliolo che mi trascino dagli albori della carriera quando ero disposto ad andare in capo al mondo a fare service, anche senza aver mai visto prima quel tipo di PLC , anche solo a mani nude! Ora con il favore dell'eta' e degli errori vissuti, ho fatto giudizio ma ancora adoro il mio lavoro!

Ecco un'altra di quelle ragioni per le quali la gente "ama" Siemens e il suo beneamato AWL laugh.gif laugh.gif .

Lucios, leggo un poco di malignita' nel tuo topics.

Se ci mettiamo a guardare i difetti degli editors , tra tutti stiamo qui fino a domani.

Ivan

[Savino]

Se ci mettiamo a guardare i difetti degli editors , tra tutti stiamo qui fino a domani.

Concordo... e forse fino ad anche una settimana!

Poi, per la rappressentazione LAD (KOP) il codice dovrebbe innanzitutto venire subdiviso in segmenti ...

[batta]

Senza pensare poi che altri plc permettono sempre la conversione da lista istruzioni a ladder per il solo fatto che ti permettono di scrivere in lista istruzioni solo segmeni traducibili in ladder.

Cerco di spiegarmi meglio: con Siemens in awl puoi scrivere cose che non si possono tradurre in kop, ma che funzionano meglio, non fosse altro perché si saltano operazioni.

Altri plc invece non ti consentono questa libertà; anche in lista istruzioni sei costretto a rispettare stretti vincoli, senza poter lavorare a ruota libera saltando la ripetizione di operazioni inutili. Facile in questo modo convertire sempre e comunque anche in ladder.

Modificato: 25 maggio 2007 da batta

[lucios]

Lucios, leggo un poco di malignita' dry.gif nel tuo topics.

Ma và... da cosa lo hai capito :lol: ?

No, scherzi a parte, pur non considerandomi un esperto in Siemens, ho fatto alcune interessanti applicazioni col medesimo e penso di poter dire che:

E' un plc potente (dal 300 in su) e che ti permette di affrontare praticamente ogni problema (ed ha un'ottima dotazione di hardware), ma, quello che non mi va giù e che nel 2007 uno si debba preoccupare ancora del RLC per programmare!

Mi sembra di essere tornato a 20 anni fa quando avevi a disposizione un macro assembler e avevi listati chilometrici di AND, OR e ST!

E il ladder (come evidenziato da vari post precedenti) non è certo il massimo della categoria e non ci puoi, in ogni caso, far tutto.

Tutto qui.

Ciao

[Ecup]

Ecco un'altra di quelle ragioni per le quali la gente "ama" Siemens e il suo beneamato AWL

Non credo di aver capito cosa vuoi dire... comunque personalmente quando uso Siemens programmo esclusivamente in AWL, e se devo mettere le mani su sw di altri realizzato in LAD, la prima cosa che faccio è convertire in AWL e togliere tutto ciò che non è necessario.

Se poi dobbiamo metterci a confrontare i vari editor, non finiamo più... ognuno ha pro e contro (qualcuno più contro che più), e anche per la scelta del linguaggio, io preferisco quelli tipo AWL, ma spesso dipende anche dal tipo di applicazione e dalle richieste del cliente (con certi PLC non puoi scegliere...)

ciao

[Livio Orsini]

Mi sembra di essere tornato a 20 anni fa quando avevi a disposizione un macro assembler e avevi listati chilometrici di AND, OR e ST!

E si, sarebbe un mondo migliore se tutti i PLC si programmassero in "C" ANSI.

Massima comprensibilità, massima portabilità. Accidenti ma forse è proprio questo che disturba i costruttori di PLC

[Matteo Montanari]

Il programma è chiaro anche scritto cosi, solo che in fase di simulazione lo seguo meglio se fosse scritto in kop, anche perchè ho sempre usato il linguaggio kop.

tutti hanno bisogno di accertarsi che il codice scritto funzioni...

ti assicuro che il codice che hai scritto (copiato) è corretto e funzionante...

per tradurlo in KOP, se vuoi devi scomporlo in tanti segmenti... cosa assolutamente inutile, in quanto è stato già fatto a suo tempo per il debug.

comunque:

// RESET CONTROLS

SET

R #Broken_cable

R #Overflow

R #Over_limit

R #Under_limit

primo segmento, azzeri tutti i controlli e bit utilizzati nella funzione.

// Limits confrontation

L #PEW_input

L 32767

==I

O(

L #PEW_input

L W#16#8000

==I

)

= #Broken_cable

SPB chk

secondo segmento confronti la variabile di ingresso con i limiti che ti permettono di controllare se il cavo è interrotto, nel caso saltare ad etichetta chk in quanto non ha senso esguire nessun altro controllo.

TAK (sostituisce l'istruzione L #PEW_input, prendendo il dato dall'accumulatore, #PEW_input appunto)

L 32511

>I

= #Overflow

SPB chk

terzo segmento confronti la variabile di ingresso con i limiti che ti permettono di controllare se il valore è in Overflow (dati riportati nei cataloghi Siemens in riferimento ai segnali analogici), nel caso saltare ad etichetta chk in quanto non ha senso esguire nessun altro controllo.

TAK (sostituisce l'istruzione L #PEW_input, prendendo il dato dall'accumulatore, #PEW_input appunto)

L 27648

>I

= #Over_limit

SPB hl

quarto segmento confronti la variabile di ingresso con i limiti che ti permettono di controllare se il valore è in Overlimit (dati riportati nei cataloghi Siemens in riferimento ai segnali analogici), nel caso saltare ad etichetta hl in quanto non ha senso esguire nessun altro controllo.

TAK (sostituisce l'istruzione L #PEW_input, prendendo il dato dall'accumulatore, #PEW_input appunto)

L 0

<I

= #Under_limit

quinto segmento confronti la variabile di ingresso con i limiti che ti permettono di controllare se il valore è in Underlimit (dati riportati nei cataloghi Siemens in riferimento ai segnali analogici), nel caso saltare ad etichetta hl in quanto non ha senso esguire nessun altro controllo.

chk: L 0

U #Broken_cable

O #Under_limit

SPB load

hl: L 27648

U #Over_limit

SPB load

L #PEW_input

load: T #Pew_value

qui esegui il cariamento delle varibili a seconda dei confronti avvenuti in precedenza...

L #Pew_value

DTR

L 2.764800e+004

/R

T #Value_0_1

qui ricavi il primo dato necessario per la scalatura, praticamente dividi il valore letto per i punti di risoluzione

L #HIGH_range

L #LOW_range

-R

L #Value_0_1

*R

L #LOW_range

+R

T #Output_value_read

qui esegui la scalatura, in base ai valori impostati di massimo e minimo.

praticamente è come scrivere:

L #HIGH_range

L #LOW_range

-R

T APPOGGIO

L APPOGGIO

L #Value_0_1

*R

T APPOGGIO

L APPOGGIO

L #LOW_range

+R

T #Output_value_read

----

L #Output_value_read

L #offset

+R

T #Output_value_offset

qui viene sommato un valore di offset (anche negativo se si vuole) al risultato, per ottenere una precisione maggiore o rendere il valore più simile al reale (se presente uno strumento di controllo)

//;

// Out

SET

SAVE

per chiudere il blocco e permettere di elaborarne un altro utilizzando "EN".

[nick.kelevra]

E si, sarebbe un mondo migliore se tutti i PLC si programmassero in "C" ANSI.

Massima comprensibilità, massima portabilità. Accidenti ma forse è proprio questo che disturba i costruttori di PLC

Livio, ti quoto pienamente e a malincuore.

[Ecup]

E si, sarebbe un mondo migliore se tutti i PLC si programmassero in "C" ANSI.

IMHO sarebbe meglio se tutti i PLC si potessero programmare *anche* in "C", e non solo in quel modo

Massima comprensibilità, massima portabilità. Accidenti ma forse è proprio questo che disturba i costruttori di PLC

Beh... massima comprensibilità per chi ci è avvezzo... chi è solito programmare in Ladder non credo che sarebbe facilitato...

Massima portabilità? Anche qui dipende... ogni PLC ha un suo hardware specifico, e usare lo stesso linguaggio per tutti diventerebbe una forzatura, oppure il compilatore sarebbe costretto a generare codice "sporco" penalizzando le prestazioni... pensa solo al fatto che certi PLC hanno un numero limitato di Timer, mentre altri ne hanno infiniti. E comunque anche chi programma in "C" scrive determinate cose in un linguaggio di più basso livello quando è necessario, magari con istruzioni specifiche per il sistema dedicato. Anche nel mondo dei PC un programma scritto in "C" non è univocamente compilabile ed eseguibile indistintamente su Win, *nix, Mac, ecc...

Secondo me cosa migliore è utilizzare PLC che consentano di scrivere utilizzando più linguaggi, in modo tale che si possa scegliere il linguaggio più adatto alla situazione, e ci sono diversi PLC che lo consentono. Poi ovviamente bisogna sempre fare i conti col cliente, che in certe situazioni ha il "potere" di imporre la sua scelta

ciao