Puntatori E Variabili Locali

[lucios]

Scusate se pongo una domanda forse banale, ma è un sacco di tempo che non lavoro in AWL e sto andando un po in confusione.....

anche perchè ho fatto in passato solo applicazioni semplici che non andavano a scomodare i puntatori.

Dunque...

Ammettiamo di avere una FB in cui nelle variabili locali STAT sono stati definiti 2 array di byte del tipo:

Pippo Array [0..31] Of Byte

Pluto Array [0..31] Of Byte

Io voglio semplicemente fare un loop per copiare Pippo in Pluto (in realtà devo anche modificare alcuni byte ma il problema non è li).

      L     P##Pippo                                        //in questo modo non creo 2 puntatori alle variabili?
      LAR1  
      L     P##Pluto
      LAR2  

      L     31
NEXU: T     #Count                      //loop 

      L    LB [AR1,P#0.0]
      T    LB [AR2,P#0.0]

quì ci mancano gli incrementi dei puntatori sui quali mi sono
incasinato!!

RETL: L     #Count                      //return loop
      LOOP  NEXU

A parte l'incremento dei puntatori per copiare tutte e 32 i bytes, già così il codice mi manda in stop la cpu con un errore :

"Errore di lunghezza di campo in lettura".

Dove sbaglio?

[batta]

Prima di tutto, ti sconsiglierei di utilizzare AR2.

Cito da manuale Siemens:

Il registro DI ed il registro indirizzi AR2 vengono utilizzati dal sistema per il CALL FB e CALL multi-istanza e non devono quindi essere modificati all'interno degli FB.

Poi l'errore è causato dal fatto che gli array Pippo e Pluto sono dichiarati nei dati STAT, quindi fanno parte del DB di istanza, e non sono "Dati Locali".

Per "Dati Locali" si intendono quelli dichiarati nell'area TEMP.

Non devi quindi richiamarli come "LB" ma semplicemente come "B".

Altro piccolo errore nel tuo codice è che devi inizializzare il contatore del loop a 32 (array 0..31 sono 32 oggetti), e non a 31.

Se l'offset tra i due array è fisso e noto, tutto diventa estremamente semplice.

Vedi esempio (suppongo array "Pluto" inizi subito dopo array "Pippo", quindi con offset di 32 byte):

      LAR1  P##Pippo

      L     32
NEXT: T     #ID

      L     B [AR1,P#0.0]
      T     B [AR1,P#32.0]

      L     P#1.0
      +AR1  

      L     #ID
      LOOP  NEXT

Modificato: 10 agosto 2010 da batta

[mubeta]

Se proprio vuoi utilizzare AR2, (lo salvi prima di iniziare il loop e lo rinfreschi appena concluso), e non ti è noto l'offset tra i due array, sfruttando tutti i 32 bit della CPU:

L P##pippo

LAR1

L P##pluto

LAR2

L 8

T #iter

next: L LD [AR1,P#0.0]

T LD [AR2,P#0.0]

TAR1

L 32

+D

LAR1

TAR2

L 32

+D

LAR2

L #iter

L 1

-I

T #iter

JN next

NOP 0

[batta]

Per pura curiosità, ho provato a risolvere il problema in SCL con un semplice ciclo FOR NEXT.

Il codice risulta estremamente intuitivo, come si vede dall'esempio (senza dichiarazione variabili):

    FOR ID := 0 TO 31 DO
        pluto[ID] := Pippo[ID];
    END_FOR;

Peccato che, mentre l'FB scritta in AWL occupa solo 76 byte, quella scritta in SCL ne occupi 152!!! Se si fa una copia dell'FB in modo da vedere il codice AWL generato, ne viene fuori quanto segue:

      SET   
      SAVE  
      =     L      2.1
      L     0
      T     #ID
A7d0: L     #ID
      L     31
      <=I   
      SPBN  A7d1
      L     #ID
      ITD   
      L     L#16
      *D    
      TAR2  
      +D    
      L     #ID
      ITD   
      TAK   
      T     LD     4
      TAK   
      L     L#16
      *D    
      TAR2  
      +D    
      LAR1  
      L     DIW [AR1,P#0.0]
      LAR1  LD     4
      T     DIW [AR1,P#64.0]
      L     #ID
      L     1
      +I    
      T     #ID
      SPA   A7d0
A7d1: CLR   
      U     L      2.1
      SAVE  
      BE

Modificato: 10 agosto 2010 da batta

[batta]

Altra possibile soluzione in AWL, con offset tra Pippo e Pluto non noti:

      L     P##Pippo
      T     #AdrSorg

      L     P##Pluto
      T     #AdrDest

      L     32
NEXT: T     #ID

      L     DIB [#AdrSorg]
      T     DIB [#AdrDest]

      L     #AdrSorg
      +     8
      T     #AdrSorg

      L     #AdrDest
      +     8
      T     #AdrDest

      L     #ID
      LOOP  NEXT

Dove AdrSorg e AdrDest sono variabili TEMP DINT.

E siamo a 106 byte contro i 152 dell'SCL.

[walterword]

usa SCL , meno rogne e piu veloce nella progettazione

ciao

walter

[mubeta]

E siamo a 106 byte contro i 152 dell'SCL.

Se vogliamo fare a gara contro lo SCL, non c'è da sudare molto.

Però, a parte tutto, lo prediligo. I linguaggi strutturati, (a parte questo di STEP 7), sono più immediati, sempre che non si pensi al PLC solo come sostituto di relè e temporizzatori, (pensiero ancora troppo comune).

Non voglio ripetere ora i perché dei FUP, KOP, AWL, ecc.; ognuno si tenga le sue abitudini e ragioni.

[batta]

Io dico che si deve usare il linguaggio più adatto considerando tutti i pro e i contro.

Il fatto che per fare la stessa cosa si passi da 76 a 152 byte (i dati STAT della FB non si muovono da soli, quindi l'offset tra Pippo e Pluto è sicuramente noto), non sempre è trascurabile.

Se poi, all'interno della stessa FB, ci sono altri calcoli, magari sempre con puntatori, per cui l'uso dell'SCL può apportare vantaggi a livello di scrittura di codice (vantaggi comunque solo per chi scrive, non certo per la cpu), ben venga.

Se nella FB in questione non ci sono altre parti che risulti comodo programmare in SCL, non vedo perché si debba usare l'SCL.

Riporto di nuovo il codice in AWL:

      LAR1  P##Pippo

      L     32
NEXT: T     #ID

      L     B [AR1,P#0.0]
      T     B [AR1,P#32.0]

      L     P#1.0
      +AR1  

      L     #ID
      LOOP  NEXT

Mi pare che di complicato non ci sia proprio nulla.

In compenso, il codice risultante è esattamente la metà.

Forse c'è chi è abituato a lavorare solo con super cpu per cui memoria e tempo ciclo non sono mai un problema.

A me capita abbastanza spesso di riempire cpu oltre l'80%.

Se scrivessi tutto in SCL dovrei passare a cpu superiori.

L'SCL è bello e comodo per alcuni scopi, ma genera un codice abominevole.

Personalmente non ho mai trovato problemi che mi abbiano costretto a usare l'SCL perché troppo difficili da risolvere in AWL. Con l'AWL ho sempre fatto tutto quello che volevo.

Che ci volete fare ragazzi, sarà per l'età ma è più forte di me: quando vedo un codice che fa grande spreco di risorse, mi si chiude lo stomaco.

[Luca Bettinelli]

Ragazzi, vediamo di non fare una guerra di religione sul linguaggio di programmazione migliore.

Nella mia esperienza, anche se breve di programmazione, ho avuto modo di appurare che non esiste un linguaggio migliore dell'altro in senso assoluto, ognuno ha le sue peculiarità e deve essere chi lo usa che decide, per quella funzione, quale linguaggio preferisce usare, in base alla sua esperienza e perché no anche in base alla sua simpatia personale per uno o per l'altro.

Nei miei programmi ho sempre utilizzato KOP, AWL ed SCL a seconda del blocco e della funzione che stavo creando, a volte anche in contrasto con i miei colleghi che avrebbero preferito quella funzione scriverla con un linguaggio diverso, ma alla fine quello che conta è il risultato, ovvero che l'impianto sia funzionante.

[lucios]

Grazie ragazzi, mi stavo perdendo in un bicchier d'acqua..... , d'altronde ho un disperato bisogno di ferie .

Per Batta:

Perchè devo inizializzare a 32 il loop?

Se conta fino a 0 faccio 33 cicli (0 --> 32), oppure calcola il decremento alla fine (tipo un Do While > 0) e il ciclo con il contatore a 0 non lo esegue?

P.S.

Non uso SCL perchè non ce l'ho e non voglio comprarlo, anche in altre occasioni ho ribadito che Siemens dovrebbe fare una politica differente per quanto riguarda la vendita del software.

Le licenze su chiavetta sono assurde su un prodotto così specialistico. Non dico che vorrei avere step7 gratis, ma perchè devo essere costretto a comprare 3 licenze (care!) se in ditta siamo in 3 a lavorare con Siemens?

La Siemens guadagna vendendo PLC e CNC o vendendo licenze?

Grazie ancora a tutti

[walterword]

io uso tutti i linguaggi in ogni progetto

Per lo spostamento , modifica , copia , elimina di dati complessi espressi in array di strutture di array di strutture oppure per calcoli abbastanza malefici uso solo SCL da cira 10 anni .

Problemi non ne ho mai avuti e le cpu sono delle saette , considerando la lentezza di natura s7 .

Poi uso kop , awl per rendere codice piu compatto in routine o funzionalità testate e ripetute .

Punto .Senza alcuna polemica o gara sui linguaggi .Le gare non le faccio nemmeno per le donne .

comunque , l'automazione sta diventando sempre piu una nicchia dell'informatica .

Lo dimostrano molti costruttori tipo Beckhoff .

Si programmano i sistemi con un porting di codesys e dal 2010 ogni funzione di Twincat e' supportata da Visual Studio 2010 .

Significa che creando un nuovo progetto di visual studio si crea anche il sistema , dall'hw al sw .

si potra programmare nei classici linguaggi IEC oppure in c++ , magari per qualche routine particolare.

In c# invece si potra programmare la parte hmi .

I pc hanno due kernel , uno plc integrato ed indipendente ed uno sotto Ce o xp embedded .

Questo e' futuro e automation .Il bus ethercat poi dispone devices di sicurezza , piltoaggio in safaty con inverters e drive , con sew , wago ect ect .

Da programmatore specializzato e scoppiato siemens dico che ormai e' tempo di cambiar pagina

ciao

walter

p.s. ormai nemmeno i microprocessori o microcontrollori da 2 euro si programmano piu in assembly , esiste il C ed altro .

Sarebbe ora che mamma siemens si dia una bella ripulita ed inizi a pensare seriamente , il load - transfer ormai e' roba obsoleta

Modificato: 11 agosto 2010 da walterword

[batta]

Per Batta:

Perchè devo inizializzare a 32 il loop?

Perché il loop non viene più eseguito quando il conteggio è zero.

Non uso SCL perchè non ce l'ho e non voglio comprarlo, anche in altre occasioni ho ribadito che Siemens dovrebbe fare una politica differente per quanto riguarda la vendita del software.

Le licenze su chiavetta sono assurde su un prodotto così specialistico. Non dico che vorrei avere step7 gratis, ma perchè devo essere costretto a comprare 3 licenze (care!) se in ditta siamo in 3 a lavorare con Siemens?

La Siemens guadagna vendendo PLC e CNC o vendendo licenze?

Su questo, impossibile non essere assolutamente d'accordo.

Per Walter:

Che la scelta migliore sia quella di utilizzare il linguaggio più adatto per ogni singola occasione, penso di averlo già detto anch'io.

Nel caso specifico tirare in ballo l'SCL per una cosa così semplice, non mi pareva il caso.

Ho comunque illustrato per primo, se non sbaglio, la chiarezza della routine scritta in quel linguaggio.

Unica cosa che ho fatto notare è che questo ha un costo da pagare in termini di occupazione di risorse. In alcuni casi questo è ininfluente, in altri no.

Non cercate quindi di farmi passare come detrattore dell'SCL, perché non lo sono.

Bello sarebbe se, come per KOP e AWL, i due linguaggi potessero convivere nella stessa funzione: un pezzo in KOP, uno in AWL, un altro in SCL.

Purtroppo invece, se fai una funzione in SCL è tutta in SCL e basta.

Per quanto riguarda programmazione in altri linguaggi tipo C++ e simili, ben venga, ma deve cambiare anche l'hardware. E non mi pare che tutti i costruttori di plc si si sano buttati su quella strada.

A me pare che la grande maggioranza dei plc sia ancora legata ai linguaggi classici, appunto, dei plc.

Poi non capisco questa avversione per l'AWL. Io lo trovo un linguaggio estremamente versatile e "lineare": scrivi le istruzioni una alla volta così come verranno eseguite.

Comunque nessuno vi obbliga ad usarlo, ma è innegabile che, rispetto ad altri linguaggi, offra anche dei pro e non solo dei contro.

[mubeta]

Allora, butto giù ancora l'ultima mia:

AWL, KOP, FUP, hanno questo grande handicap, (come grapchet e simili): l'editor è molto lento, il copia incolla non è immediato, STEP 7 è orientato all'indirizzamento assoluto, (anche se impostabile in modo simbolico, ma non è completo). Certo, è tutta questione di abitudine, ma, vogliamo paragonare la scrittura di un gestore di ricette scritto in SCL, rispetto a scriverlo in AWL? (Certo, FUP e KOP sono più immediati in fase di debug). Ben vengano anche questi nel contesto in cui ha senso usarli.

E ben vengano C, C++ e compagnia, ma sarà un passo difficile. (un poco come l'eliminazione della 232 dai PC). Che mercato offre oggi migrare in linguaggi esclusivamente mnemonici? Quanti disegnatori di contatti in KOP resterebbero fermi? Ovvero che fetta di mercato andrebbe persa? Io ne incrocio tantissimi quotidianamente, ben allocati in aziende anche prestigiose. Immagino che quando i "capi" decidono cosa darci in pasto, tengano in buona considerazione anche questo aspetto. (Mettere sul mercato una CPU che poi non viene comprata dalla stragrande maggioranza perché inutilizzabile, non è una bella strategia).

Daltro canto quanta gente conoscete che "sà mettere le mani su un PLC"? E quanti di costoro, ad esempio, partecipa a questo, od altri forum?

Sono andato fuori tema, quindi la chiudo qui.

Buona vacanze.

[walterword]

a mio parere il concetto "programmare plc " dovrebbe essere sostituito con "programmare macchine ed impianti " in una certa maniera , con diagnostica , mail , allarmi , avvisi e quant'altro possa permettere l'operatore di ripartire sempre con i dovuti modi e precauzioni .

La parola plc e' nauseante ed eccentrica .

Chi progetta automazione deve avere una prospettiva piu ampia mirata allo scopo finale .

Nei miei impianti , da anni a questa parte , nessuna ha l'esigenza di mettere le mani nel sw del plc .

Nei pannelli c'e' la diagnostica , i messaggi per partire coi cicli , cosa fare se il ciclo va in allarme , come ripartire e da dove .

La macchina sottostante , in questo i plc , non devono nemmeno essere menzionati .

Quando la macchina o l'impianto sono collaudati nessuno ha necessita di mettere mani nel plc .

Un buon manuale operatore deve spiegare le operazioni da eseguire , i pulsanti da premere , le pagine con le condizioni di start , i motivi di uno shutdown , il reset dei passi , e le ripartenze con relative memorie settabili/resettabili da pannello .

In caso di errore gli opportuni controlli danno ulteriori allarmi ed i cicli non startano .

Non scrivere porcherie in kop senza commenti o sw mal gestiti che necessitano il continuo intervento dei manutentori dello stabilimento che devono collegarsi al plc per capire cosa succede .

Questo intendo io per automazione industriale .

ciao

walter

[flavia]

Sono perfettamente d'accordo con il pensiero di walterword. Sono da anni abituata a programmare DCS, ma ultimamente per esigenze di mercato è stato necessario programmare anche qualche PLC siemens.

Nei DCS si può impostare in pochi minuti una logica mediamente complessa usando dei blocchetti software molto specializzati, con l'ausilio dell'immediatezza della grafica. Ho visto diverse volte clienti con nozioni di PLC tradizionali molto interessati da questo sistema..

Ovviamente i tempi di ciclo fanno ridere rispetto a quelli di un PLC, ma il problema non è questo.

Personalmente reputo ridicolo che nel 2010 si programmino scatolini con 32 kb di ram e una CPU che non usano nemmeno nei cellulari, usando lo stesso linguaggio di 30 anni fa, quando per programmarli si usano PC con 4 GB di ram e processori che fanno impallidire i supercomputer di 15 anni fa.

Se lo stesso codice scritto in SCL occupa il doppio di quello in AWL è perché alla cara siemens non interessa fornire un compilatore VALIDO, forse perché non c'è richiesta oppure sarà per ragioni commerciali.

Realizzare in SCL l'equivalente di un blocchetto di gestione valvola di un DSC occupa un paio d'ore e in totale saranno un centinaio di righe. Lo stesso realizzato in AWL può essere fatto solo a livello amatoriale, dove il tempo impegato non costa nulla, per non parlare poi dei tempi di debugging..

Al cliente importa il costo del lavoro nel complesso, e i fattori sono 2: il costo dello scatolino (costo tenuto alto solo per questioni di mercato dai produttori) e costo di sviluppo, dato dalla bontà o meno degli strumenti di programmazione messi a disposizione.

Ciao

[Livio Orsini]

Al cliente importa il costo del lavoro nel complesso, e i fattori sono 2: il costo dello scatolino (costo tenuto alto solo per questioni di mercato dai produttori) e costo di sviluppo, dato dalla bontà o meno degli strumenti di programmazione messi a disposizione.

Concordo completamente con queste tue enunciazioni.

Visti i volumi di produzione, l'automatizzazione della stessa ed i costi dei materiali, gli attuali Hw dovrebbereo costare almeno il 50% del prezzo attuale.

Se poi si considera che i costi della mano d'opera specializzata (intellettuale) tendono a cresce, metre quelli dei materiali hanno tendenza inversa, gli strumenti di sviluppo dovrebbero essere molto più performanti. Se fossero regalati si potrebbe anche accettare qualche deficienza, invece vengono venduti a prezzi decisamente alti quindi questo è ache meno tollerabile.

Ad esempio non si capisce, anzi lo si capisce benissimo, perchè i maggiori produttori di PLC non forniscano un compilatore "C" standard. Si avrebbe la massima portabilità del software applicativo, ma questo diminuirebbe l'artificiosa "fidelizzazione" del cliente.

[walterword]

ciao Flavia , ciao Livio .

Per impianti dove si necessita di comunicazioni appropriate con pc piuttosto che stampanti o altro , se non viene usato opc server che rende al plc il tutto trasparente , bisogna implementare i sockets con programmazione a basso livello.

In awl non se ne viene fuori piu , ricordo un lavoro fatto da un collega che se ne ando prima che arrivassi io , nell'azienda dove lavoro da quasi 3 anni .

Uno dei problemi principali che noto durante le discussioni con la direzione e' che il cliente finale talvolta si preoccupa di volere questo piuttosto che quello.

Voglio il plc siemens , voglio l'inverter , voglio i morsetti pinco e via dicendo .

Posso capire una multinazionale come ist , sca ect nel campo della carta .

Nel campo dei pallet e imballatrici abbiamo venduto a tutti , grandi marche che hanno un team di manutenzione con programmatori (spesso poveri disgraziati pasticcioni che pensano di risolvere il tutto con qualche setta e resetta di merker senza nemmeno un simbolico misero ) , magazzini con pezzi di ricambio ect .

In molti altri casi cono i nostri venditori , compresi i boss , che hanno paura a proporre qualcosa di nuovo , innovativo e decisamente meno costoso , faccio un esempio :

una macchinetta che vendiamo spesso ,che interpreto come piccolo polmone tra un grosso impianto e l'altro , e' sempre piu sottoposta a continui sconti e "ricatti " da chi acquista .Queste macchinette vanno in luoghi dove non sanno nemmeno cosa sia una lampadina , e comunque non necissatano di alcun intervento sul plc in quanto hanno tutto il necessario per capire cosa succede e cosa si deve fare per ripartire con un ciclo piuttosto che un altro , il tutto nonostante gli schifosissimi pannellini op che mi fanno venire il volta stomaco solo a vederli.

Ebbene , la macchina ha una cpu313 con a bordo analogiche per piltoare due inverter .

Ha un sistema di rele di sicurezza , una logica che permette di caricare bobine passando davanti al muting o alle fotocellula di sicurezza senza andare in allarme durante la fase preposta , un quadro piu grosso della stessa macchina , 4 celle di carico con un visualizzatore che in seriale comunica con un pc che avendo il pc express ha una scheda seriale che costa 90 euro e che non garantisce il corretto funzionamento in quanto l'applicazione scritta in delphi 10 anni fa non ha i driver aggiornati .

Migliaia di euro buttati nel cesso e tanti problemi , tutti i giorni , in tutto il mondo .

Ho fatto una ricerca e ho valutato delle proposte da beckhoff .

Un bel pc con kernel plc , I/O decentrati , Hmi per stampare etichette , celle di carico in bus , minor spazio nei quadri , eliminazione dei rele di sicurezza , eliminazione dei segnali analogici in quanto con sew per esempio si puo usare ethercat che e' certificato per la sicurezza ..... costo inferiore alla meta dell'attuale , macchina compatta ed integrata .

Risposta : ...si lo faremo piu avanti , adesso i clienti vogliono cosi ....e poi si lamentano che vendendo a basso costo non vorrebbero mettere questo , non vogliono mettere quell'altro ect .

Ormai non mi incazzo piu nemmeno e non rispondo piu nemmeno alle chiamate dei clienti che si lamentano .

Le soluzioni innovative , valide , economiche e compatte ci sono se si vogliono provare .

Purtroppo siamo in mano ad una massa di incompetente che pensano di risolvere il tutto al telefono o pensando che il programmatore faccia dei miracoli ,e perdono soldi continuamente ahahahahahah

Il plc va bene come regista di impianto , ma per macchine speciali o particolari ci vogliono sistemi embedded o pc - plc integrati .

ciao

walter

[walterword]

con un caro amico , tempo fa , abbiamo preso un pc con xp embedded.Settato il tempo a 1 ms tramite una API di windows .

Messo schede di acquisizione wago , e scritto l'intero programma in c# con diversi thread con mutex e semafori per sincronizzare il tutto .

Il pc legge ogni 1 ms da una libreria modbus tcp/ip , e un altro thread svolge il processo delle logiche anche complesse .

Un altro thread piu lento e con minori priorità gestisce la stampa e muore e fine operazione .

Un thread gestisce la coda dei messagi di winzoz , pulsanti , griglie dati , carico file xml , salvataggio ect .

Abbiamo creato un sistema plc integrato che e' una meraviglia e funziona tuttora senza problemi .

Nei pc integrati , beckhoff non ha fatto altro che scrivere un kernel sicuro e testato per la parte che processa le logiche plc e le comunicazione , indipendenti da win CE o xp che fa girare l'hmi .

Un pc normale ha un core i5 .Anche pentium IV , sapere quanta logica che fa girare ?

Nel plc siemens ci sono ancora gli infineon a 8 bit ridicoli , e quando la flash non e' sufficiente si deve prendere una cpu maggiore .

Le cpu S7-414 o 415 sapete quanto le fanno pagare ? Dentro c'e' una flash che possiamo trovare a bordo di un DsPic

ahahahahahaahah

e tutti comprare ,e via ......

Modificato: 12 agosto 2010 da walterword

[walterword]

livio , magari il C per i plc non e' proprio indicato , anche se a me piacerebbe .

Pero molte case hanno gia sviluppato il porting sui loro sistemi di CodeSys .

l'ho usato con gli inverter SEW e le stesse logiche provate sui sistemi Beckhoff .

Wago idem e molti altri .

Codesys e' un pacchetto di compilatori , gratuito , con ladder , fup , IL , ST , Grafset ect ed anche un hmi .

Le case costruttrici dovrebbero guadagnare con l'hw e la differenza oltre alle prestazioni la deve fare il tool di programmazione perche poi alla fine una cpu o un fpga o la ram o la flash sono sempre la stessa cosa .

Con step 7 V5.4 e' rimasto tutto uguale , nessuna novita , nessun nuovo linguaggio o modo espressivo .

Wincc flexible e' buono , nei pannelli Ce scrivono valanghe di script per venirne fuori e non appesantire il plc , ma e' troppo pesante e ci son troppi rischi che un giorno avvi il pc non va questo , oppure non vede le licenze , oppure wincc non e' piu integrato a step 7 , oppure Starter ( che uso con grande soddisfazione per gli inverter ) va in conflitto con internet explorer , oppure sky-pe non ti fa aprire la vat di step 7 , oppure devi installare firefox per comunicare con opc scout opc server .

Son tutti pacchetti patch con file exe che risalgono a carlo cudega .figuriamoci poi quando faranno il tutto per win 7

Ormai ono sempre piu convinto di cambiare mestiere

[Livio Orsini]

livio , magari il C per i plc non e' proprio indicato , anche se a me piacerebbe .

Cia Walter, fa piacere risentirti dopo lunga assenza.

Perchè pensi che il "C" non sia adatto per programmare i PLC? Non ci sono problemi per risolvere equazioni booleane in "C"; eventualmente i problemi li hanno quegli utenti che non conoscono il "C" e programmano (si fa per dire) esclusivamente in "ladder diagram".

Io non son mai stato un grande estimatore dei sistemi Siemens, ad eccezione del 200 e di quelli basati Hw simil PC e sitema operativo RTOS (purtroppo defunti). Devo però ammettere che anche gli altri "grandi" hanno un approccio molto simile a Siemens. Hw caro, tools di sviluppo con prezzi che assomigliano a furti, ottimizzazioni dei compilatori che son ridicole e via elencando. Sono molto meglio alcuni piccoli che, lavorando in nicchie particolari, offrono soluzioni molto più performanti. Basti apragoanere VIPA a Siemens e già si hannno notevoli vantaggi, pur mantenendo compatibilità Hw e Sw.

I sistemi Beckhoff, ma anche altri, offrono notevoli vantaggi. Usando un SO non WINDOW, eliminando quindi il principale punto debole del sistema basato su Hw simil PC, permettono prestazioni notevoli, strumenti di sviluppo potenti e costi contenuti.

Purtroppo però riuscire a farlo capire al cliente finale è quasi impossibile. Pensano che usando un grande nome di avere miglior affidabilità e un'assistenza certa anche in Sudan o in Sierra Leone

[walterword]

non c'e' bisogno di andare cosi lontano , ho messo in servizio anche qualche impianto in italia .

Quelli di sierra leone meritano di più a confronto .

Il problema principale sono gli imprenditori italiani .

Ogni avaria che capita mandano la telefonata all'ufficio elettrico ..."li dal plc si riesce a capire meglio"

Uffici di progettazione dove nessuno , a parte il meccanico -collaudatore ed i programmatori sanno come funzionano e cosa fanno le loro macchine .

I tedeschi ed altri se vuoi la macchina te la pigli com'e' fatta .

Prova ad andare da un concessionario per acquistare un auto e volere le gomme di un'altra auto , o i sedili del trattore o altre puttanate .

Ti cacciano fuori a calci nel sedere , perche comunque pur volendo soddisfarti e guadagnare , farebbero una boiata .

Noi invece siamo sempre li , tutti che mettono il becco e quando c'e' da risolvere non sanno nulla , anzi indicano col dito medio i programmatori .

E' questione di cultura e serieta .

Non andremo mai da nessuna parte cosi

Mi sto facendo le ferie qua a casa con la mia cucciola pastore tedesco e qualche lavoro , tempo permettendo

ciao

walter

[batta]

Realizzare in SCL l'equivalente di un blocchetto di gestione valvola di un DSC occupa un paio d'ore e in totale saranno un centinaio di righe. Lo stesso realizzato in AWL può essere fatto solo a livello amatoriale, dove il tempo impegato non costa nulla, per non parlare poi dei tempi di debugging..

Su questo non sono d'accordo.

E' sicuramente vero per chi non ha dimestichezza con l'awl, non certo per chi l'awl lo mangia a colazione.

Io scrivo quasi tutto in awl perché mi fa risparmiare tempo!

Comunque mi pare siamo andati decisamente fuori tema e, tanto per cambiare, giù a criticare Siemens, che oramai è lo sport più seguito, come il calcio.

Qualche produttore che propone cose diverse c'è (tipo, appunto, Beckhoff), ma tutti gli altri sono sullo stesso piano di Siemens. Ma criticare solo Siemens sembra sia più di moda.

A parte questo, spesso si devono fare anche altre considerazioni. Con Beckhoff per esempio, è capitato di avere problemi con le licenze, e di dover acquistare una nuova licenza per sostituire un pc guasto

Eppure si è guastato il pc, non la licenza!!!

Ci sono poi altri sistemi, basati su linguaggi compilati, che offrono prestazioni di tutto rispetto. Peccato che (fortunatamente non per tutti) se si modifica una virgola si sia costretti alla ricompilazione totale e all'arresto dell'impianto.

Su alcuni impianti questo non è un problema, mentre su altri è assolutamente improponibile.

Modificato: 12 agosto 2010 da batta

[Livio Orsini]

Comunque mi pare siamo andati decisamente fuori tema e, tanto per cambiare, giù a criticare Siemens, che oramai è lo sport più seguito, come il calcio.

E' vero la discussione è oramai passata ad un altro argomento.

E' normale per chi è un punto di riferimento nel mercato. In Europa, e ancora di più in Italia, Siemens è praticamente "il PLC"; quindi è logico che sia anche il punto di riferimento per le critiche. Però se leggi bene, le critiche sono piuttosto generalizzate e rivolte anche ai maggiori costruttori di PLC.

Modificato: 13 agosto 2010 da Livio Orsini

[walterword]

x Batta : io a colazione mangiavo un tipo di biscotti da piccolo.

Poi per tanti anni solo caffe' .

In germania mangiavo speck e salmone affumicato e in india yogurt oppure omelette .

Stamattina due wafers con caffelatte e una piizzettina come spuntino .

Poi sarà anche abitudine , ma sta di fatto che scrivere tutto in awl non e' il massimo della vita , forse lo e' per te , ma non vorrei mai essere un qualcuno che per necessità o intervento debba mettere le mani su un codice interamente scritto in awl .

Io lo uso per compattare il codice , per esempio per generare un bit di condizioni di avvio ciclo automatico.

Mettere tanti contatti in OR o AND in ladder mi risulta fastidioso e allora lo faccio in awl .

In awl richiamo i blocchi FC o Fb per gestire drives, encoder , camme software e soglie .Cose che stanno li e che non devo piu toccare e cose che nel blocco seguente , se simile al primo copio ed incollo e tramite trova/sostituisci vado a sostituire il DB di appoggio .Per le logiche serie parallelo , serie si trovan tutti male .

Cosa di piu facile che trovarsi un bel ramo in ladder e rendere piacevole per i propri occhi una logica ?

Scusa se mi permetto , io critico siemens , ne ho tutti i diritti ed i doveri .E' una forma automatica visto che si programma quasi esclusivamente solo quello.

Ma da buon programmatore so anche apprezzare i pregi .

Per esempio una cosa che mi piace di step 7 sono i DB che permettono di essere strutturati veramente ad alto livello.Non uso merker tranne che per il byte di clock , obbligatorio .

Uso tutti DB con FC .A partire da FC100 - DB100 inizio la descrizione delle macchine che compongono l'impianto .

E cosi , ad ogni impianto nuovo , prendo il layout , copio ed incollo le macchine gia fatte e le modifico nei suoi interblocchi , piuttosto che passi automatici .

Ogni FC di macchina gestisce le copie sul db dei suoi ingressi , genera i suoi allarmi tawati per copiarli pari pari nella lista allarmi , le sue segnalazioni , le logiche di comando manuale , automatico , semiautomatico , shutdown e reset .

Dopo quasi 3 anni di sacrifici e lavoro sono riuscito a raggiungere un buon livello , smantellando il lavoro fatto da incapaci fanatici di awl e puntatori .puntatori ovunque , non vedevi nemmeno un ingresso o un'uscita .

FB annidati in FB con super multiistanze .Plc scan time =80 ms .

Per non parlare del fatto che poi se scarichi dal plc ti vedi tutto STAT nei db e che per risalire ad unt rip del inverter devi fonderti il cervello per mezza giornata col dubbio di non essere sicuro dell'intervento .

Libri e libri della SITRAN vedevo sulle scrivanie .

C'e' solo un problema coi DB ..... l'intenzione e' buona ma purtroppo il fatto di lavorare sempre con gli indirizzi assoluti causa dei problemi se sbadatamente togli un bit o aggiungi una word al posto di un real .

Per ripulire o aggiungere cose nuove si perde troppo tempo .

Problema che in codesys non esiste perche on esiste il senso di valore assoluto .

Il compilatore compila e non interessa al programmatore sapere dove sia allocata la variabile, anche perche poi la variabili assoluta e' a sua volta un #define che prende dalla ram .

Cosi come le istruzioni awl , sono delle macro .

Nei micro , e anche nel S7200 , le istruzioni occupavano una riga di codice , con parametro 1 , parametro 2 e registro dove mettere il risultato .

Solo siemens ha il concetto di accumulatori ....Load , load , calcolo , transfer

E' ora di aggiornarsi , dopotutto con quello che si spende in denaro e neuroni .

dimenticavo ....il ladder di step 7 lo adoro .Veloce , libero e dinamico .Peccato che non si possano fare operazioni a byte

e peccato che si debba stare attenti alle local assegnate , anche se non le uso mai .

Si perche il ladder , a fine ramo assegna una local prima , e questa viene passata al blocco richiamato .

Se per sbaglio si assegna una local senza vedere , in awl , le local assegnate si rischia un bel macello

Modificato: 13 agosto 2010 da walterword

[flavia]

Batta

Su questo non sono d'accordo.

E' sicuramente vero per chi non ha dimestichezza con l'awl, non certo per chi l'awl lo mangia a colazione.

Io scrivo quasi tutto in awl perché mi fa risparmiare tempo!

Non dubito nemmeno io che chi sia esperto di AWL impieghi un tempo accettabile, ma credo che sia fuori dubbio che lo sforzo di scrivere in codice macchina piuttosto che in codice ad alto livello o addirittura tirare righe col mouse tra un blocchetto ed un altro sia più impegnativo e con maggiore possibilità di errore..

D'altra parte, per quelli come me che fanno oggi una configurazione con dentro un siemens, ieri una con dentro un Hima, domani una con un Honeywell e il giorno dopo una con un Eurotherm, non è nemmeno lontanamente accettabile che per ogni istruzione si debbano mettere a guardare sul manuale ogni istruzione

Sarebbe bello essere esperti di tutto, ma nel mondo reale bisogna sapersi arrangiare

E dato che il tempo di apprendimento costa (così mi dicono), torniamo alla grande a quello che diceva Livio: un bel compilatore C per tutti

Modificato: 13 agosto 2010 da flavia