Sysmac Studio Stupidity

[dott.cicala]

Chi riesce a spiegarmi questo ?

 

 

Con altri plc

 

 

lo stesso fatto con cx non accade!

[pcontini]

Ma in cx-p hai messo la divisione come in sysmac?

 

[dott.cicala]

CX è solo un esempio che però non ho riportato.

 

La riga sotto gira su un Siemens.

 

Il progetto gira su un NJ e devo leggere la posizione di un asse collegato in ethercaz il quale manda la pos in DINT e che devo dividere /10 per avere i mm.

 

In ogni caso, che senso ha quel risultato?

[dott.cicala]

Ecco come si comporta CX

 

 

[dott.cicala]

 

...E ancora in Sysmac Stu(p)dio

 

 

[max.riservo]

Il senso è semplice ed è intrinseco nel tipo di dato REAL ......

I REAL NON SONO PRECISI e non andrebbero usati quanto è richiesta la correttezza / precisione del dato.

Come fare ?

Semplice : usi un Doppio intero e formatti la visualizzazione con i decimali che ti servono.

 

P.S. - E' un comportamento 'normale' e non ascrivibile a OMRON / SIEMENS /SCHNEIDER / PC ..... (probabilmente potresti non avere la stessa casistica sui processori differenti).

 

[dott.cicala]

Ma che significa ?

 

Sopra hai gli esempi con cx e Siemens e il problema non c'è.

 

Sai darmi una spiegazione?

 

 

 

[max.riservo]

Real_Numbers

 

Leggi (è in inglese) la parte finale quando parla di 1/10 .....

 

[max.riservo]

Nel caso non fossi convinto : Matlab & FloatingPointNumbers

 

Nel link trovi CHIARAMENTE scritto (sempre in inglese) che il problema dei real risiede nel come i numeri vengono memorizzati in (implementazione IEEE754), che NON è un BUG di MatLab e che il problema esiste anche in C, Fortran .....

 

Non ti so spiegare il differente comportamento tra Omron e Siemens (magari tipo di dati diverso ? Single Vs. Double Float?) ma ti ho indicato il problema dei REAL.

[pcontini]

infatti se usi LREAL sei ok

[dott.cicala]

Grazie dei link.

 

Probabilmente non sono stato chiaro nella mia richiesta.

 

Già conoscevo le ragioni che comportano quel risultato

 

Ciò che invece mi irrita terribilmente è che nel CX di 20 anni fa, questo problema è stato considerato

 

 

e in sysmac invece NO....

 

 

 

 

 

[max.riservo]

Stefano, hai letto le mie risposte? Le hai capite ?

Hai letto la risposta di pcontini che ti suggerisce di usare lreal (non so cosa sia non usando Omron - ipotizzo long real / real double precision ) che ti da il risultato atteso ?

Hai capito che il problema risiede nella NON precisa conversione da int a real e che NON è un problema di Omron / Sysmac ?

 

[dott.cicala]

Caspita,  mi sa che non le hai lette tu le mie risposte o non le hai capite.

 

Lo so che se uso Lreal la conversione è corretta

 

ma ciò non toglie che se fai la conversione e guardate bene ciò che ho allegato,

 

con cx  la conversione int_to real non è affetta da quell'errore.

 

 

 

 

 

 

 

[max.riservo]

Bene, allora contatta la OMRON e segnala a loro il problema .....

 

[dott.cicala]

Il problema lo segnalo qui per chi dovesse trovarsi a "migrare" un vecchio progetto fatto con cx programmer, nel quale esista un fb in cui sia stata fatta la stessa conversione int_to_real senza problemi, la quale in  sysmac invece da un risultato diverso.

 

 

 

[Schwoch89]

Ciao a tutti,

sembra che il problema non sia tanto del Controllore, ma del monitoraggio di Sysmac Studio!

Ho provato infatti a controllare il risultato di una divisione tra REAL e il PLC non sbaglia.

4643/10 = 464.3 su PLC, 464.29999 sul monitoraggio di Sysmac Studio.

Non è quindi necessario utilizzare LREAL in quanto non è un problema di precisione

Allego lo screenshot sul mio programma di esempio.

Saluti!