[Sergio Bertana]

I sistemi Cortex M7 sono basati su di un sistema operativo real time sviluppato da noi e non possono eseguire applicativi.

Se vuoi utilizzare Node-RED sui nostri prodotti devi scegliere il modulo CPU MPS055 basato su Raspberry. nella zona knowledge trovi informazioni sulla installazione ed un esempio di utilizzo.

[Sergio Bertana]

Per aggiornare i sistemi CortexM7 ad XUnified devi scaricare il PCK051.

[Sergio Bertana]

Con la versione XUnified abbiamo risolto anche alcuni BUGs presenti su XTarget_12, il primo riguarda la risposta alle richieste GET sulle pagine dinamiche (Pagine con estensione htm) nella versione XTarget_12 venivano ritornate le informazioni di Cache-Control.

Cache-Control: max-age=300
ETag: "1612163484:149"

Questo forzava il caching della pagina da parte del browser e quindi non veniva più richiesta al server, per sopperire al problema nella richiesta get veniva aggiunto alla pagina un numero random per simulare richieste diverse.

Per quanto riguarda le richieste POST, nell’XTarget_12 viene eseguito un controllo case sensitive sull’header e questo a volte genera problemi di decodifica. Nell’XUnified il controllo ora e case insensitive.

Quindi per risolvere i tuoi problemi ti consiglio di eseguire l’upgrade del sistema a XUnified.

[Sergio Bertana]

Buona l’idea di abbandonare XMLHttpRequest e di utilizzare le più moderne API Fetch, ho quindi provveduto a modificare gli esempi riportati nella knowledge.

Se scarichi l’esempio citato nell’articolo troverai una pagina gestita con l’API Fetch in cui si aggiornano in AJAX i valori con richieste in GET e si impostano valori in POST.

[Sergio Bertana]

Ho provato a scrivere un esempio del programma…

VAR
    i : UDINT; (* Auxiliary variable *)
    IDx : USINT; (* Index *)
    ArrayA : ARRAY[0..143] OF BYTE; (* Array appoggio lettura Modbus *)
    ArrayB : ARRAY[0..36] OF REAL; (* Array appoggio valori acquisiti *)
END_VAR

    // Simulo i valori acquisiti dallo strumento.

    i:=Sysmemmove(ADR(ArrayA[0]), ADR(16#42C81234), 4); //Carico 100.036
    i:=Sysmemmove(ADR(ArrayA[4]), ADR(16#44022BC7), 4); //Carico 520,684

    i:=Sysmemmove(ADR(ArrayA[140]), ADR(16#4733B0D8), 4); //Carico 46000,844

    // Eseguo la conversione in REAL.

    FOR IDx:=0 TO 35 DO
        i:=BEArrayToVar(REAL_TYPE, ADR(ArrayB[IDx]), ADR(ArrayA[IDx*4]));
    END_FOR;

Per il calcolo dei valori in esadecimale ho utilizzato un convertitore IEE754 on line.

[Sergio Bertana]

Settando il valore di Coefficent a “0” l’uscita Average assume valore di Value.

Dopodichè settando il valore di Coefficent corretto si riprende ad eseguire la media.

[Sergio Bertana]

Da quello che dici c’è un problema di endianness sui dati acquisiti via Modbus, è strano che tu debba usare la funzione BEArrayToVar, perchè questo vuol dire che è scambiato l’endianness anche nei singoli registri oltre che tra i registri. Mentre il protocollo Modbus indica chiaramente l’endianness dei registri (Dai una occhiata a questo post).

Bene leggere i 36*2 registri consecutivi (Se gli altri 4 non sono molto distanti come indirizzi puoi anche leggerne di piu eliminando i registri vuoti nel mezzo). Poi come dici tu tutti i registri letti saranno appoggiati in ArrayA, di tipo BYTE lungo 144 bytes. E dovrai creare l’ArrayB da 36 REAL per contenere il valore convertito.

Dovrai poi eseguire 36 volte la funzione BEArrayToVar, indicando come Type un REAL e passando come Source l’indirizzo di ArrayA e come Destination l’indirizzo di ArrayB opportunamente offsettati.

[Sergio Bertana]

Non mi dici se i valori sono in registri consecutivi oppure no. Se  sono in registri consecutivi puoi eseguire un unico comando di lettura di tutti i valori (40 valori float corrispondono a 80 registri modbus, 160 bytes). Il comando Modbus può acquisire fino a 250 bytes.

Se invece sono allocati ad indirizzi molto distanti tra di loro occorre per forza eseguire più comandi di lettura.

Ora assumendo che per sistemare l’endiannes dei dati occorra eseguire la funzione VarSwap su ogni valore letto, ti consiglio di appoggiare i valori letti in variabili di memoria di appoggio e poi eseguire lo swap su un’altra variabile che sarà quella che effettivamente utilizzerai.

Se utilizzi il FB ACModbus e vuoi ottimizzare il programma puoi appoggiare il valore letto da ogni comando sempre nella stessa variabile, poi con l’uscita COk, attivo per un loop se comando Modbus eseguito correttamente, sincronizzandosi con AIDx puoi eseguire lo swap del valore letto nella tua variabile.

[Sergio Bertana]

Il mouse USB è supportato da tutti i terminali.

Utilizzando im mouse è possibile muovere il cursore sullo schermo ed agendo sul pulsante del mouse effettuare il click sull’oggetto puntato proprio come toccandolo sullo schermo con il dito.

[Sergio Bertana]

Un pò di ordine tra le idee… e una occhiata a questo post potrebbe essere utile.

I dati in lettura e scrittura sul meter sono sempre in float 32 bit IEE754, che in IEC61131 si identificano con il formato REAL. Quindi con la funzione VarSwap non fai nessuna conversione. Usi questa funzione perchè essendo il valore espresso su 32 bits si utilizzano 2 registri Modbus per la lettura/scrittura e siccome il protocollo Modbus non specifica l’endiannes sui valori multiregistro ognuno fà come vuole.

La funzione VarSwap sistema proprio l’endiannes dei dati quindi puoi usarla sia per convertire i dati in lettura che quelli in scrittura. Quindi per scrivere un valore sul meter appoggi il dato REAL nel buffer del FB ModbusMaster (Che definirei di tipo DWORD) utilizzando la funzione VarSwap.

[Sergio Bertana]

Si passa per un puntatore per “fregare” il compilatore, se assegnassi il valore 16#7F8FFFFF (Decimale 2.140.143.615) ad una variabile REAL essa assumerebbe il valore 16#4EFF2000 (Come puoi verificare con un convertitore come questo).

Per poter impostare un valore esadecimale devo avere una variabile di tipo DWORD, nel linguaggio ST non c’è il costrutto UNION che permette di unire variabili di tipo diverso, quindi l’unico escamotage che ho trovato è utilizzare un puntatore.

Ma magari nel forum c’è qualcuno che ha una idea migliore.

[Sergio Bertana]

Come vedi nello screenshot devi configurare un nuovo dispositivo MODBUS RTU (Hex Addressing), configurato sulla porta seriale RS485 con i parametri di comunicazione 2400, n, 8, 1 e nodo Modbus 1.

Siccome devi gestire variabili REAL a 32 bits devi sincronizzare l’endiannes sull’acquisizione, attiva con il tasto Data Conversion e metti il tick sulla voce corrispondente.

Ora puoi nella finestra del terminale inserire un oggetto di visualizzazione numerica, definendo l’origine dei dati da protocollo Modbus indicando il modo 3x_Double con indirizzo 0. E nel formato dati il formato 32-bit Float.

[Sergio Bertana]

Ho ricreato la prova in laboratorio, vediamo intanto le connessioni Modbus:

• Il segnale RS485- và collegato con il morsetto 9 dello strumento
• Il segnale RS485+ và collegato con il morsetto 10 dello strumento
• I parametri di comunicazione di default sono 2400, n, 8, 1

Utilizzando Toolly menù Utilities -> Modbus master, ecco come si presenta la prova (Screenshot). Come si vede ho eseguito la lettura con il comando 04 Read Input Registers di 2 registri partendo da indirizzo 0 (Ricordo che Modbus ha offset 1 ecco spiegata la discordanza tra il manuale SDM120 che cita indirizzo 1).

Tutti i dati letti dallo strumento sono espressi in float IEE754 a 32 bit, il valore letto è quindi 0x4368333 che in decimale (Puoi utilizzare un convertitore on-line come questo) equivale a 232.199 Volts.

[Sergio Bertana]

Il PTP128 è un vecchio dimostrativo, per prendere pratica con le pagine web ti rimando a questo articolo dove puoi eseguire il download di alcuni esempi.

Ricordo che il simulatore su PC permette di eseguire programmi logici e matematici, non è gestito dal simulatore tutto quello che riguarda la comunicazione sia seriale che TCP.

Inoltre il simulatore non ha un server HTTP attivo, quindi per provare le pagine web devi necessariamente utilizzare un modulo CPU SlimLine.

[Sergio Bertana]

La definizione NaN è un acronimo che indica “Not A Number”. I valore NAN per una variabile REAL in formato IEE754 è un valore che ha tutti gli 8 bit di esponente a “1” e la mantissa diversa da “0”, il segno non importa.

Quindi se lo rappresentiamo in esadecimale sarà un numero del tipo 16#7F8FFFFF, ma qualsiasi altro numero che mantenga tutti gli 8 bit di esponente a “1” e la mantissa diversa da “0” verrà indicato cone un NaN. Risulta quindi evidente che non c’è un numero univoco per rappresentare il NaN, se vuoi settare una variabile a NaN puoi utilizzare una definizione del tipo:

VAR
    APtr : @DWORD;
    RVars : ARRAY[0..3] OF REAL;
END_VAR

    // Definizione valori REAL in esadecimale. Vedi sito:
    // https://www.binaryconvert.com/convert_float.html

    APtr:=ADR(RVars[0]);
    @APtr:=16#41280000; //10.5

    APtr:=ADR(RVars[1]);
    @APtr:=16#42C80000; //100.0

    APtr:=ADR(RVars[2]);
    @APtr:=16#7F8FFFFF; //NaN (Not a number)

    APtr:=ADR(RVars[3]);
    @APtr:=16#7F800001; //NaN (Not a number)

Come vedi dall’esempio sia il valore 16#7F8FFFFF che 16#7F800001 sono riconosciuti come NaN. Da quanto espresso si deduce che non è possibile fare comparazioni sul valore NaN, e certamente potrebbero servire due cose:

• Una definizione di NaN per settare il valore in una variabile.
• Una funzione di verifica se un numero REAL e NAN. La funzione deve verificare se il numero ha gli 8 bit di esponente a “1” e la mantissa diversa da “0”.

[Autore]

Post