Linearità analogiche

[acquaman]

Prova anche a vedere direttamente cosa leggi dalla scheda, a 4mA l'ingresso analogico deve darti 0 e salire mano a mano fino a 27648 a 20mA.

[pigroplc]

Ho dato una veloce lettura al documento del sensore e secondo me la mancanza di linearizzazione è dovuta ad una parametrizzazione della corsa parziale. La cosa è spiegata a pagina 8. Prova ad effettuare la procedura di calibrazione dello strumento.
Ricordati di fare un documento di regolazione del sensore per evitare che un manutentore in futuro diventi pazzo in caso di sostituzione del pezzo.

[acquaman]

11 ore fa, max.riservo ha scritto:

Devi collegare il tuo sensore sui pin Ix+ (il 2 del sensore) e Ix- (il 3 del sensore).

Il 3 lo devi portare anche allo 0v della macchina.

[max.riservo]

19 minuti fa, acquaman ha scritto:

Il 3 lo devi portare anche allo 0v della macchina.

Ovvio, come al pin 1 devi portare il +24V.

[Ghisla]

Ciao ragazzi, ho scoperto che il problema non è il sensore ma la macchina andando a 1 ciclo al secondo mi sballa un sacco la lettura.

Io mi azzero su un pezzo e andando a misurare lo stesso pezzo a velocità di ciclo mi trovo valori sballati.

Come potrei fare per avere una lettura più affidabile? a livello di programma

[batta]

La prima domanda che mi viene da porti è: ma non hai mai provato a vedere cosa legge l'ingresso analogico, muovendoa mano il magnete in varie posizioni note? Hai provato solo cosa leggi ad alta velocità?

 

Qualche post fa scrivevi:

Il 18/6/2020 alle 21:25 , Ghisla ha scritto:

La scheda è: 6es7134 6hb01 0da1

è configurata come 4-20 mA convertitore a 4 fili

Sei sicuro del codice? A me risulta che non esiste.

Potrebbe essere:

6ES7 134-6HB00-0DA1 (2 ingressi analogici U/I 2/4 fili per campionamenti veloci)
oppure:

6ES7 134-6HD01-0BA1 (4 ingressi analogici U/I 2 fili)

 

Dato che affermi che è configurata come 4 fili, mi viene da pensare alla prima ipotesi, che sarebbe la scelta corretta per misure veloci, come nel tuo caso.
Il tempo di ciclo di questa scheda dovrebbe essere di 125 microsecondi.
Bisogna però vedere come fai le letture: su interrupt? Con la normale scansione?

 

Ghisla!!!! Siamo alle solite! Eppure, non sei più un novellino del forum, dovresti avere imparato che, per avere risposte, prima di tutto devi fornire i dati!
Siamo impazziti per cercare di capire quali potessero essere le cause di una mancata linearità, e pare che si tratti, invece, di un problema di tutt'altra natura.
Devi dire, per filo e per segno, come funziona il tuo sistema, che prove hai fatto, come effettui le misure!

 

 

[Ghisla]

Scusami batta, mi sono dimenticato questa informazione.

La lettura la eseguo su una camma che viene attivata quando il master raggiunge la posizione di impostazione della camma.

Come si attiva la camma eseguo la scalatura e la lettura del valore ricevuto dall'analogica

La scheda è la prima che hai citato.

 

 

[batta]

Ancora non dai informazioni fondamentali: la lettura viene effettuata in movimento o da fermo?
Nel caso venga effettuata da fermo, hai gestito un piccolo ritardo (es. 10-20 ms) in modo da essere sicuro che non stai leggendo un valore analogico non ancora aggiornato?
Se effettui la misura in movimento, a che velocità si muove il pezzo? E la camma che comanda la lettura, viene gestita con un normale ingresso nel normale ciclo del plc (quindi risente dei ritardi della scansione, da sommare a quelli dell'ingresso analogico), o viene lanciato un interrupt?

 

"Per filo e per segno" significa "in modo molto dettagliato".
Penso ti renderai conto che non hai certo descritto "in modo dettagliato" come stai gestendo questa misura, ma hai aggiunto una sola informazione.

Dai, non avrai mica paura di consumare la tastiera? 😉

 

[Ghisla]

La lettura, come dicevo viene effettuata su una camma che va da 355° a 5° e in quell'angolo la testata è tutta bassa e ferma. ovviamente il tutto avviene molto velocemente.  Il pezzo sono delle cartucce con dentro della polvere, quando scendo a misurare l'altezza della polvere le cartucce sono ferme.

Per quanto riguarda la camma uso le camme Siemens MC_outputcam, sul fronte di camma attiva eseguo la lettura, il tutto in un FC richiamato da OB1.

Quando lancio il comando di azzeramento, la macchina esegue un colpo epr poi fermarsi. In quel colpo eseguo l'azzeramento sul pezzo, quindi se io faccio ripassare il pezzo sotto il controllo dovrei leggere 0.00mm in quanto è il pezzo su cui mi sono azzerato. Ora, il problema non so se è la velocità oppure sono i  ritardi della CPU 

 

Spero di aver dato tutte le informazioni necessarie

 

Grazie

 

[batta]

16 ore fa, Ghisla ha scritto:

La lettura, come dicevo viene effettuata su una camma che va da 355° a 5° e in quell'angolo la testata è tutta bassa e ferma.

Ma tu lanci la misura appena raggiungi i 355°?
La velocità della macchina è di un ciclo al secondo, giusto?
Quindi, se hai a disposizione 10° su 360° per effettuare la misura, in tempo significa che hai 27,78 ms.
Hai provato cosa succede se, anziché leggere appena raggiunti i 355°, leggi, per esempio, a 0°, ovvero quando il pezzo dovrebbe essere fermo da quasi 14 ms, e la lettura dell'ingresso analogico aggiornata?
I valori analogici, con che sintassi li leggi?
Non puoi pubblicare qualche pezzo significativo del codice?
In quanti ms gira la scansione del PLC?

 

16 ore fa, Ghisla ha scritto:

quando scendo a misurare l'altezza della polvere le cartucce sono ferme.

Io non ho ancora capito come viene effettuata la misura.

Uno schemino? Un breve filmato?

[Livio Orsini]

19 minuti fa, batta ha scritto:

...per effettuare la misura, in tempo significa che hai 27,78 ms.

 

Io non conoco i tempi di conversione A/D di questa scheda, ma ricordo che quelle del 300 e del 200 non erano certamente trascurabili.

Con 27.78 ms di tempo a disposizione credo che bisogna essere ben sicuri di non aggiungere ritardi.

[Ghisla]

Buongiorno ragazzi

 

Il ciclo macchina è 1 colpo al secondo .

Ho provato a modificare la camma, per esempio 0° 10° ,350-5 ecc.

Il ciclo di scansione della CPU è sempre sui 10ms.

Come funziona la misura:

C'è una testata che sale e scende movimentata da un asse master, quando la macchina è in basso, ci sono quei 10° in cui la macchina rimane ferma. In quei 10 gradi c'è un diciamo tampone che entra nella cartuccia e si va ad appoggiare sulla polvere da sparo. Appoggiandosi sulla polvere viene movimentato il magnete che scorre sul sensore analogico effettuando cosi la misura.

 

Vi posto il codice:

Molto semplicemente, quando rilevo il fronte positivo della camma, vado ad azzerare se ho una richiesta di azzeramento altrimenti eseguo la conversione e salvo l'ultimo valore letto che sarà il valore con cui deciderò se il pezzo è buono o scarto.

 

Nella conversione,  il parametro P4_9 è il fattore K mentre il parametro P5 sarebbe un offset applicato che è attualmente sempre a 0

Modificato: 22 giugno 2020 da Ghisla

[batta]

58 minuti fa, Livio Orsini ha scritto:

Io non conoco i tempi di conversione A/D di questa scheda, ma ricordo che quelle del 300 e del 200 non erano certamente trascurabili.

Con 27.78 ms di tempo a disposizione credo che bisogna essere ben sicuri di non aggiungere ritardi.

Ho già chiesto a Ghisla di fornire il codice corretto, dato che quello che scritto ha in un precedente post risulta inesistente. Se è il modulo "HS", dovrebbe leggere entrambi i canali, mi pare, in 125 microsecondi. Per i moduli ET200SP "standard", la lettura e la conversione di tutti i canali richiederebbe invece alcune decine di millisecondi.

 

53 minuti fa, Ghisla ha scritto:

Ho provato a modificare la camma, per esempio 0° 10° ,350-5 ecc.

Io non intendo che devi spostare tutta la camma, intendo che, se il tuo sistema è fermo a 355°, anziché effettuare la lettura a 355° effettui la lettura, per esempio, a 360°, in modo da essere sicuro che i valori che leggerai dagli ingressi analogici saranno aggiornati.

 

52 minuti fa, Ghisla ha scritto:

Molto semplicemente, quando rilevo il fronte positivo della camma, vado ad azzerare se ho una richiesta di azzeramento altrimenti eseguo la conversione e salvo l'ultimo valore letto che sarà il valore con cui deciderò se il pezzo è buono o scarto.

Domanda: "E1_9" è il canale analogico? Cioè, qualcosa tipo: L IWxxx?

Leggendolo in questo modo, vai a leggere l'immagine, ovvero lo stato ad inizio scansione del plc.
Insomma, rischi di leggere un dato vecchio.
Dovresti fare una lettura immediata, scrivendo:
L IWxxx:P
Puoi scrivere anche come si faceva in Simatic Manager:
L PEWxxx

Il TIA poi corregge in automatico.

 

Inoltre, con un tempo di scansione di 10 ms e meno di 30 ms per l'acquisizione, non è che hai poi tanto margine.
Perché non lanci un interrupt?

 

Da non trascurare poi eventuali ritardi del sensore. Ora non ho voglia di rileggermi le caratteristiche tecniche, ma da qualche parte ci deve essere scritto.
Non sarebbe male poi controllare il segnale con un oscilloscopio. In questo modo, ti toglieresti ogni dubbio sulla stabilità del segnale e su quanto tempo il segnale rimane stabile. È in questo istante che tu dovrai fare la lettura.

 

Un'altra domanda: io ho usato molto AWL, e sono ancora affezionato a questo linguaggio, ma è tenuto sempre meno in considerazione anche dalla stessa Siemens. Io mi sono imposto di non utilizzarlo più, salvo casi molto particolari.
Perché stai usando AWL quando, per queste cose, oltre a quanto scritto sopra, il testo strutturato risulta molto più pratico?
 

[Ghisla]

La scheda di lettura è una scheda HF quindi veloce.

Ho provato ad eseguire la lettura anche oltre i 355° ma non ho ottenuto risultati migliori.

E1_9 è il canale analogico, non sta leggendo dalla periferia, quindi qui provo a cambiare andando a leggere direttamente dalla periferia.

Ho provato a lanciare un interrupt ma ho notato che il tempo ciclo di scansione PLC è aumentato enormemente, quasi raddoppiato (probabilmente è stato settato il tempo ciclo interrupt in modo errato??)

 

Per quanto riguarda AWL, normalmente per eseguire i cicli di stazione utilizzo ancora AWL, ma se il problema potrebbe risedere qui non ho problemi a riscrivere tutto o per lo meno questa stazione in SCL.

 

Il sensore ha un intervallo di campionamento di 1ms leggendo da manuale, non so se è quello che intende Batta.

 

Modificato: 22 giugno 2020 da Ghisla

[Cialtrone]

Ma

L 100 alla settima riga della conversione, non dovrebbe essere L L#100?

 

 

[batta]

1 ora fa, Ghisla ha scritto:

La scheda di lettura è una scheda HF quindi veloce.

HF e HS non sono la stessa cosa. Anche la scheda "HF" ha un'acquisizione piuttosto veloce, ma non tanto quanto la scheda "HS".
Perché non scrivi il codice completo corretto?

 

1 ora fa, Ghisla ha scritto:

Ho provato a lanciare un interrupt ma ho notato che il tempo ciclo di scansione PLC è aumentato enormemente, quasi raddoppiato (probabilmente è stato settato il tempo ciclo interrupt in modo errato??)

In che senso hai lanciato un interrupt? Hai creato un OB a tempo? Con che tempo?
Io intendevo lanciare un interrupt su evento, e questo influirebbe in maniera insignificante sul tempo ciclo.

 

1 ora fa, Ghisla ha scritto:

Per quanto riguarda AWL, normalmente per eseguire i cicli di stazione utilizzo ancora AWL, ma se il problema potrebbe risedere qui non ho problemi a riscrivere tutto o per lo meno questa stazione in SCL.

No, il problema non è certo in poche righe di AWL piuttosto che di testo strutturato.
È solo che, per quanto io sia ancora affezionato all'AWL, trovo poco sensato sviluppare nuovo codice usando un linguaggio che la stessa Siemens tiene sempre meno in considerazione.
Se, a questa considerazione, si aggiunge che le stesse operazioni scritte in strutturato sarebbero di più facile scrittura ed interpretazione, ecco che proprio non capisco la scelta di scrivere in AWL.

Il mondo intero è in continua evoluzione, non possiamo rimanere radicati su posizioni superate.
Una cosa è se si lavora su un progetto originariamente scritto in AWL (sarebbe assurdo e sbagliato pretendere di convertire tutto in strutturato), altra cosa è scrivere nuovo codice.
Oggi, scrivere nuovo codice in AWL su una CPU 1500, è una scelta anacronistica.

 

Altra cosa: scorrendo velocemente tutto il thread, non ho trovato il codice della CPU che stai usando, né quali oggetti tecnologici tu stia usando né, tantomeno, come questi oggetti tecnologici vengano usati. Anche il tempo impostato nell'elaborazione di MC-Servo sarebbe una utile indicazione.

 

Un consiglio: perché non dai dei nomi significativi alle variabili? Tutta la programmazione oramai è orientata all'uso simbolico, e tu, come simboli, metti dei nomi che sembrano indirizzi.

 

 

 

 

 

Modificato: 22 giugno 2020 da batta

[batta]

Mi pare poi di capire che leggi lo stato della camma dal'uscita "CamOutput" della funzione "MC_OutputCam", la quale funzione è inserita un un blocco di programma che cicla con OB1 (quindi, ogni circa 10 ms, nel tuo caso).

L'oggetto tecnologico "TO_OutputCam" nasce per andare a pilotare direttamente uscite digitali (ci sono anche i parametri per definire il ritardo dell'attuatore da OFF a ON e da ON a OFF, in modo da mantenere costante l'azione anche cambiando velocità).

Purtroppo, mi pare non si possa lanciare un interrupt da questo oggetto tecnologico. Leggendo però lo stato dell'uscita come scritto sopra, hai ritardi notevoli.

Potresti però inserire un OB "MC-PostServo" (che viene lanciato in automatico dal sistema subito dopo "MC-Servo"), e valutare la posizione dell'asse master con delle semplici comparazioni, senza tirare in ballo funzioni di camma.

Ovviamente, per non appesantire il programma, in MC-PostServo dovrai programmare in modo da rendere il più leggera possibile l'esecuzione di questo blocco, elaborando in continuo solo le cose indispensabili, ed eseguendo i calcoli solo quando si verifica l'evento.

Con un MC-Servo impostato a 4 ms, dovresti non rallentare troppo il ciclo CPU, anche nel caso di CPU poco performanti (compatibilmente col numero di assi da gestire, che noi non conosciamo, come non conosciamo la cpu utilizzata, data l'atavica riluttanza di Ghisla a fornire tutti i dati).

[batta]

51 minuti fa, Cialtrone ha scritto:

L 100 alla settima riga della conversione, non dovrebbe essere L L#100?

Sarebbe concettualmente più corretto ma, in questo caso, non cambia nulla.
Diverso sarebbe se fosse -100, perché verrebbe messo a true il bit 15 anziché il bit 31 dell'accumulatore.

Personalmente, anche se non crea problemi, se fosse un esercizio scolastico e se io fossi un insegnante, lo considererei un errore.

[Cialtrone]

Grazie Batta

 

 

[Ghisla]

Ciao

Sto usando una CPU 1515T-2PN, mentre il codice della scheda analogica è questo: 6ES7134-6HB00-0DA1

L'ob MC servo utilizzato è impostato a 4ms.

Per quanto riguarda la programmazione purtroppo devo attenermi alle regole dell'azienda.

Oggetti tecnologici sto utilizzando 1 positioning axis per il master e 5 syncronous axis per gli slave, oltre a 1 outputcam utilizzata per questo controllo analogico.

Scusatemi per le informazioni ma non sapendo come risolvere il problema non so nemmeno quali informazioni potrebbero esservi utili, ma senza alcun problema vi fornisco tutte quelle che vi servono.

 

Grazie mille

 

 

 

 

[batta]

54 minuti fa, Ghisla ha scritto:

Sto usando una CPU 1515T-2PN

La 1515T non è velocissima (ha più memoria, ma come prestazioni è come la 1511T), ma per 6 assi e una camma non dovresti avere problemi con MC-Servo a 4 ms.

Non mi dici se utilizzi la camma anche per comandare attuatori, o solamente per generare l'uscita (o le uscite, non si sa...) per lanciare le letture.
Se non hai attuatori da pilotare, non vedo a cosa ti serva la camma.
Se hai attuatori da pilotare, ti conviene usare "MC_OutputCam" solo per impostare la camma (operazione quindi da fare tranquillamente nel ciclo dell'OB1), mentre per rilevare il momento in cui eseguire la misura (o le misure? Quante?), come ho già scritto, io farei delle semplici comparazioni all'interno di MC-PostServo, che viene lanciato subito dopo MC-Servo, e che cicla quindi anche lui in 4 ms. E, sempre all'interno di MC-PostServo, farei i calcoli che ti servono.
Una manciata di comparazioni ed una manciata di operazioni, pure se in virgola mobile, non dovrebbero portarti via più di qualche decina di microsecondi.
Per i calcoli poi, perché non fai una FC alla quale passare i parametri? Ne guadagnerebbe la leggibilità del codice, e anche la praticità, dato che richiameresti sempre la stessa FC per diverse misure. 

 

1 ora fa, Ghisla ha scritto:

Per quanto riguarda la programmazione purtroppo devo attenermi alle regole dell'azienda.

Mi vuoi dire che quei nomi assurdi assegnati alle variabili sono imposti dalla ditta? O che ti impongono di usare AWL? Demenziale!
Questo significa aver paura di ogni cambiamento. Ma rifiutare i cambiamenti, significa rimanere ancorati al passato, significa non seguire l'evoluzione del mondo dell'automazione.

 

Mi rimane ancora da capire come sono usate le 16 analogiche di cui si parlava all'inizio. Su tutte hai questo problema di lettura?

[Ghisla]

Ciao

La camma la uso solamente per eseguire la lettura (pensavo fosse più precisa utilizzare la camma piuttosto che una comparazione data l'elevata velocità, pensavo le camme fossero dinamiche).

Per le analogiche ne ho 16 ma una in particolare è la più critica perché c'è una tolleranza di 2 decimi quindi potrei usare il metodo da te descritto solamente per questa analogica in particolare.

Purtroppo la mia azienda è ancora ancorata all'awl spero che cambiamo presto ma temo passa ancora un po' di tempo. Comunque tutto il codice che ho postato prima io avevo già provato a inserirlo nel post servo, ma il risultato ottenuto non cambiava da lasciarlo inserito nell'ob1. Ho sbagliato qualcosa?

 

Grazie

 

Modificato: 22 giugno 2020 da Ghisla

[batta]

Manca sempre un'analisi del segnale con oscilloscopio.

Se non sappiamo se il segnale rimane stabile al valore da rilevare per almeno 10 ms, inutile continuare a cercare soluzioni più o meno fantasiose.

L'oscilloscopio è uno strumento che, nel nostro mestiere, non dovrebbe mai mancare. Per l'analisi di questo tipo di segnali, vanno benissimo quegli oscilloscopi tascabili che si trovano per una cinquantina di euro.

[batta]

5 ore fa, Ghisla ha scritto:

Comunque tutto il codice che ho postato prima io avevo già provato a inserirlo nel post servo, ma il risultato ottenuto non cambiava da lasciarlo inserito nell'ob1. Ho sbagliato qualcosa?

Non saprei dirti se hai sbagliato o meno. 

Se "MC_OutputCam" la richiami sempre sotto OB1, mettendo i calcoli in MC-PostServo probabilmente peggiori la situazione.

[Ghisla]

Esatto, così è stato