Actions mancanti in sysmac studio?

[Marco Mondin]

Buongiorno, mi hanno commissionato un lavoretto con sysmac studio.
Premetto che da una prima analisi ho potuto notare che hanno banalizzato la gestione del motion, e questo può essere un bel punto a favore, anche grazie all'uso del plcOpen.
Sto però riscontrando una lacuna.

Non trovo un modo per creare ACTIONs in ST.
Purtroppo gli FB plcOpen non si possono usare negli FB normali, questo è un problema serio!
Non potendo usare FB e ACTIONs, mi viene fuori un porting di un applicativo in cui in un singolo file mi troverei quasi 9000 righe di codice! Questo lo renderebbe alquanto illeggibile.
Ho cercato nella documentazione, ma non trovo nulla! Veramente non hanno implementato le ACTIONS???

Non si possono nemmeno usare gli indirizzi!!! AAAARRRRGGGHHH!!!!

[Ctec]

Per quanto ne so, le Actions  sono implementate in SFC. O intendi la chiamata di una Action di una istanza di FB in un altro PUO? Sinceramente non le ho mai usate neppure in quel poco di CodeSys che ho fatto, per cui non ne sento la mancanza.

Invece per gli FB plcOpen eccome se li puoi usare entro un tuo FB normale. Io lo faccio e funziona.

La frase sugli indirizzi non l'ho capita, invece. Che cosa vuoi usare di indirizzi? Non puoi usare una variabile assegnata?

[Marco Mondin]

Innanzitutto grazie per la celere risposta.

 

Non parlo di SFC, se non sono costretto con fucile puntato sulla schiena evito SFC e LADDER come la peste! Sono troppo limitativi per troppe cose soprattutto se si fa pesante uso di macchine a stati. Orami mi sono creato uno standard derivato dall'OMAC e da un po' di anni lo sto affinando.

 

Intendo le ACTION ST dell'IEC standard...
Sono come le subroutine del BASIC, le MACRO INLINE del C, le sub di alcuni LADDER, le subroutine dell assemby etc....
Permettono di scrivere codice ST molto più leggibile.
A differenze di un FB condivide tutte le variabili con il programma di cui fanno parte. Quindi le variabili locali di un programma vengono viste anche dalla sua action!
Alla fine è come se fossero pezzi di codice del programma stesso portati fuori dal programma.
Rendono tutto molto più leggibile. Soprattutto per chi sviluppa tutto in ST facendo pesante uso di macchine a stati.

 

Per carità posso simularle con delle FB, ma le FB non sarebbero fatte per fare quello e di loro non dovrebbero accedere a variabili locali del programma e globali per regole di privacy e di buon senso!

Una FB può fare finta di essere una action e non una FB, ma le variabili usate devono essere globali, e sinceramente è antipatico instanziare 500 variabili globali ed una sfilza di 150-200 FB tutti ammucchiate nelle Function Blocks sull'editor!

Ci girerò intorno con le strutture annidiate, ma purtroppo questo viola la privacy, permettendo ad altri di toccare oggetti che non dovrebbero toccare.
Per evitarlo sarebbe stato comodo avere i due operatori ADR ed ACCESS con le relative variabili reference che trovo in altri ST, ma non ci sono! Permettono di mantenere la privacy passando indirizzi!

 

Ho anche visto che le FB plcOpen possono essere annidiate in altre FB, stavo facendo un altro errore.
Purtroppo da warning in compilazione, ed io odio gli applicativi che in compilazione danno warning!

[Ctec]

Capisco lo SFC che non piace neppure a me, ma il ladder è richiesto da molti clienti, perché altrimenti non capiscono un tubo, e con i nuovi che permettono parti in inline ST non è male.

Per quello che vuoi fare, penso ti basti usare le Funzioni. Sono esattamente come delle macro, le uso spesso anche in Ladder per parti ripetitive, per renderle più leggibili (spesso le faccio in ST e poi le metto in un chiamante Ladder). Non hanno bisogno di istanze, ovviamente sono espanse (come le macro del C) per cui occupano più posto se chiamate più volte, ma non richiedono appunto variabili di istanza. Possono accedere anche alle globali (variabili esterne) oltre a quelle passate in chiamata. Hanno le loro interne che non sono visibili dall'esterno.

 

Ora ho capito cosa intendo per indirizzi. Pensavo parlassi degli accessi fisici agli I/O del PLC... Invece intendi l'indirizzo come per i puntatori (indirizzo memoria fisica del processore).

No, le ADR non essendo una istruzione standard IEC, non c'è. L'ho trovata solo in CodeSYS.

A mia conoscenza non è possibile ricavare un indirizzo interno, e non si può fare uso di puntatori (limite che non c'era nel vecchio sistema CX della Omron) né ci sono registri indice per operazioni simili. E' una mancanza che ho già segnalato a Omron, ma pare non ci sia interesse.

 

[Marco Mondin]

Le ACTION le ho viste in CodeSYS con cui ci sta lavorando ora il mio socio (Io sto lavorando su un kernel linux RT per avere un runtime su ARM con latenze massime sotto i 40uS per poi poter sviluppare facendo pesante uso della shared memory di Codesys, vorrei usarlo con dispositivi come il netPI Hilsher o il CX9020 Beckoff), con B&R e con Twincat (Che è un CodeSYS modificato, implementa librerie di Beckhoff e ne modifica l'ambiente di sviluppo in alcune parti).
Ci avevo pensato alle function, ma devo svolgere alcuni compiti in più cicli di scansione. Soprattutto quando devo lavorare parecchio con gli SDO di alcune apparecchiature (Non mi piace avere PDO troppo lunghi, i PDO li uso quasi solo per i compiti deterministici).

Gli ADR e ACCESS effettivamente li ho trovati per ora su B&R, ma c'è da dire che lo standard IEC61131-3 utilizza l'operatore & per i puntatori. Appena torno a casa provo! Mi risolverebbe un enorme problema! 

 

P.S. Oggi si inizia a trovare anche chi vuole solo ST che rispeti l'IEC in tutto! Ti potrei fare l'esempio di due grosse realtà per cui lavoriamo io ed il mio socio.

[Marco Mondin]

Non posso più editare... 
Ho testato. Effettivamente non c'è modo di usare i puntatori, risultano comunque molto comodi i namespaces per separare per bene le cose.