Dubbio su creazione segmenti kop

[Simone.Salarsi]

in questo modo

31 minuti fa, leleviola ha scritto:

Scusami ma forse è una funzionalità che non conosco, bisogna che cerchi di capire come usarla, puoi darmi qualche dritta? C'è la possibilità di racchiudere un segmento in più rami, come? Scusa l'ignoranza ma è anche a questo che serve il forum

 

 

 

 

[acquaman]

Intendevo questo:

 

Con il 300 non si può fare.

33 minuti fa, leleviola ha scritto:

Scusa l'ignoranza ma è anche a questo che serve il forum

 

E' il bello del forum ogni discussione può essere uno spunti per  aumentare le proprie conosceze.

[marco1278]

2 ore fa, batta ha scritto:

Poi, se un programma è scritto male, è scritto male in qualsiasi linguaggio. Pensa ad un programma scritto male e senza commenti in testo strutturato: non ne vieni fuori.

Esattamente! Se è scritto male non ne vieni fuori più...certe volte è anche dovuto al fatto che il softwareista è autodidatta e si inventa cose di cui esistono già le funzioni. 

 

Come ho già detto secondo me i linguaggi vanno studiati tutti e lo dico anche per me.

 

 

[Cesare Nicola]

12 ore fa, leleviola ha scritto:

C'è la possibilità di racchiudere un segmento in più rami, come? Scusa l'ignoranza ma è anche a questo che serve il forum

Credo si riferisse alla possibilità di fare questo.

 

Mentre in passato si poteva fare solo questo:

 

Edit: non avevo visto che altri avevano già risposto, scusate. Ma come si cancella un post?

 

Modificato: 13 gennaio 2020 da Cesare Nicola

[step-80]

Francamente questa cosa degli informatici che si autoproclamano i gran conoscitori del mondo plc ha un po stancato. 

 

Ho avuto a che fare anch'io con informatici in grado di scrivere software complicatissimi e difficilissimi da interpretare(persino per loro), ma che non erano assolutamente in grado di prevedere i malfunzionamenti generati dai propri listati. Spesso la macchina si piantava o assumeva stati casuali : a quel punto l'informatico si gratta la testa e,molto spesso,da la colpa all'impianto elettrico .

 

Non è sempre detto che avere moltissime nozioni in testa aiuti(almeno in questo campo). Spesso sono sufficienti un buon numero di esperienze dirette sul campo e un po di pelo sullo stomaco: gli informatici spesso tendono a filosofeggiare "e se fosse questo" , "e se fosse quello"..come se gli IF fossero diventati un mantra pure nella vita reale, quando spesso il buon vecchio elettricista tuttofare magari ha già capito dove sta il problema. Voglio dire che a volte in questo mestiere bisogna osare anche dove gli altri pensano di trovar nulla.

 

Questa ovviamente è una mia opinione e si riferisce a esperienze personali. 

[Cesare Nicola]

2 minuti fa, step-80 ha scritto:

. Spesso sono sufficienti un buon numero di esperienze dirette sul campo e un po di pelo sullo stomaco: gli informatici spesso tendono a filosofeggiare "e se fosse questo" , "e se fosse quello"..come se gli IF fossero diventati un mantra pure nella vita reale, quando spesso il buon vecchio elettricista tuttofare magari ha già capito dove sta il problema

Io faccio sempre l'esempio dell'asse che non si muove correttamente. Uno va a verificare parametri, dimensionamento, tarature, ecc.; l'altro prende uno straccio e pulisce le guide dalla polvere impastata con l'olio e tutto torna magicamente a funzionare. 🙂

 

[Cesare Nicola]

Il 10/1/2020 alle 22:54 , Novis ha scritto:

non ereditati dallo schema a contatti per semplificare la vita agli elettricisti

Sbagliato. Gli elettricisti sono anche quelli che a volte ti evitano di fare un viaggio in Papuasia per correggere un contatto che tu hai erroneamente inserito e che provoca un malfunzionamento della macchina. Se li aiuti, spesso aiuti te stesso e la tua ditta. A meno che non vuoi fare i programmi volutamente complessi e con linguaggi evoluti per far vedere al capo che solo tu sai metterci mano e per garantirti ogni tanto un viaggetto qui e là a mangiare a sbafo e mettere qualche soldino in più in busta paga; lo dico perché ne ho visti, potrei fare nomi e cognomi. 😄

[Roberto Gioachin]

Bisogna dire anche che differenti ambienti di programmazione (di diversi produttori intendo), possono rendere più facile questo o quel linguaggio, per cui può esserci una diversa veduta a seconda dell'ambiente che si utilizza, ma io farei una considerazione diversa. In genere le aziende (oppure il normatore) decidono di aggiungere o togliere un tipo di linguaggio sulla base di due considerazioni.

Una prima considerazione è tecnica, se un linguaggio non permette di ottenere quello che la tecnica oggi permette, va eliminato; se un nuovo linguaggio permette di crescere tecnicamente, va introdotto.

Una seconda considerazione è più commerciale; se un linguaggio non viene più usato o usato solo da pochi, va tolto.

Quindi se è stato introdotto il linguaggio ST significa che si ritiene possa portare dei vantaggi.

Se non è stato tolto il Ladder significa che molti lo usano e che non limita la crescita tecnica di un prodotto.

Detto questo, per quale motivo, se le aziende non hanno eliminato il Ladder, qualcuno lo deve ritenere un linguaggio inutile?

[step-80]

17 minuti fa, Cesare Nicola ha scritto:

Io faccio sempre l'esempio dell'asse che non si muove correttamente. Uno va a verificare parametri, dimensionamento, tarature, ecc.; l'altro prende uno straccio e pulisce le guide dalla polvere impastata con l'olio e tutto torna magicamente a funzionare. 🙂

 

Esatto, proprio quello che volevo dire. Mio padre mi ha sempre esortato a lavorare senza i cosiddetti 'paraocchi'. Tradotto significa allargare gli orizzonti,anche a ciò che normalmente non si penserebbe.

 

E aveva ragione, cavolo se aveva ragione.

[batta]

8 ore fa, step-80 ha scritto:

Ho avuto a che fare anch'io con informatici in grado di scrivere software complicatissimi e difficilissimi da interpretare(persino per loro), ma che non erano assolutamente in grado di prevedere i malfunzionamenti generati dai propri listati.

Sia chiaro che non voglio certo sminuire gli informatici, e che rimango sempre convinto che un informatico abbia la possibilità di arrivare a livelli più elevati rispetto a chi non ha nozioni approfondite di informatica.
Ma programmare un PLC è estremamente diverso da sviluppare un programma per un PC e, quanto descritto da Step-80, accade molto spesso.
L'informatico sarà bravo a gestire classi, moduli, eccezioni, ma è abituato a ragionare in modo diverso: premo un pulsante, e lancio questa routine; premo quest'altro pulsante, ed apro quel form (sto banalizzando, chiaramente).
Nella programmazione di un PLC devi invece tener presente che "il resto del mondo non si ferma perché hai aperto un altro form", e non si ferma nemmeno in attesa che tu faccia una qualche operazione. Quanti post è capitato di leggere, di utenti con basi informatiche al loro primo contatto con un plc, che chiedevano perché quella tale uscita rimaneva alta anche se non richiamava più la funzione dove l'uscita veniva comandata? O perché rimaneva alta, nonostante avesse dato un comando di reset, ma senza tener conto che, da qualche altra parte, veniva nuovamente alzata?
Per esperienza personale, posso affermare che i programmi sviluppati da informatici puri peccano proprio nella gestione delle anomalie: il ciclo funziona se tutto procede come previsto, ma quando accade qualcosa di imprevisto, non si riparte più, proprio perché l'imprevisto non era stato previsto.
Non dimentichiamo poi che, oltre alle mille condizioni che si possono verificare durante il funzionamento, si devono fare i conti anche con una delle tante leggi di Murphy, che afferma: "Non riuscirai mai a fare un programma a prova di tonto, perché i tonti sono molto ingegnosi". Nel nostro settore, si può riferire agli operatori. Come ci sono operatori molto in gamba, ci sono operatori che si inventano procedure o manovre assolutamente insensate, che nessuno mai ha valutato nella stesura del software. Bene, per programmare un PLC, si deve tener conto anche di questo.