Lettura variabili ritenitive da Python ritornano valore “0”

[Stefano]

Stò sviluppando una libreria Python per  interagire in maniera semplice con un PLC SlimLine. Tramite un semplice parser ricavo le variabili definite nel PLC dal file .plcprj, calcolo numero di registri e tipo di dato (REAL/INT/DINT/UINT…) e quindi riesco ad avere una struttura dati (dizionario) in Python che mi permettte di accedere alle variabili del PLC usando lo stesso nome e senza dovermi preoccupare dell’indirizzo nel PLC o via modbus.

Sta iniziando a funzionare, ora però sto avendo problemi con le letture dei registri relativi alle variabili ritenitive (dal 2048 in su).

Ad esempio, provando a leggere un array contentente due REAL definito in %MD100.2088 (ARRAY[0..1] OF REAL := [19.5,17.5]), calcolo il relativo indirizzo modbus: 41043 ed effettuo la lettura (read_holding_registers) come al solito ma i registri che mi ritorna sono: [0, 0, 0, 0]. Ho lo stesso comportamento in caso di variabili semplici tipo UDINT (non array).

Mi sono perso qualcosa?

[Sergio Bertana]

Complimenti hai fatto un ottimo lavoro…

Ora venendo al tuo problema a parte precisare che per accedere alla variabile MD100.2088 l’indirizzo Modbus sarà 40000+(2088/2) quindi 41044. Ti ricordo che Modbus ha offset 1 e quindi dipende dal tuo driver se definire indirizzo 41043, 41044 o 41045, puoi comunque fare delle prove. E dovendo acquisire 2 variabili REAL giustamente devi leggere con il comando Read Holding Register 4 registri.

Ma a parte la precisazione sull’indirizzo Modbus avendo letto 4 registri non dovresti avere dati a “0”. Ma una domanda stupida il programma su LogicLab è in esecuzione? Se metti in debug su LogicLab le variabili vedi i valori che hai definito?

Attenzione volendo utilizzare variabili in backup e quindi fare in modo che alla successiva accensione mantengano il valore allo spegnimento non devi definire un Init Value, perchè altrimenti all’avvio il programma forzerà le variabili sempre al valore definito.

I valori REAL sono nel formato IEE754 su 32 bits e come tutte le variabili a 32 bits leggendole o scrivendole da Modbus visto che si accedono a 16 bits potresti avere un problema di endiannes cioè LSWe MSW scambiate di ordine.

[Stefano]

Grazie, appena arrivo ad un punto sensato lo pubblico che magari serve a qualcun’altro;)

Il discorso offset lo avevo considerato e infatti ero arrivato all’indirizzo 41043. La rappresentazione grezza che restituisce Python è un array che stampato diventa: [0, 0, 0, 0] è indicativa e corrisponde a 4 registri settati interamente a zero. Per esempio

%MD100.32 contiene un REAL raggiungibile da Python al registro 40015 [50368, 16796] [0xC4C0, 0x419C] e una volta convertito diventa 19.5960693359375
%MD100.56 contiente un DINT raggiungibile da Python al registro 40027 [918, 0]  [0x0396, 0x0000] e una volta convertito diventa 918.

%MD100.2688 contiente un UDINT raggiungibile da Python al registro 41343 [0, 0] e una volta convertito diventa 0: peccato che il vero valore sarebbe 3001 come riesco peraltro a leggere tramite pagina web usando:

<span style=”color: #007200; white-space: pre;”><!–[‘%u’, UDINT, 2288]–>”</span>

Non capisco la domanda relativa  a LogicLab: l’interazione è tra il PLC fisico e il codice Python su PC, LogicLab è spento.

[Sergio Bertana]

Quindi come vedi i valori sono ritornati in little endian, il valore REAL è in realtà rappresentato in esadecimale con il valore 0x419CC4C0 che convertito con un convertitore on line dà proprio 19.5960693359375.

Per quanto riguarda la variabile 100.2688 vedo una incongruenza con la visualizzazione in pagina web dove hai definito <!–[‘%u’, UDINT, 2288]–> e non <!–[‘%u’, UDINT, 2688]–>.

Riguardo a LogicLab ti suggerivo di mettere in debug le variabili in modo da verificarne il loro relativo valore ed eventualmente modificarlo run time per verificare che il tuo programma lo acquisisca correttamente (Screenshot).

[Stefano]

Colpito e affondato!

Avevo fatto un pasticcio con “git” e non mi ero accorto che si erano disallineate le versioni del file plcprj.

E anche leggendo la risposta ho dovuto tornare indietro due volte per vedere che i numeri erano diversi!

Nel mentre ho scoperto che il mio parser necessita di una revisione, spero di farmi vivo a breve con una versione beta per chi la volesse provare!

[Sergio Bertana]

Scusa se mi viene in mente solo ora di suggerirtelo, ma per risalire all’indirizzo delle variabili solitamente non ci si riferisce al file di progetto, ma al file simboli.

Il file simboli (Lo trovi nella cartella Build) ha lo stesso nome del progetto ed estensione sym. Il vantaggio potrebbe essere che è un file in formato XML e magari più gestibili da librerie Phyton.

[Autore]

Post