Limiti del sysmac studio.

[Marco Mondin]

Visto che tempo fa notai la mancanza di alcune cose su OMRON e recentemente altri hanno fatto notare altre lacune, ho deciso di aprire questa discussione in modo che possa essere raccolta da eventuale personale OMRON in lettura una critica costruttiva.

Ci tengo a fare tale critica in modo costruttivo, in quanto ho notato che il sysmac è di suo un ambiente di sviluppo reattivo e con ottime potenzialità, ma al contempo con limiti molto penalizzanti se confrontato con prodotti simili, per altro più economici, sul tipo di mercato che mi sembra vogliano andare a toccare con tali prodotti.

- Mancanza di puntatori.
Ci sono il ToAryByte e AryByteTo che possono fare il lavoro sporco del memcpy, ma non è che siano il massimo.

Io uso i puntatori per esempio quando voglio rendere una struttura contenuta in una struttura non ritentiva, ritentiva.

- Impossibilità di mappare segnali di campo su variabili appartenenti a strutture.
Questa è una lacuna enorme, che crea un disordine ed una confusione mostruosa in un applicativo!!!

Fare mappatura sw porta via inutili risorse di sistema!!!

 

- Impossibilità di avere doppie mappature di ingressi! Indispensabile quando si una uno stile molto object oriented e si spinge molto sul concetto di compartimentazione dei moduli software e della privacy.

Per me è un problema molto grave in quanto rende molto meno riciclabile il mio codice, facendomi perdere un sacco di tempo a fare due volte le stesse cose! Concetto che odio in quanto ogni minuto perso è un euro perso!

 

- Non visibilità delle variabili mappate sul campo in task che non siano sincronizzati con il campo stesso!
Assurdo, in quanto l'uso di task a cadenze differite è fondamentale per ottimizzare le risorse! Chi se ne frega di controllare il pulsante di start ogni ms quando controllarlo ogni 20ms non causerebbe nessun effetto collaterale!!!

 

- Mancanza dei packages!
Se si creano applicativi molto frammentati e modulari, orientati al riciclo massiccio del codice è una lacuna enorme!
Orientarsi in 150 FB tutte nello stesso calderone è tedioso! Fa perdere una quantità di tempo spropositata!

 

- Non possibilità di usare costanti per definire dimensioni di array.
Per esempio io uso molto le costanti quando rendo staticamente parametrizzabili alcuni moduli riciclabili, cambiando il valore della costante quando importo un modulo riadatto tutti gli array che dipendono da tale costante e tutti i cicli iterativi in un solo colpo.

- Simulatore che non permette di usare socket UDP e TCP, rendendolo inutile la simulazione quando la macchina deve essere per esempio controllata da un applicativo su PC.

- Mancanza di ACTIONS ST IEC (Subroutine), o si creano sorgenti ST enormi o si usano massicciamente gli FB, ma in entrambi i casi ci sono dei grossi contro.
Nel primo il sorgente diventa immotivatamente grosso ed illeggibile, l'ordine e la pulizia vengono pesantemente pregiudicati.
Nel secondo diventa impossibile effettuare debug in modo serio in quanto le locali degli FB non sono facili da monitorare.

- Impossibilità di fare funzionare i break point fuori dal simulatore! Se uno sviluppa una applicazione di motion si da per scontato che sappia i rischi che si corrono con tale strumento, fare debug sviluppando macchine a stati complesse ed articolate senza poterli usare è molto complesso!

 

- Nessuna possibilità di scelta sul luogo dove salvare gli applicativi! Cosa che rende abominevole la gestione delle cose con un certo ordine! Fa venir voglia di usare una VM per ogni progetto!!!

Detto questo trovo il sysmac, se installato su un buon PC con SSD un ambiente di sviluppo tra i più reattivi con un buon completamento automatico (anche se con piccolissimi bug e lacune).

Se un giorno risolvessero tali lacune, diventerebbe un prodotto molto aggressivo nel mercato dei PLC/CN dedicati al motion, oggi per progetti grossi se non si vuole stare a perdere tempo riscrivendo tantissimo codice ad ogni nuovo lavoro è un po' problematico.
Si trova secondo me in un limbo un po' critico cercando di abbracciare due mentalità di sviluppo software per automazione che purtroppo cozzano un po' troppo!

Come dicevo ho aperto questa discussione come critica costruttiva, in quanto ci vedo del buono e delle ottime possibilità, ma i limiti imposti, almeno per me oggi pesano troppo.

Modificato: 21 dicembre 2018 da Marco Mondin

[lelos]

ciao

mi chiedo come abbia fatto fino ad ora a programmare senza tutto questo.

Ho sempre fatto tutto senza problemi anche su macchinari "grossi" inteso come 500 i/o e 20 assi con visione e scada.

ok come critica costruttiva ,ma da come messa sembra che senza tutto quello che gli manca non si possa  programmare.

 

 

[Marco Mondin]

Noooo... Anzi... Rispetto ad altri ambienti mi trovo pure meglio, ma se faccio un conto di ore sviluppo per lo stesso applicativo da altri ambienti a questo c'è molta differenza a livello di ore a parità di progetto!
Per farti un esempio se su un progetto su uno di quelli a cui sono più abituato ci metto 300 ore su questo ce ne metto 700 perché molte cose che solitamente non riscriverei le devo riscrivere, senza fare veloci copia/incolla con cambio di due tre parametri da altri miei applicativi.

Tieni comunque conto che se non obbligato i miei applicativi non hanno una singola parte in ladder, le lacune di cui ti parlo derivano da una necessità di sviluppo rapido in ST e lì che ci sono più limiti, ma solo se si vuole progettare con una filosofia molto più informatica che di automazione pura. 

 

Modificato: 21 dicembre 2018 da Marco Mondin

[dott.cicala]

Pobabilmente non hai il vincolo a capitolato di non usare certe acrobazie, non ti viene imposto dall'altro come scrivere il codice, quale plc usare e non ti trovi a dover formare il personale che svolgerà la manutenzione per il resto della vita dell'impianto - che non sono 2-4 anni come quella di un pc  ma almeno 15 o 20 -

Personale che vorrà magari introdurre qualche piccola modifica e che certamente non ha lo skill di ingegnere informatico e anche se lo avesse, non è lo stesso soggetto che ha scritto il codice.

La comprensione dell'opera altrui non è così immediata, specialmente quando chi l'ha scritta è un informatico puro con il vizio di non sprecarsi nei commenti.

E' probabile che dopo qualche anno, anche ci ha partorito quel codice così scritto,  non riuscirà immediatamente a ricordare perchè ha adottao certe soluzioni.

L'impianto magari sarà fermo, l'intervento sarà a consuntivo, il fermo impianto produrrà perdite consistenti per ogni minuto di mancata produzione.

 

Se non ti rivedi o non hai mai vissuto le situazioni che ti ho descritto e ce ne sarebbero molte altre, nemesi di ognuno di noi che svolge questa professione,

che fortuna, puoi adottare qualsiasi soluzione ti passa per la mente nei limiti che come in questo caso hai evidenziato e che possono anche essere noiosi ed irritanti, altrimenti... l'approccio puramente informatico non è una grandissima idea....ma questa è una mia modestissima opinione.

 

[max.bocca]

Quando compravami le macchine facevamo presente ai costruttori di aver la stampa del programma con pre requisito che possibilmente dove essere scritto in kop e anche gli  schemi dovevano essere molto dettagliati  perché in caso di interventi doveva essere il più semplice possibile verificare hw e sw. Chi proponeva programmi scritti in c o altri linguaggi non veniva presa in considerazione come pure hw di marche sconosciute. 

[leleviola]

Concordo con max.bocca infatti la problematica è sempre quella, la manutenzione impianto che deve essere semplice e immediata, spesso non se ne tiene conto ma è fondamentale su certi tipi di macchine. Che dire ST facilita la programmazione tra un marchio e un altro ma non è certo di aiuto a chi fa manutenzione e non è un informatico

[Marco Mondin]

Beh... È diciamo che la verità sta nel mezzo.
Stiamo andando un po' OT, ma neanche troppo, in quanto grazie a queste discussioni si comprende perché a me pesano certe lacune.
 

Diciamo che in giro sia come "non informatici" che come "informatici", si vede di tutto e una percentuale purtroppo grossa è molto improvvisata e fa cose abbastanza assurde, ma questo è un parere personale. Al cliente finale sovente basta che la macchina/linea funzioni e non guardano mai dentro gli applicativi.

 

Io sono di estrazione fortemente informatica, con passioni per automazione, fisica, matematica, elettronica coltivate fin da bambino.

 

Ci sono due distinzioni:
- In ST

Il software non basta che funzioni, deve essere scritto con stile e metodo, se la fase di progettazione è seguita bene ed occupa l'80% del tempo della realizzazione come dovrebbe essere (80% progetto 5% scrittura 15% debug), se si seguono rigide regole di ordine, nomenclature, organizzazione dati, pulizia, documentazione, commenti soprattutto in parti criptiche (che andrebbero comunque evitate), e si evitano come la peste tutti i cattivi vizzi di programmazione, il sorgente diventa autoparlante. Un buon softwarista di estrazione informatica, o un ingegnere elettronico/informatico degno di tale nome non avrà nessun problema a leggere, capire e modificare il codice.
Premetto che effettivamente io ed il mio socio lavoriamo prevalentemente per costruttori di macchine che non vogliono che il software venga toccato da nessuno che non siamo noi!
Se un applicativo è sufficientemente parametrizzabile ed offre una buona intrefaccia di scambio informazioni per eventuali up e down stream è probabile che non necessiti proprio di interventi di alcun genere in tutta la sua vita!
Per me è fondamentale che si possa diagnosticare tutto senza collegare l'ambiente di sviluppo! In caso contrario lo reputo un fallimento personale!
Se in un applicativo ho 500 timers, avrò 500 parametri nascosti in HMI (o sovente un sw di configurazione dedicato ai tecnici non softwaristi) per i settaggi di tali parametri.
Per esempio parametrizzo tutti i timer di debounce e di filtraggio. È anche fondamentale che tutto il campo sia diagnosticabile da HMI.

 

Se un singolo sorgente supera le 200 linee di codice e non è una parte di calcolo matematico complesso, mi chiedo sempre cosa ho sbagliato in fase di analisi/progetto.
Un progetto deve avere un gran numero di sorgenti specializzati e piccoli, di facile ricerca e rilettura!
Se su un modulo (oggetto) accedo direttamente a variabili che non sono di sua proprietà e non fanno parte dell'interfaccia astratta di interscambio interprocesso sto facendo una schifezza che rompe la riciclabilità. (Non sono dio e di schifezze a volte ne faccio anche io, ma cerco di evitarle).

 

Se uno improvvisa e non ha una formazione adeguata fa schifezze! Che diventano illeggibili al più ed anche al softwarista stesso a distanza di anni! Questa è un'ovvietà dell'informatica, ma sembra che invece che come assioma troppe persone lo considerino una cosa facoltativa.
Qualcuno mi potrebbe contestare che scrivere software così porti a sprecare troppo tempo! È vero alla prima applicazione, quasi alla seconda, ma man mano che la libreria di moduli riutilizzabili si amplia si raggiunge un punto in cui i tempi quasi si equivalgono, con la differenza che si ottengono due risultati completamente diversi.

 

Pensando e progettando in object oriented (Un oggetto deve avere proprietà privare ed un interfaccia astratta di comunicazione) anche in ST si può usare il concetto di atomizzazione degli oggetti e la riciclabilità del codice non può che trarne vantaggio.

-In Ladder
Troppe cose sono tediose da gestire, scrivere tanto codice è noioso e si finisce quasi sempre per fare poco più del minimo indispensabile per fare funzionare una macchina. Anche un niubbo informatico riesce a volte a portare a casa il risultato, sovente facendo cose che fanno drizzare i capelli ai nerd, non tanto a livello funzionale, dove magari le cose vanno anche bene, quanto a stile e pulizia. C'è chi fa ottimi lavori anche in ladder e ne ho visti tanti, ma purtroppo non sono la maggioranza.
Effettivamente per un non informatico è più semplice intuire dove qualcosa va storto, ma sono dell'idea che se qualcosa va storto il softwarista deve sempre essere disponibile.

L'uso di risorse fa impressione! Per fare un esempio un applicativo scritto in stile Ladder su una CPU occupava il 70% delle risorse CPU con una ciclica a 2ms ed una a 20ms. Rscritto da me ed il mio socio su una CPU 3 volte meno prestazionale siamo arrivati al 4% con una ciclica a 1mS ed una a 10mS!!! Questo vuol dire usare una CPU che costa meno della metà per fare lo stesso lavoro (che poi è risultato anche più prestazionale).

Detto questo le lacune che ho fatto notale, non pongono grossi limiti allo sviluppo di applicazioni, in quanto ci sto comunque convivendo, ma pongono grossi limiti allo stile, pulizia, riciclabilità e leggibilità per per me sono dei dogmi, quando costretto ci rinuncio, ma mi pesa! 
Altro limite che trovo un po' assurdo, ma è sicuramente una scelta commerciale è che in un prodotto così recente pongano limiti così stretti alla quantità di ram e codice disponibili per un applicativo! Mi trovo una CPU scarica a tempo ciclo e che non mi da abbastanza RAM o spazio per gli applicativi, ma qua non dico nulla in quanto a livello commerciale ogni CPU ha il suo target e non credo faccia piacere ai produttori che si usino sempre i modelli più piccoli!
 

Modificato: 22 dicembre 2018 da Marco Mondin

[leleviola]

2 ore fa, Marco Mondin scrisse:

 ogni CPU ha il suo target e non credo faccia piacere ai produttori che si usino sempre i modelli più piccoli!

 

In quest'ultima frase hai centrato il nocciolo della questione, proprio una ragione commerciale, anche a livello hardware le nuove CPU compatte Omron non hanno la possibilità di avere a bordo ingressi veloci, sei obbligato a mettere costose espansioni. Ma allora è una CPU compatta come vogliono o come vogliono spacciarti? Capisci che dietro ci sono ragioni commerciali o che il target cui vogliono raggiungere è altro. Questo esula tal tema del tuo post ma forse fa un po' capire perchè si arriva a quello che dici riguardo al software. Secondo me vogliono rompere le scatole ad altri e abbondonare un certo tipo di mercato, ma non so se da i suoi frutti, molti li stanno abbondonando

[Operational Amplifier]

Condivido in pieno la filosofia di Marco Mondin...quando certi clienti iniziano con la solita lagna che chiunque deve metterci mano, me ne vado all'istante...👎.

Colgo l'occasione per augurare a tutti Buone Feste...!!! 🎅 

[Marco Mondin]

1 ora fa, leleviola scrisse:

... Questo esula tal tema del tuo post ma forse fa un po' capire perchè si arriva a quello che dici riguardo al software. Secondo me vogliono rompere le scatole ad altri e abbondonare un certo tipo di mercato, ma non so se da i suoi frutti, molti li stanno abbondonando

Infatti... Per chi sviluppa in modo tradizionale ci sono sufficienti features, forse anche troppe e che potrebbero confondere qualcuno.
Probabilmente ho travisato io, ma sembra che abbiano cercato di rompere le scatole a qualcuno di cui non faccio nomi, ma almeno tre sono abbastanza conosciuti ed uno di loro ha pure subito una grossa acquisizione nel recente periodo.
Se questo è l'obbiettivo sono sulla buona strada, in quanto l'ambiente di sviluppo sotto certi punti di vista è migliore dei concorrenti, ma i limiti sono troppo grossi per infastidirli veramente.
Certo che se avessi tutte le feature di uno dei 3 semi big concorrenti con un ambiente così fluido... Beh... La mia scelta sarebbe senza dubbio questa in molte applicazioni.
Oltre al fatto che proporre OMRON ai clienti è più semplice ed indolore.
Da quest'ultima considerazione è scaturita la mia critica costruttiva. Hanno fatto 28 su 30! Con non troppo sforzo potrebbero fare 31...

Se non avessi apprezzato il lavoro fatto non mi sarei scomodato a perdere il tempo per aprire questa discussione.