max.riservo Inserita: 26 febbraio Segnala Share Inserita: 26 febbraio Altra soluzione (io uso M340 ... spero che ci siano istruzioni analoghe in Codesys): 1) - DWord = MB_ReceiveBuffer _01[0] 2) - Dword = Dword * 65536 + MB_ReceiveBuffer _01[1] 3) - Real = Dword_To_Real(DWord) Io utilizzo una soluzione (a mio avviso) più elegante : - costruisco una struttura di dati che rispetta la struttura dei registri che ricevo, che si sovrappone al buffer di ricezione (servono variabili allocate), quello che ricevo è già nel giusto formato. Link al commento Condividi su altri siti More sharing options...
Water Inserita: 27 febbraio Autore Segnala Share Inserita: 27 febbraio 10 ore fa, NoNickName ha scritto: ti faccio il primo 17251 54936 = 0x4363 0xD698 La tua dword è 0x4363d698 4 3 6 3 D 6 9 8 0 1 0 0 0 0 1 1 0 1 1 0 0 0 1 1 1 1 0 1 0 1 1 0 1 0 0 1 1 0 0 0 0 10000110 11000111101011010011000 Il primo bit è il segno, quindi positivo. i successivi otto bit sono l'esponente Il resto è la mantissa L'esponente è a complemento 127. 10000110 = 134 - 127 = 7 La mantissa è 1.11000111101011010011000 binario, cioè 1.7799863815307617 decimale Il risultato è 2^7 * 1.7799863815307617 = 227,838 che è la tua tensione della fase 1 Analogamente per le altre. IEEE 754 floating point standard. La seconda è 0x43653e10 e la tensione è 229.242 La terza è 0x4365c270 e la tensione è 229.76 cavoli sono imbarazzato! 🥶 non mi era mai capitato di fare questa conversione e non ci sarei mai arrivato!! stupidamente davo per scontato di leggere direttamente il dato, ti ringrazio molto per l'esauriente spiegazione e soluzione! 😱 👍👍 Link al commento Condividi su altri siti More sharing options...
Water Inserita: 27 febbraio Autore Segnala Share Inserita: 27 febbraio 10 ore fa, max.riservo ha scritto: Altra soluzione (io uso M340 ... spero che ci siano istruzioni analoghe in Codesys): 1) - DWord = MB_ReceiveBuffer _01[0] 2) - Dword = Dword * 65536 + MB_ReceiveBuffer _01[1] 3) - Real = Dword_To_Real(DWord) Io utilizzo una soluzione (a mio avviso) più elegante : - costruisco una struttura di dati che rispetta la struttura dei registri che ricevo, che si sovrappone al buffer di ricezione (servono variabili allocate), quello che ricevo è già nel giusto formato. grazie Max!! come detto a NoNickName non mi ero mai "scontrato" con questa conversione, nel mio campo e da sempre, i valori che leggo in Modbus sono diretti e ci stanno comodamnente in una word, questa cosa dell'inversione e relativa conversione è una cosa nuova e vi ringrazio di avermi aiutato!👍👍👍 è vero cercando si trova la risposta a tutto ma bisogna saper prendere la giusta "autostrada", grazie ancora a tutti per il prezioso aiuto! 👍👍👍 Link al commento Condividi su altri siti More sharing options...
NoNickName Inserita: 27 febbraio Segnala Share Inserita: 27 febbraio 11 ore fa, max.riservo ha scritto: Io utilizzo una soluzione (a mio avviso) più elegante : - costruisco una struttura di dati che rispetta la struttura dei registri che ricevo, che si sovrappone al buffer di ricezione (servono variabili allocate), quello che ricevo è già nel giusto formato. A me non mi piace. Funziona solo in ambito PLC e C/C++ Nei linguaggi di programmazione moderni le aree di memoria potrebbero non essere adiacenti. Link al commento Condividi su altri siti More sharing options...
max.riservo Inserita: 27 febbraio Segnala Share Inserita: 27 febbraio Nel mondo PLC nel quale io opero (SCH) la tecnica della sovrapposizione della memoria funziona da sempre (diciamo da almeno 30 anni così non mi allargo troppo) ... Leggo dati in modbus RTU e/o TCP/IP tramite Vb6 (Os XP e successivi) e Access (Os Win10) utilizzando strutture di dati e, al momento, non ho riscontrato problemi di memoria non allocata consecutivamente. Non utilizzo l'ecosistema dot.net dove la memoria potrebbe essere gestite diversamente ... 3 ore fa, NoNickName ha scritto: A me non mi piace. Funziona solo in ambito PLC e C/C++ Nei linguaggi di programmazione moderni le aree di memoria potrebbero non essere adiacenti. Se sei a conoscenza di SW (ambienti di sviluppo) tramite i quali non funziona, elencali : magari mi eviti il mal di pancia di capire dove sbaglio nell'ipotesi che dovessi usarli. Link al commento Condividi su altri siti More sharing options...
NoNickName Inserita: 27 febbraio Segnala Share Inserita: 27 febbraio (modificato) 1 ora fa, max.riservo ha scritto: Se sei a conoscenza di SW (ambienti di sviluppo) tramite i quali non funziona, elencali : magari mi eviti il mal di pancia di capire dove sbaglio nell'ipotesi che dovessi usarli. Dove la memoria è gestita. Tu hai menzionato VB6 e sono sorpreso che tu non abbia mai avuto problemi. Certamente in .net, python o java anche se in linea di massima potrebbe funzionare, è un rischio. Modificato: 27 febbraio da NoNickName Link al commento Condividi su altri siti More sharing options...
Markeso Inserita: 1 marzo Segnala Share Inserita: 1 marzo Esistono librerie progettate specificamente per lavorare con i dati del PLC, come PyModbus o Modbus-TK. Queste librerie possono aiutare a evitare problemi di memoria non indirizzata e fornire prestazioni più affidabili. Link al commento Condividi su altri siti More sharing options...
Water Inserita: 7 marzo Autore Segnala Share Inserita: 7 marzo Il 26/2/2024 alle 20:40 , NoNickName ha scritto: ti faccio il primo 17251 54936 = 0x4363 0xD698 La tua dword è 0x4363d698 4 3 6 3 D 6 9 8 0 1 0 0 0 0 1 1 0 1 1 0 0 0 1 1 1 1 0 1 0 1 1 0 1 0 0 1 1 0 0 0 0 10000110 11000111101011010011000 Il primo bit è il segno, quindi positivo. i successivi otto bit sono l'esponente Il resto è la mantissa L'esponente è a complemento 127. 10000110 = 134 - 127 = 7 La mantissa è 1.11000111101011010011000 binario, cioè 1.7799863815307617 decimale Il risultato è 2^7 * 1.7799863815307617 = 227,838 che è la tua tensione della fase 1 premesso che ti ringrazio ancora per la descrizione, non capisco un passaggio. dalla mantissa di cui sopra 11000111101011010011000 (6543000 decimale) come arrivi a 1.7799863815307617? grazie Link al commento Condividi su altri siti More sharing options...
NoNickName Inserita: 7 marzo Segnala Share Inserita: 7 marzo 15 minuti fa, Water ha scritto: premesso che ti ringrazio ancora per la descrizione, non capisco un passaggio. dalla mantissa di cui sopra 11000111101011010011000 (6543000 decimale) come arrivi a 1.7799863815307617? grazie Devi moltiplicare ogni bit per potenze decrescenti di 2. Ad esempio 1011 = 1*2^-1+0*2^-2+1*2^-3+1*2^-4 = 1/2 + 1/8 + 1/16 = 0.6875 Nel tuo caso vedi sotto: 0.7799863... + 1 = 1.7799863.... Link al commento Condividi su altri siti More sharing options...
Water Inserita: 7 marzo Autore Segnala Share Inserita: 7 marzo Cavoli ti ringrazio molto! 👍 non essendomi mai scontrato con questo problema proprio non ne avevo la più pallida idea, colpa anche delle lacune che in questo campo ahimè non è difficile avere 😢 prima di scrivere avevo cercato in rete e mai avevo visto questa soluzione, certo che questa è roba da informatici puri!! 😁 è anche vero che ci sono PLC o HMI che lo fanno in automatico ma non quello che uso io (TM241), le variabili Modbus le leggo sempre correttamente e nel mio campo (gruppi di pressurizzazione) mai avuto problemi, nel mio caso i decimali dopo la virgola servono più per capire la tendenza piuttosto che un vero utilizzo, che dire ho imparato qualcosa! .. un grazie a te e a tutti per le preziose risposte ciao Link al commento Condividi su altri siti More sharing options...
Messaggi consigliati
Crea un account o accedi per commentare
Devi essere un utente per poter lasciare un commento
Crea un account
Registrati per un nuovo account nella nostra comunità. è facile!
Registra un nuovo accountAccedi
Hai già un account? Accedi qui.
Accedi ora