Delucidazione su Ciclo Plc

[step-80]

Buonasera a tutti. Mi scuso anticipatamente se l'argomento è banale ma vorrei una conferma da parte vostra.

 

Solitamente nei miei programmi creo cicli di Homing assi, Posizionamenti ecc usando la tecnica batch (setto/resetto dei bit che definiscono lo stato in cui mi trovo e,a seconda dello stato, eseguo determinate operazioni).

Un ciclo di posizionamento tipico potrebbe essere: da start ---> carico valori di posizionamento 1---->attendo asse partito----->attendo asse arrivato----->carico valori posizionamento 2 --->ecc ecc.

 

A seconda del linguaggio che uso(ladder o testo strutturato, a seconda di come mi gira e della complessità del progetto) uso, per l'appunto, la tecnica batch oppure il costrutto CASE. 

Il mio dubbio verte su queste 2 scelte: credo che a livello di gestione di risorse il linguaggio strutturato ne occupi molte di piu per eseguire le stesse operazioni...sbaglio?

Al di la di questo, per la parte ladder avrò ,se ogni bit scandisce il passo attivo, il comando di start che alza pippo.x0,con pippo.x0 alto carico i valori di posizionamento 1 , alzo pippo.x1 e abbasso pippo.x0; con pippo.x1 faccio partire il posizionamento ecc ecc.

In questo modo mi aspetto che il caricamento dei valori di posizionamento e lo start posizionamento vengano eseguiti durante la stessa scansione giusto?Cioè mi aspetto che se nella riga 1 setto pippo.xo ,nella riga 2 vengano eseguite le istruzioni se pippo.x0=true. 

Col CASE invece , se Step=0 e premo start, Carico 1 in Step------>con Step=1 carico valori di posizionamento 1 e carico 2 in Step. Solo che a questo punto il programma salta all'istruzione END CASE quindi le istruzioni di Step=2 vengono elaborate la scansione successiva. E' esatto quello che dico?

 

Mi scuso se ho fatto confusione, spero si capisca il concetto ....

 

Ringrazio anticipatamente

Matteo

[drugo66]

Ciao Step,

credo che tutti i linguaggi vengano poi "tradotti" in codice macchina, a prescindere che si tratti di ladder o simil pascal o quello che vuoi; ci vorrebbero delle tabelle con indicati i costi in termini di tempo delle singole istruzioni; un volta le avevo viste, ma, al momento non ricordo per quale PLC; dirti che il linguaggio più ad alto livello "costa" di più alla CPU onestamente non lo so; posso dirti che, personalmente, i linguaggi di quel tipo preferisco usarli solo per manipolare i dati, per le loro trasmissioni / ricezioni, ma non per il ciclo, dove preferisco sempre il ladder.

Con il discorso del costrutto Case, invece, penso che tu abbia ragione: una volta eseguito un passo e se il passo successivo è nello stesso costrutto, quest'ultimo verrà per forza eseguito alla scansione successiva; con il ladder, invece, è facile che siano eseguiti più passi nella stessa scansione.

[step-80]

Ciao Drugo, grazie per la risposta.

 

21 minuti fa, drugo66 scrisse:

Con il discorso del costrutto Case, invece, penso che tu abbia ragione: una volta eseguito un passo e se il passo successivo è nello stesso costrutto, quest'ultimo verrà per forza eseguito alla scansione successiva; con il ladder, invece, è facile che siano eseguiti più passi nella stessa scansione.

 

da quello che capisco io leggendo i vari manuali di Testo Strutturato (presente ormai sulla stragrande maggioranza degli ambienti di sviluppo) quando il CASE ha elaborato le istruzioni corrispondenti al valore corrente della variabile da monitorare, salta all'istruzione 'END CASE'. Sul plc che uso (Mitsubishi) esiste una funzione che, qualunque sia il linguaggio usato, ti mostra tutto ciò che hai scritto in Lista Istruzioni (IL) . 'Traducendo' un banale CASE si nota che se il confronto con il primo(scusate la ripetizione) Case ,ad esempio 5, risulta falso, esegue un salto (JMP) alla parte di programma dove il CASE termina, e cosi via per tutti gli altri confronti. Se risulta invece Vero, esegue quello che c'è da eseguire ma poi salta ugualmente alla stessa riga finale. 

In altre occasioni invece e con altri ambienti di sviluppo, ho visto che facoltativamente si poteva aggiungere l'istruzione 'BREAK' ,che saltava a fine CASE, facendomi pensare che senza Break invece elaborasse di seguito tutti i confronti...anche se dopo testando, mi è parso che non cambiasse nulla usare il Break oppure no. 

 

Piccola riflessione personale: Sono quasi 6 anni che 'gioco' con i plc(non dico lavoro per rispetto ai programmatori veri)...e non c'è una volta dico UNA che,terminato un programma, non mi venga voglia di ricominciarlo daccapo.

Ho sempre l'impressione di gestire le cose in modo confusionario..anche se passo settimane ad analizzare il ciclo macchina, diagrammi di flusso come se piovesse..poi arrivo a stendere il programma e,anche se parto in modo ordinato, poi finisco sempre per aggiungere parti di programma per far funzionare il tutto, magari sul campo, mentre la produzione è ferma per colpa mia e quindi è difficile rimanere lucidi. Aggiungo parti con la convinzione di riprendere poi in mano tutto con calma e sistemare ma nel frattempo la macchina va e,almeno per me, scatta il terrore di fare modifiche per cui le cose peggiorino e quindi...rimane cosi. Spero di trovare un'anima pia che mi consoli, se invece mi dite che al primo colpo vi riesce tutto..Beh vi invidio da morire

[drugo66]

Assolutamente no, è difficile che mi riesca tutto al primo colpo ... quello che faccio spesso è di migliorare comunque almeno un pezzo per volta nella speranza che poi funzioni tutto ...

[step-80]

10 ore fa, drugo66 scrisse:

Assolutamente no, è difficile che mi riesca tutto al primo colpo ... quello che faccio spesso è di migliorare comunque almeno un pezzo per volta nella speranza che poi funzioni tutto ...

 

Ah meno male...è che nella mia testa bacata ero convinto che dopo qualche anno avrei bevuto programmi come niente fosse, invece non è assolutamente cosi. 

Sarà perchè non faccio mai 2 cose nello stesso modo ma cerco sempre di cambiare /migliorare se possibile,e questo porta inevitabilmente a nuovi problemi che poi vanno capiti e risolti.

 

Grazie per il supporto!

[leleviola]

Anch'io come drugo66 preferisco usare linguaggi tipo il ladder per il normale ciclo, la programmazione in strutturato la lascio agli eventuali calcoli complicati che posso avere, anch'io lavoro con Mitsubishi e pensa che tutt'ora continuo a preferire la vecchia programmazione con BufferMemory per le espansioni dei PLC alla nuova programmazione con le Label tanto per citare qualcosa di Mitsubishi. Quando uno si è fatto le ossa con un linguaggio basilare difficilmente si affida ad altro. Per la programmazione dei cicli macchina dei posizionamenti step-80 ti consiglio di usare per il Mitsubishi l'SFC, ottieni una programmazione a passi in maniera sicura e gestisce le transizioni dei vari passi attivi in maniera ottimale senza avere errori, isola gli Step attivi e ne fa le transizioni in maniera univoca e sicura, con il normale ciclo ladder se non usi le dovute precauzioni nello scorrere del programma puoi incappare in banali errori di esecuzione. Per esempio se usi le istruzioni SET o RESET per le attivazioni dei vari Step attivi, la posizione cronologica di tali istruzioni all'interno del programma è fondamentale per la corretta esecuzione delle stesse per evitare che contemporaneamente all'interno di unico ciclo più volte tali istruzioni vengano eseguite in maniera erronea

[leleviola]

il 23/3/2018 at 19:00 , drugo66 scrisse:

 ci vorrebbero delle tabelle con indicati i costi in termini di tempo delle singole istruzioni; un volta le avevo viste, ma, al momento non ricordo per quale PLC;

Mitsubishi le mette le tabelle con i tempi di esecuzione delle varie istruzioni, spegando in maniera chiara le loro esecuzioni tempistiche, tipo istruzione eseguita o no e se tale istruzione prevede un loop di escuzione

[step-80]

Leleviola da come scrivi sembri un programmatore vecchio stampo,di quelli che plcOpen non lo vogliono vedere nemmeno in foto. Naturalmente lo dico con ammirazione.

Non so se hai mai usato il motion sulla serie Q: come saprai si programma con MtDeveloper che usa esclusivamente sfc come linguaggio. Mi è capitato di realizzare una macchina con parecchi assi sincronizzati e per niente banale: a causa di ciò ho dovuto per forza sbattere la testa con sfc che sino ad allora non mi aveva mai entusiasmato. 

Per farla breve, mi sono trovato talmente bene che adesso Mt lo uso per i diagrammi di flusso...creo un progetto a caso e inserisco i blocchi con solo i commenti dentro. Questa nuova apertura mentale mi ha aiutato non poco con gli altri progetti ed ora non potrei piu tornare indietro. Una volta provato però sfc su gxWorks mi sono accorto che è diverso da quello usato e non c ho capito granchè...non ho capito se le transizioni/operazioni si possono scrivere in altri linguaggi o no per esempio.

 

Dato che abbiamo tirato fuori Mitsubishi, ho avuto una 'brutta' esperienza con la serie L e scheda simple motion: in pratica saltuariamente il ciclo mi si piantava in corrispondenza della parte in attesa del bit "busy" , anche se il posizionamento veniva effettuato. Chiamando l'assistenza siamo arrivati alla conclusione che , essendo la scheda motion piu veloce del plc, per posizionamenti brevi il busy si alzava per un tempo talmente piccolo da non essere 'visto' dalla cpu . 

 

[leleviola]

2 ore fa, step-80 scrisse:

Dato che abbiamo tirato fuori Mitsubishi, ho avuto una 'brutta' esperienza con la serie L e scheda simple motion: in pratica saltuariamente il ciclo mi si piantava in corrispondenza della parte in attesa del bit "busy" , anche se il posizionamento veniva effettuato. Chiamando l'assistenza siamo arrivati alla conclusione che , essendo la scheda motion piu veloce del plc, per posizionamenti brevi il busy si alzava per un tempo talmente piccolo da non essere 'visto' dalla cpu . 

 

Tale situazione capitava anche a me in passato con M8029 di esecuzione passi effettuata con la serie Fx, in pratica non vedevo l'impulsivo di tale merker, sai come ho risolto senza chiamare l'assistenza? E' bastato appoggiare tale merker direttamente a un altro merker generico e verificando l'impulsivo di atle nuovo merker, esempio:M8029=M0 banalmente, problema risolto, non mi sono posto troppo il problema, probabilmente era così anche con la serie L. Purtroppo non ho mai usato la serie L e probabilmente ha i suoi vantaggi ma non è molto reclamizzata dalla casa, ultimamente insieme a un collega siamo passati alla serie iQr, purtroppo ho seguito solo la progettazione ma non la parte software, quello che posso dirti che non mi piace molto lo stile nuovo di programmazione col le Label, preferisco ancora i Buffer Memory vecchio stile, pure i manuali che fanno adesso no mi piacciono molto, troppo dispersivi e poco orientati al problem-solving, troppi discorsi per arrivare al punto. I vecchi manuali descrizione concisa dei vari buffer memory e in un attimo programmavi tutto. Ho fatto con il solo FX revampig notevoli. Certo i nuovi PLC potenza di calcolo e velocità notevoli, l'unica cosa che hanno in più è il controllo di coppia e in velocità che con il vecchio FX3u e la sua espansione in fibra non ha. Programmatore vecchio stile? Mi son fatto le ossa con il GX.Developer e credimi se è durato 15 anni un motivo ci sarà. Ricordo della tua macchina che hai descritto anno scorso, bell'impresa. SFC nei vecchi GX si faceva solo in ladder negli step e pure nelle transizioni, nel nuovo non so, l'ha seguito il mio giovane collega

[batta]

Quote

Sono quasi 6 anni che 'gioco' con i plc(non dico lavoro per rispetto ai programmatori veri)...e non c'è una volta dico UNA che,terminato un programma, non mi venga voglia di ricominciarlo daccapo.

Io lavoro con i PLC da trent'anni, e sono nelle tue stesse condizioni.
Ma questo, secondo me, non è perché sbagliamo approccio, ma perché, probabilmente, siamo dei perfezionisti, quindi non siamo mai completamente soddisfatti di quello che abbiamo fatto, perché ci rendiamo conto che potevamo fare meglio. Ma per fare meglio serve tempo, e questo non c'è mai.  

[step-80]

Batta, come al solito hai centrato la questione. Faccio macchine che funzionano ma il tarlo del "si poteva fare meglio" è sempre in agguato. A me capita spesso di fare il 70% del programma, testarlo, sistemare quello che non va e mettere ad andare l 'impianto perchè i tempi sono sempre stretti e BISOGNA produrre..manca il 30% composto da allarmi , segnalazioni, funzioni di ripristino dopo un black out ecc ecc...tutte cose ritenute spesso inutili finchè tutto va bene, poi quando succede qualcosa ed un robot va a cozzare da qualche parte si punta subito il dito con chi ha fatto il programma ..ma a questo punto della storia io sono già passato ad occuparmi di altro . Non c è mai tempo per fare nulla, nemmeno per fare un minimo di formazione alle persone che dovranno usare la macchina che spesso sino alla settimana prima lavoravano in pizzeria o commessi in negozio di scarpe, quindi gente che non ha nemmeno le basi di un lavoro del genere .

[Livio Orsini]

19 minuti fa, step-80 scrisse:

Faccio macchine che funzionano ma il tarlo del "si poteva fare meglio" è sempre in agguato.

 

Questo capita a tutti i progettisti e non solo ai progettisti.

Dopo che hai fatto un lavoro sai come si poteva farlo meglio; la seconda volta lo fai meglio ed alla fine credi di sapere come farlo ancora meglio.

 

Io ho sempre usato un metodo comune per tutti i Sw che ho sviluppato e sviluppo, indipendentemente dal dispositivo e dal linguaggio usati.

Tendo a crearmi librerire di funzioni che metto a punto sino a quando sono soddisfatto, poi non tocco più la funzione anche se mi viene l'idea di poterla far meglio.

Quando hai una funzione ben ottimizzata e che hai verificato in svariate applicazioni, quindi sai che molto affidabile, non devi più "migliorarla" perchè rischi di peggiorarla, sicuramente se introduci modifiche hai comunque la possibilità di aver introdotto anche errori non immediatamente riscontrabili.

 

 

[step-80]

Spesso faccio lavori che poi guardo con disgusto a distanza di qualche mese...mi chiedo come facciano a funzionare anche se in realtà quello che devono fare lo fanno. Forse è il fatto che sono arrivato al funzionamento dopo una miriade di rattoppi sul campo,e quindi non è un lavoro 'ragionato' in ufficio. Anzi spesso di quello che scrivo in ufficio funziona si e no il 50%. C'è sempre un qualche cosa che non ti aspettavi, una condizione che non avevi contemplato:il peggio è che la maggior parte delle volte certe condizioni si verificano quando meno te lo aspetti anche a distanza di molto tempo.

Per non parlare poi dei misteri 'x-files', quelle cose che risolvi dopo una nottata di imprecazioni ma alla fine non sai bene in che modo sei riuscito a risolvere, spesso si cambiano decine di parametri e alla fine tutto funziona e non si sa mai quale era veramente la causa..magari bastava un riavvio del plc. 

 

Questo per dire(tanto ormai sono ampiamente off-topic) che è un lavoro visto come una stupidata dai non addetti ai lavori ma noi sappiamo benissimo che l'automazione logora, non ti lascia mai in pace, nemmeno nei week end. Il termine 'staccare la spina' comincia a perdere sempre piu senso sino a diventare sconosciuto. Anzi, si prova un remoto senso di colpa a non pensare come risolvere determinati problemi nel week-end...momento nel quale in teoria la mente dovrebbe essere piu rilassata e quindi piu fresca e pronta. 

Il momento in cui la macchina gira e tutti la guardano col sorriso da beota...come se il funzionamento fosse scritto già da qualche parte, gia fatto e noi programmatori dovessimo solo dare lo start. Solo noi sappiamo quanti e quali problemi abbiamo dovuto affrontare o trovare il modo di bypassare e quanto ci è costato in termini mentali. Se è cosi per me che con i plc ci gioco, non oso immaginare chi deve risolvere problemi ben piu grandi dei miei e magari deve rendere conto a persone che spesso sono tutto tranne che gentili e pazienti.

A loro va tutta la mia stima

 

[Livio Orsini]

30 minuti fa, step-80 scrisse:

Anzi, si prova un remoto senso di colpa a non pensare come risolvere determinati problemi nel week-end...momento nel quale in teoria la mente dovrebbe essere piu rilassata e quindi piu fresca e pronta. 

 

Accidenti come ti capisco! Anche sono in pensione da parecchi anni quella sensazione la ricordo ancora. Ricordo che già ricompariva anche negli ultimi giorni di ferie, quaindo per una ventina di giorni riuscivo a "staccare la spina".

33 minuti fa, step-80 scrisse:

e magari deve rendere conto a persone che spesso sono tutto tranne che gentili e pazienti.

 

Questo è il lato peggiore di tutta la faccenda.

[Operational Amplifier]

33 minuti fa, step-80 scrisse:

Questo per dire(tanto ormai sono ampiamente off-topic) che è un lavoro visto come una stupidata dai non addetti ai lavori ma noi sappiamo benissimo che l'automazione logora, non ti lascia mai in pace, nemmeno nei week end. Il termine 'staccare la spina' comincia a perdere sempre piu senso sino a diventare sconosciuto. Anzi, si prova un remoto senso di colpa a non pensare come risolvere determinati problemi nel week-end...momento nel quale in teoria la mente dovrebbe essere piu rilassata e quindi piu fresca e pronta. 

Il momento in cui la macchina gira e tutti la guardano col sorriso da beota...come se il funzionamento fosse scritto già da qualche parte, gia fatto e noi programmatori dovessimo solo dare lo start. Solo noi sappiamo quanti e quali problemi abbiamo dovuto affrontare o trovare il modo di bypassare e quanto ci è costato in termini mentali.

Sono nelle tue stesse condizioni.

[batta]

Quote

Anzi, si prova un remoto senso di colpa a non pensare come risolvere determinati problemi nel week-end...

Questo penso affligga tutti noi programmatori (e non solo). Se c'è qualcosa che non riesci a risolvere, anche se non vuoi, la mente rimane sempre bloccata lì, a cercare la soluzione, anche di domenica, anche quando vai a dormire. Un vecchio proverbio dice che la notte porta consiglio. Ed è vero. Ora, probabilmente a causa dell'età, con una mente che fa più affidamento sull'esperienza che sull'intuizione, mi capita più raramente, ma succede ancora che la soluzione mi si presenti accendendosi come una lampadina al risveglio.
Ho anche imparato che le nottate trascorse a cercare di far partire un impianto non servono. Possono essere l'eccezione, in casi particolari, ma non devono assolutamente diventare una regola. Invece troppo spesso viene considerata una cosa normale. Ma per questo dobbiamo recitare il mea culpa. Fino a quando non impareremo a dire di no, fino a quando non fisseremo dei limiti invalicabili, fino a quando non avremo il coraggio di spegnere il generale e dire: "Ciao a tutti, ci si rivede domani mattina", mandando a quel paese tutti quelli che ti vogliono fermare, la situazione potrà solo peggiorare.
In questo senso, devo dire che sono veramente poche le situazioni nelle quali qualcuno riesce ad impormi di fare nottate. E poi, una volta raggiunto un certo livello di stanchezza fisica e mentale, quelle ore in più passate davanti al pc rischiano non solo di essere poco produttive, ma addirittura dannose. Se c'è un problema di difficile soluzione quando sei lucido, figurati cosa puoi combinare quando hai la mente offuscata da sonno, stanchezza, fame e stress.
 

[Livio Orsini]

30 minuti fa, batta scrisse:

E poi, una volta raggiunto un certo livello di stanchezza fisica e mentale, quelle ore in più passate davanti al pc rischiano non solo di essere poco produttive, ma addirittura dannose.

 

Sicuramente!

Ricordo un episodio accaduto a 3 ex colleghi di una grande azienda.

Durante una messa in marcia di un impianto di laminazione, dopo ptre 18 ore di lavoro ininterrotto, procedendo a delle misure su di un grosso convertitore, uno di loro fece un errore causato dalla stanchezza.

L'errore fece letteralmente esplodere il convertitore.

La persona che eseguiva la misura, essendo inginocchiata davanti all'apparato, se la cavà con ustioni alle mani i cui effetti furono permanenti. Gli altri 2, in pedi dietro a lui, furono colpiti in pieno dalla vampata; uno perse la vita, l'altro ebbe il volto completamente sfigurato.

 

Fare gli "eroi" lavorando per 18 - 24 ore consecutive serve a poco, se va bene; se va male rischi di far male a te ed agli altri.

 

Purtroppo questa semplice ed evidente verità sembra che non sia recepita da alcuni "(ir)responsabili".

[drugo66]

Il problema è anche, secondo me, che siamo circondati sempre più da più "menti" commerciali e meno tecniche: ecco perchè ci si sente dire sempre più spesso: "Ma se ci vogliono solo 10 minuti !!!", frase che, onestamente, fino a poco tempo fa, mi faceva andare su tutte le furie.

Adesso non ascolto quasi più quelle provocazioni (perchè questo poi sono) e mi limito a cercare di dare il meglio di me come posso; sono stanco ed è ancora un'ora ragionevole ? Allora faccio una pausa; è diventata un'ora indecente e sono cotto come una pera ? Vado a casa e se ne parla il giorno dopo. In queste situazioni se mi urlano dietro o fanno commenti poco edificanti ma nei limiti dell'educazione, mi limito a non rispondere. Se si passa il segno e si diventa maleducati (per mia fortuna non mi è più capitato da un pò di tempo) allora sì che è il momento di rispondere per le rime ...

Spesso anch'io nei week end mi riguardo le cose fatte, risolte o meno, mi scorro dei manuali, ma sto cercando di costringermi sempre di più a non pensarci e a fare altre cose ogni mese che passa. La questiione della stanchezza mentale è di importanza fondamentale: si "tira" finchè la mente è lucida ed esiste almeno una parvenza di ragionamento utile; se questo non c'è, vuoi per stanchezza o magari per un inizio di malattia o anche perchè si è dormito poco, anche il ciclo più semplice può diventare impossibile.

Quindi "staccare" e riposarsi è troppo importante per rinunciarci.

[leleviola]

Come non condividere ciò che ha scritto drugo66, lo condivido in pieno,

a volte anch'io cerco di ridare un'occhiata a casa a ciò che ho fatto ma preferisco spesso non insistere troppo anche perchè mi sono sempre più convinto che verificare on-line le problematiche è sempre più risolutivo del problema, quando cerchi di capire direttamente perchè certi problemi accadono per me è sempre meglio,

poi c'è problema e problema, a volte accade spesso anche il contrario, la pressione di chi ti sta accanto quando sei sul pezzo non ti fa risolvere questioni banali che poi con calma vedi subito. E' fondamentale esser sempre riposati e poi quando a casa provo a riguardare qualcosa e mi prende un po' di sonnolenza, chiudo tutto immediatamente senza mai insistere e vado a riposare, anche perchè so che se insisto potrei solo che far danni

[step-80]

Accidenti...

 

15 ore fa, batta scrisse:

succede ancora che la soluzione mi si presenti accendendosi come una lampadina al risveglio.

 

Capita anche a me e credo un po a tutti, la mente stanca e tirata non ti fa vedere ad un palmo dal naso.E quelli che ti stanno col fiato sul collo non migliorano certo la situazione. 

Ora riderete, ma spesso elaboro le migliori soluzioni ai problemi mentre sono sotto la doccia. Ho imparato quindi che quando non riesco a venirne fuori è inutile continuare a sbatterci la testa: spengo tutto e me ne vado a casa,mi butto sotto la doccia e...sarà lo scrosciare dell'acqua,il rilassarsi, non so..fatto sta che molto spesso le soluzione viene da sola e ti rendi conto di averla avuta sempre li, a portata di mano. 

 

15 ore fa, batta scrisse:

Fino a quando non impareremo a dire di no, fino a quando non fisseremo dei limiti invalicabili, fino a quando non avremo il coraggio di spegnere il generale e dire: "Ciao a tutti, ci si rivede domani mattina", mandando a quel paese tutti quelli che ti vogliono fermare, la situazione potrà solo peggiorare.

Quanto hai ragione. 

Credo che la figura del programmatore sia, al 99.99% dei casi, quella di un bonaccione(non sto dicendo stupido sia chiaro). 

In fondo siamo dei maledetti perfezionisti,e se abbiamo dei problemi insoluti al mattino fatichiamo a guardarci allo specchio. Naturalmente parlo di chi ha intrapreso questa carriera per passione..i cialtroni purtroppo sono ovunque. 

 

Io lavoro in una piccola realtà produttiva in forte crescita composta da me, mia moglie e i suoi 2 fratelli. Quando parecchi anni fa sono stato assunto da mio suocero(che forse aveva visto lungo) un plc non sapevo nemmeno cosa fosse. Tutti i problemi di automazione del tempo li risolveva mio suocero col martello ed un paio di cacciaviti. Al massimo della libidine spuntava qualche finecorsa pneumatico ed un cilindro, stop. Col tempo mi ha lasciato spazio sino a farsi totalmente da parte e solo ora capisco il sacrificio che gli è costato: quel lavoro era la sua vita.

Ora viene in azienda 'da pensionato' ; sta delle ore ad osservare orgoglioso i miei progressi e questo mi rende felice. Il lato nero della medaglia è che NON sono stato assunto come programmatore: quella figura non esisteva al tempo,ma me la sono creata. Purtroppo questo ha fatto si che tra i miei 'colleghi' si insinuasse l'idea che progettare e programmare macchine sia per me un hobby, tuttora, come i puzzle. Effettivamente la cosa è nata cosi, per gioco. Ma non vuol dire che lo sia ancora .

Capita quindi che mi vengano richiesti continuamente cambi di programma, aggiunte di cicli che non servono ad un tubo perchè..tanto il programmatore è li, non costa nulla,credono in fondo che io mi diverta come un pazzo...si forse all'inizio,ora meno. Come giustamente detto da Batta, dobbiamo fissare un limite invalicabile altrimenti non ci sarà mai fine alle richieste assurde. 

 

12 ore fa, drugo66 scrisse:

"Ma se ci vogliono solo 10 minuti !!!", frase che, onestamente, fino a poco tempo fa, mi faceva andare su tutte le furie.

Questa frase la sento spesso anch'io ed in svariate salse.

Se c'è una cosa che non tollero è proprio quando chi non sa nulla di una cosa ti vuole insegnare come farla. 

Per come sono fatto io , se non so una cosa me ne sto zitto a guardare chi sa farla che fa il suo mestiere. Al massimo posso dare una opinione, se gradita. Oppure mi metto sotto per studiare come farla. 

[batta]

Quote

La persona che eseguiva la misura, essendo inginocchiata davanti all'apparato, se la cavà con ustioni alle mani i cui effetti furono permanenti. Gli altri 2, in pedi dietro a lui, furono colpiti in pieno dalla vampata; uno perse la vita, l'altro ebbe il volto completamente sfigurato.

Fortunatamente non mi sono mai trovato nemmeno vicino a situazioni così drammatiche.
Ma l'incidente è sempre in agguato e, con la stanchezza, le probabilità aumentano in modo esponenziale.

[step-80]

Buonasera ragazzi

 

a volte siccome non mi basta bucarmi il cervello a lavoro, mi vado a trovare gli impicci pure se non mi vengono a cercare. 

 

Questo per esempio, è un quesito trovato qui sul forum di un utente del quale ora non ricordo il nome. Incuriosito ho provato a testarlo sul mio ambiente di sviluppo(Mitsubishi) anche se credo non vi sia differenza con altri ambienti. 

Non apro una nuova discussione perchè ho ritenuto sia attinente con l'oggetto della stessa...

Si trattava molto semplicemente di realizzare una logica con la quale ,ad ogni pressione di un tasto, 2 uscite assumessero lo stato :0-1 , 1-1 , 1-0 , 0-0 per poi ricominciare da capo. 

 

Ho provato a stendere un rung e poi in simulazione ho visto che non funzionava(o meglio, la variabile 'passo' che uso per le transizioni rimaneva sempre a zero ). Poi, provando in altri modi analoghi funzionava ma tuttora non riesco a capire perchè nel primo non ne voleva sapere. 

 

Spiego brevemente la mia logica: 

-Se premo 'cambio'(fronte di salita) AND 'passo' =0   THEN carico 5 in 'passo';

-Se premo 'cambio'(fronte di salita) AND 'passo' =5   THEN carico 10 in 'passo';

-Se premo 'cambio'(fronte di salita) AND 'passo' =10   THEN carico 15 in 'passo';

-Se premo 'cambio'(fronte di salita) AND 'passo' =15   THEN carico 0 in 'passo';

 

Posto 3 immagini; la prima è la versione che non funziona dove ho inserito un solo fronte e poi le diramazioni in parallelo. Per la cronaca, non funziona nemmeno se dopo il 'MOV' faccio un jump alla riga seguente..

La seconda e la terza immagine invece, funzionano perfettamente.

Qualcuno di voi ha tempo/voglia di spiegare ad un somaro come me il perchè?

Vi ringrazio anticipatamente..

 

[Roberto Gioachin]

Il motivo è legato a come le IEC61131 hanno stabilito debba essere eseguito ogni singolo network.

Non uso Mitsubishi, ma per Panasonic vale la stessa regola.

Nella prima versione tutte le comparazioni ed i MOV vengono eseguiti uno dopo l'altro con la stessa condizione "Cambio", il risultato sarà che la variabile "Passo" assumerà tutti i valori fino all'ultimo che è zero, poi si passa al network successivo.

Nella seconda versione invece il compilatore fa in modo di congelare il valore della variabile "passo" in una variabile temporanea, sarà poi questa che verrà confrontata co i valori costanti, in questo modo non avrai più l'esecuzione di tutti i MOV ma solo del primo (con il primo fronte di salita).

Dei tre il modo più corretto è l'ultimo, anche se io non userei mai un metodo simile, è un tale spreco di risorse .....

Ciao

[step-80]

Ciao Roberto, grazie per la risposta. 

 

Sei stato molto chiaro anche se alcuni dubbi permangono..non per la tua spiegazione ma per altre prove che nel frattempo ho fatto.

 

Per esempio, nella prima versione(quella che non funziona) non appena forzo il contatto cambio ad '1' succede ciò che hai detto tu: vedo la variabile 'passo' rimanere a 0 ma solo perchè il cambio è stato talmente rapido da non poter essere notato. In realtà ha assunto tutti i valori 5,10,15 per poi ,appunto, tornare a 0. Il fatto è che a questo punto mi aspetterei che, rimettendo ad Off il contatto, su un nuovo fronte vi sia un nuovo loop ...invece ho scoperto che la variabile 'passo' continua a cambiare valore continuamente( me ne sono accorto perchè non si riesce a scriverla con un valore a piacere). Ma perchè? Voglio dire, visto che ho usato il fronte, la scansione successiva a quella dello start dovrebbe trovare condizione OFF per cui, secondo i miei calcoli, dovrebbe per lo meno attendere un nuovo trigger..al di la che poi sia sbagliato il ragionamento. Perchè continua a loppare?

 

Allego un altro screen: in questa si vede che, chiudendo il contatto, la variabile 'var1' si incrementa continuamente, indipendentemente dal fatto che io poi porti ad Off lo stesso. 

 

2 ore fa, Roberto Gioachin scrisse:

Dei tre il modo più corretto è l'ultimo, anche se io non userei mai un metodo simile, è un tale spreco di risorse .....

 

Pensa che io lo credevo un buon sistema...

Lo spreco di risorse deriva dal fatto che uso una word e non semplici bit , oppure non ti piace il sistema in se? 

Adoro le critiche, mi piace imparare da chi ne sa più di me!

[leleviola]

scusami step-80

ma è un modo contorto il tuo di ragionare sulla logica di esecuzione del programma del PLC,

il fronte di salita dell'operando "passo" devi metterlo una sola volta seguito in AND delle 4 condizioni poi possibili in OR e una volta presa in considerazione una condinzione contemplata uscire con un JUMP dalla verifica delle altre condizioni perchè solo una ne deve essere contemplata, non mi sembra ci niente con cui arrovelarsi il cervello