Funzione UMOVE_BLK, TIA PORTAL

[salernozz]

@step-80proverò ad avere questa mentalità, il cammino che ho di fronte è infinito lo capisco.. E non dico solo di essere capace a programmare.. No quello è solo una parte del mondo che mi aspetta: dagli strumenti che si utilizzano, ai dispositivi, dalle macchine, ai linguaggi,

il sapere gestirsi e il saper bene ogni argomento, i problemi che possono emergere eccetera eccetera eccetera. 

Spero veramente che l' esperienza e il tempo me le faccia imparare, oltre alla mia costanza: la cosa di cui ho paura però è metterci 10 anni. Però oh non posso farci nulla, devo solo essere costante. 

Ciò che penso è che gli altri ce l hanno fatta, perché io non dovrei farcela? 

 

[salernozz]

52 minuti fa, batta scrisse:

Non è che un linguaggio sia migliore dell'altro, semplicemente ognuno si presta meglio dell'altro per svolgere certi compiti.

Ok batta, quando saprò bene o almeno molto molto meglio di orami focalizzeró anche sul C

Premetto che ho fatto anche un pochino di grafchet o flowchart,non mi ricordo il nome

[salernozz]

1 ora fa, salernozz scrisse:

1 ora fa, step-80 scrisse:

cosa non ti è chiaro? 

adesso te lo spiego proprio in generale come l' ho capito.

 

Mettiamo che devo salvare in memoria (una qualunque) un numero che è 35463456, uso il formato UDInt?

e se devo salvare un numero tipo da 250 a 254 uso USInt? Non mi serve UInt e nemmeno un DInt, giusto?

 

poi gli esadecimali? quando mi servono?

 

Spero veramente che nel libro che ho ordinato ci sia spiegato l'argomento in questione.

Ma non come te lo spiega la siemens che sembra che l' argomento debba conoscerlo già, nono, proprio d

Quando puoi, non voglio sollecitare nulla (come era già successo) ma probabilmente o magari non ti eri accorto o ti è passato di mente 

[step-80]

@salernozz volente o nolente quando si scrive in un forum ci si fa una idea di chi sta dall'altra parte del terminale...penso sia normale. 

L'idea che mi sono fatto di te è di un ragazzo molto volenteroso e determinato, ma che forse - se posso permettermi - sta prendendo il problema dalla parte sbagliata. 

Non può essere PLC Forum ad illuminarti su TUTTI gli aspetti di un plc. In circa una settimana hai aperto varie discussioni, tutte trattanti argomenti diametralmente opposti, e spesso chiedendo di una nella discussione dell'altra ma questo ci sta.  

 

Non posso credere che siamo l'unica speranza che hai, anche perchè i dubbi saranno tantissimi e credimi: se aprirai una discussione ogni volta che ne avrai uno non basterà tutto lo spazio web mondiale.

 

Per quanto riguarda i tipi di dati, è molto semplice. 

Ogni tipo di dato ha dei limiti ben definiti, non c'è da inventarsi nulla:

 

Tu solo sai che valori potrà mai assumere la variabile 'Pluto' e di conseguenza deciderai di che tipo dichiararla. Se hai una macchina che fa massimo 30000 pezzi al giorno, dichiarare una variabile 'contapezzi giornaliera' da azzerare tutte le mattine di tipo Int (-32768 to +32767) non è sbagliato, perchè ci stai dentro. Concettualmente però sarebbe meglio usare un UINT (0 to +65535) in quanto il tuo contapezzi non potrà assumere valori negativi. 

Capisci da solo però che se devi creare anche un 'contapezzi totale' che non si azzera mai e che magari può raggiungere diversi milioni di pz è meglio usare una UDINT(0 to +4294967295). 

 

Dai un'occhiata anche qui

 

Spero di essere stato in parte chiaro. 

Modificato: 5 agosto 2019 da step-80

[salernozz]

35 minuti fa, step-80 scrisse:

Non posso credere che siamo l'unica speranza che hai, anche perchè i dubbi saranno tantissimi e credimi: se aprirai una discussione ogni volta che ne avrai uno non basterà tutto lo spazio web mondiale.

Non sai quanta voglia ho che faccia un corso o che un programmatore mi si affianchi, sarebbe un sogno

Ora come ho detto in un altra discussione il capo è in ferie.. Ma in ogni caso non saprei nemmeno bene se riesca nel mio intento.. 

 

Per la spiegazione e per la pagina riportatami ti ringrazio.. In sostanza era come l' avevo pensata anche io.. Avevo bisogno di una certezza e ora l' ho avuta. 

 

 

 

 

Ora mi è arrivato il libro e cercherò il meno possibile di riportare discussioni che magari si basano solo ed esclusivamente sulle basi o su concetti facili. Proverò a studiarlo in qualche modo, poi quando sarà il momento del corso magari andrò là un po' più preparato rispetto a quando ho iniziato. In più finché non riesco ad imparare bene un argomento ci rimango finché non mi entra in testa

 

Nel caso non riesca ad uscirne fuori, il forum, la tengo come ultima speranza. 

 

Niente, grazie per la pazienza, non voglio fare vittimismo (non so se si dice così) però mi hai fatto capire che forse ho 'preteso' troppo

 

Modificato: 5 agosto 2019 da salernozz

[step-80]

Hai MP

[salernozz]

Oddio, MP, mai sentito

😕

 

 

MP mobile? 

Modificato: 5 agosto 2019 da salernozz

[step-80]

MP= Messaggio Privato

[batta]

56 minuti fa, salernozz scrisse:

Ok batta, quando saprò bene o almeno molto molto meglio di orami focalizzeró anche sul C

Scusa, rileggendo il mio post mi sono reso conto di essermi espresso male.
Almeno ad oggi, sono pochissimi i PLC programmabili in C e, salvo forse qualche eccezione che io non conosco, sono di marchi meno noti (che non vuol dire peggiori, ma solo meno diffusi). Il confronto tra linguaggi cui mi riferivo era tra il ladder (KOP per Siemens) e il testo strutturato (SCL per Siemens).

 

23 minuti fa, salernozz scrisse:

In sostanza era come l' avevo pensata anche io.

Sì, è così. In base ai valori che sai che dovrai gestire, decidi il formato più adatto. Attenzione solo a non fare scelte troppo restrittive solo per risparmiare qualche byte.
Data la tua età non so se hai presente il panico mondiale che ci fu nel passaggio dal 1999 al 2000, per il Millennium bug. Poi non accadde praticamente nulla, ma erano stati paventati scenari catastrofici.
Tutto era dovuto al fatto che le date erano espresse nel formato gg/mm/aa (o mm/gg/aa), ovvero con solo due cifre per l'anno. Ora la scelta operata a suo tempo dai programmatori ci fa sorridere ma, a quei tempi, con le memorie a disposizione, risparmiare due byte era molto importante.
Perché ti dico questo? Partiamo dall'esempio del contapezzi. Oggi lavori su una linea che sai che non potrà mai produrre più di 30000 pezzi al giorno, e decidi di usare una variabile UINT (quindi da 0 a 65535). Fra un anno quella linea verrà rimodernata e i pezzi diventeranno 60000. Fra due anni, altro maquillage e i pezzi diventeranno 80000. Per risparmiare due byte, ti ritrovi con una grana da risolvere. Con le memorie a disposizione, oggi, anche nei PLC, gli sprechi inutili sono sempre inutili, ma i risparmi esagerati possono provocare più danni degli sprechi. In altre parole, tieniti sempre ampi margini.
Altro esempio: devi gestire un valore percentuale, quindi da 0 a 100, e decidi di usare una SInt. Domani il cliente ti chiede di visualizzare la percentuale con una cifra decimale. Di solito si risolve gestendo la percentuale moltiplicata x10 (quindi valori da 0 a 1000), e visualizzandola sul pannello operatore con una cifra decimale. Se hai usato una SInt, devi cambiare formato.
Modificare il formato di una variabile potrebbe essere indolore (per esempio, solo per restare in casa Siemens, se sono Siemens PLC e pannello operatore, la modifica che fai nel PLC viene automaticamente adattata nel pannello operatore), o ti potrebbe sconvolgere la vita (se il pannello operatore non è Siemens, devi leggere le variabili facendo riferimento all'indirizzo assoluto e, se cambi formato ad una variabile, vengono modificati gli indirizzi di tutte le variabili che seguono). Ecco che per risparmiare 1 byte, ti sei messo nei casini.
E poi c'è anche una questione di abitudini. I formati più usati sono Int, DInt e Real.

E anche una questione di ordine. Mi riallaccio nuovamente all'esempio del contapezzi. Hai un contatore giornaliero che potresti gestire con una Int, ed un contatore mensile che richiede una DInt. Sono due contatori, entrambi contano pezzi prodotti, nel DB li dichiari uno in fila all'altro. Perché usare una Int per uno, ed una DInt per l'altro?

[step-80]

Concordo con tutto quanto detto da @batta . Anch'io mi sono trovato nei casini per aver risparmiato 2 byte, ed alla fine non conviene. 

Contapezzi sempre e solo Dint, tanto per restare in tema. 

 

Ovviamente la discussione aveva valore didattico e quindi ho fatto esempi di come usare le variabili..questo per rafforzare l'idea che, ancora una volta , la teoria va bene ma deve essere accompagnata da una buona dose di esperienza.

[leleviola]

1 ora fa, step-80 scrisse:

Concordo con tutto quanto detto da @batta . Anch'io mi sono trovato nei casini per aver risparmiato 2 byte, ed alla fine non conviene. 

Contapezzi sempre e solo Dint, tanto per restare in tema.

non fate troppo gli "sboroni" in passato con i PLC di una volta il fatto di risparmiare 2 byte di qua e 2 byte di la dava la possibilità di utilizzare un PLC di fascia più bassa rispetto a uno di fascia più alta e dal costo diverso, a parte la battuta con i PLC di oggi c'è poco da fare i risparmiosi, concordo anch'io meglio sempre utilizzare due DINT che lesinare su due INT, scusate l'OT

[salernozz]

Oh cavolo ora capisco, si in effetti sarebbe una menata. Non l'ho mai provata però posso immaginare il casino venuto fuori solo per aumenti di produzione (es).

Va bene, quando farò veri e propri programmi terrò a conto di essere ampio con i formati ma non stratosferico. 

 

Anche questi sono sempre racchiusi, a parere mio, nei "segreti del programmatore". Ennesima cosa che aggiungo nel mio "cassetto"

 

Grazie per la dritta! 

[batta]

13 ore fa, step-80 scrisse:

Ovviamente la discussione aveva valore didattico e quindi ho fatto esempi di come usare le variabili..

Questo era chiarissimo, ed è proprio perché era chiarissimo che mi sono riallacciato al tuo esempio.

 

11 ore fa, salernozz scrisse:

Anche questi sono sempre racchiusi, a parere mio, nei "segreti del programmatore"

Più che segreti, direi che è una questione di esperienza.
Considera poi che anche il modo di programmare si evolve con l'evolversi delle prestazioni.
Dopo quanto detto nel precedente post, non vorrei passare per sprecone. Anzi, mi ritengo ancora appartenente alla vecchia guardia, quando dovevi stare molto attento a non sprecare risorse. Per dire, io ho ancora l'abitudine che se devo dividere un numero in virgola mobile per 10, preferisco moltiplicare x0.1. La divisione, tra le quattro operazioni classiche, è la più pesante. Sinceramente, da molto tempo non controllo i tempi di esecuzione delle varie operazioni e, con le CPU attuali, la differenza probabilmente è insignificante, ma l'abitudine mi è rimasta. Come mi è rimasta l'abitudine, se devo moltiplicare o dividere un intero x2, x4, x8 (e via di seguito) fare uno shift rispettivamente a sinistra o a destra di 1, 2 o 3 posizioni.
Si tratta di usare un po' di buonsenso. Se un contatore (tanto per rimanere sullo stesso esempio) deve raggiungere valori a 5 cifre, non ci penso due volte, ed uso una DInt. Se devo contare da 1 a 10, uso una SInt o, al massimo, una Int.
Oggi poi, sempre per il fatto che le prestazioni delle cpu sono molto aumentate, io vedo la tendenza a fare largo uso del formato Real. E, ammetto, anch'io mi sono adeguato a questa "brutta abitudine". Risulta comodo. Se devi visualizzare grandezze con decimali, non devi più sbatterti per decidere, e poi ricordarti, ad ogni utilizzo, che quel valore è moltiplicato x10, x100 o x1000.
Una volta il formato Real lo usavi solo nei casi strettamente necessari, perché molto pesante per la cpu (non tanto per i 4 byte, ma in tempo di esecuzione delle operazioni).

[leleviola]

22 minuti fa, batta scrisse:

Una volta il formato Real lo usavi solo nei casi strettamente necessari, perché molto pesante per la cpu (non tanto per i 4 byte, ma in tempo di esecuzione delle operazioni).

ovviamente condivido, il Real solo se strettamente necessario

[max.bocca]

Anch'io facevo operazioni di spostamento per dividere o moltiplicarli x,2,4,8ecc addirittura se dove contare fino a 255 usavo i byte, con il 200 facevo palettizzatori quindi al massimo di risparmio di byte.. ora utilizzando alcuni Hmi che non gli piacciono i byte utilizzo le Word anche valori piccoli. 

Anch'io facevo operazioni di spostamento per dividere o moltiplicarli x,2,4,8ecc addirittura se dove contare fino a 255 usavo i byte, con il 200 facevo palettizzatori quindi al massimo di risparmio di byte.. ora utilizzando alcuni Hmi che non gli piacciono i byte utilizzo le Word anche valori piccoli. 

[salernozz]

1 ora fa, batta scrisse:

questione di esperienza.

Quella che mi manca, giustamente però, non posso averla. Se avessi esperienza probabilmente avrei vissuto già un altra vita: per sapere quello che sapete voi ci vuole una vita intera.

 

Sta di fatto che come ho già detto cercherò di utilizzare formati ampi ma non stratosferici:

 

se devo contare un valore che va da 0 a 160 userò una Uint, non di certo una Dint e nemmeno una USInt

 

se devo salvare un valore che mi va da -1 a +2 userò una SInt, poi valuterò dalla situazione e dal processo da fare se utilizzare una SInt o una Int

[batta]

1 ora fa, leleviola scrisse:

ovviamente condivido, il Real solo se strettamente necessario

Diciamo che, con le nuove cpu, mi faccio molti meno scrupoli rispetto ai tempi passati.
Se, legati ad una variabile, so che dovrò eseguire calcoli in virgola mobile, quasi di sicuro dichiaro anche la variabile in virgola mobile.
Un tempo, magari anche perché il pannello operatore o l'applicativo di supervisione non gestivano i Real, facevi tutto con Int e DInt.
Poi però, se in mezzo ci dovevi fare un calcolo in virgola mobile, ti ritrovavi a dover convertire Int in Dint, poi DInt in Real, poi facevi i calcoli, poi riconvertivi il Real in DInt o in Int.
A questo punto, visto che oggi i pannelli operatore e gli scada non hanno più problemi con i Real, tanto vale fare tutto direttamente in Real.

[salernozz]

6 ore fa, batta scrisse:

tutto direttamente in Real.

Tutto tutto tutto?

 

Tranne le booleane certo

[batta]

9 minuti fa, salernozz scrisse:

Tutto tutto tutto?

No, leggi bene, non tutto.

Un contapezzi va fatto assolutamente usando interi. Il preset di un timer deve essere in formato Time (che poi è un DInt). Se usi un indice in un array, in un ciclo FOR, o in un CASE, devi usare interi.
Però, se devi visualizzare la velocità di un tappeto che, supponiamo, è il risultato di un calcolo in virgola mobile, non ha molto senso alla fine del calcolo riportare tutto su una INT, magari moltiplicato per avere cifre decimali, solo per risparmiare due byte. Un tempo lo facevo, oggi non più.

[ken]

io, per abitudine, lavoro ancora in int e dint. ai drive passo un valore in % e il 100% per me è 10000 (100.00)

ho già tutto fatto così per s7 e per comodità e abitudine uso ancora scalare tutto a quei valori. 

potrei lavorare in real, non cambierebbe più di tanto, invece che 10000 avrei 100.00. ci guadagno in salute e in velocità

[Cesare Nicola]

il 5/8/2019 at 16:49 , salernozz scrisse:

Invece mi continuerò ad impegnare in tutto ciò che incontrerò cercando di evitare il più possibile il C,

Fino alla morte o quasi

Visto che sei giovane e morirai tra tanto e in quel tanto dovrai lavorare e verosimilmente usare tanti prodotti, ti consiglio, come già hanno fatto, di cambiare approccio: imparerai che non sempre puoi scegliere e, o ti farai andar bene ciò che la situazione ti ha portato ad usare, o avrai sempre dei limiti e delle difficoltà. Sto affrontando un progetto importante con PLC, azionamenti, inverter e HMI Mitsubishi. Mi piacciono quei prodotti, mi ci sto trovando bene? Così così, poco, a volte nulla. Posso scegliere? No, perché li ha imposti il cliente. Posso dire al mio capo che non voglio fare quel lavoro? No, mica siamo in 500 in ditta, che c'è sempre qualcuno disponibile. Oppure sì, perdendo tutta la considerazione che lui ha di me e rendendomi un "peso" da smaltire il prima possibile anziché un tecnico affidabile e disponibile. Senza contare che si lavora per i soldi, oltre che per la soddisfazione e poter dire in giro "io conosco il C o il pinco palla", ti apre a nuove opportunità professionali; se alle prime esperienze con Mitsubishi avessi detto "mi fa schifo e cercherò di evitarlo il più possibile", ora forse mi troverei senza un paio di clienti che ci fanno guadagnare qualche bel soldino e a me i soldini piacciono tanto. Senza contare che nulla fa schifo a prescindere: si trova del buono anche dove meno te lo aspetti.
Questo è un esempio reale di cosa ti potrà capitare, per darti l'idea.

[salernozz]

Se, io che ho appena iniziato, lavorassi per i soldi, avrei già perso in partenza a parere mio. Ora di soldi non posso affatto parlarne, non so fare un tubo di concreto. Ora mi ci vuole solo costanza.

 

Però concordo con te il fatto della moltitudine di prodotti, linguaggi, varianti, ecc. Dovrò adeguarmi a seconda della richiesta..

A pensarci ora come ora la strada sembra infinita, però credo che passettino per passettino, riesca anche io come voi master a raggiungere un traguardo.

Lo spero.

 

Grazie per il pensiero @Cesare Nicola

[Cesare Nicola]

2 minuti fa, salernozz scrisse:

Se, io che ho appena iniziato, lavorassi per i soldi, avrei già perso in partenza a parere mio

Vero, bravo. Io ovviamente ho un po' estremizzato in questo caso, ma senza andare molto lontano dalla realtà; con moglie e figli a carico, la soddisfazione la lascio ad altri. 🙂

5 minuti fa, salernozz scrisse:

A pensarci ora come ora la strada sembra infinita, però credo che passettino per passettino, riesca anche io come voi master a raggiungere un traguardo

E' quello che abbiamo fatto tutti, passettino per passettino. Io a 50 anni sono tutto tranne che un "master"; sai quanti passettini devo fare, ancora, hai voglia!

[salernozz]

 

3 minuti fa, Cesare Nicola scrisse:

Io a 50 anni sono tutto tranne che un "master"; sai quanti passettini devo fare, ancora, hai voglia!

Lo so, ma avrai già raggiunto bei traguardi, che invidiaa

 

6 minuti fa, Cesare Nicola scrisse:

con moglie e figli a carico, la soddisfazione la lascio ad altri. 🙂

EROE.

 ho detto tutto.

[Cesare Nicola]

18 ore fa, salernozz scrisse:

EROE

Non esageriamo. 🙂