Connessione con I/O distribuiti TRP via modbus RTU

Il modulo TRPC26 utilizza il comando modbus 01 Read Coil Status per la lettura dello stato dei 16 ingressi digitali, mentre il modulo TRPC24 utilizza il comando modbus 15 Force Multiple Coils per la scrittura delle 16 uscite digitali. Utilizzando il blocco funzione ModbusRTUMaster (Estratto manuale), è possibile eseguire la lettura degli ingressi dal modulo TRPC26 e la scrittura delle uscite sul modulo TRPC24.

Ho realizzato un programma su SLine che effettua ciclicamente la lettura dei 16 ingressi del modulo di ingressi e li appoggia in 16 variabili BOOL (TRPC26Input[0..15]), copia 16 variabili BOOL (TRPC24Output[0..15]) sulle 16 uscite logiche del modulo di uscita. I due moduli sono stati connessi in rete RS485, occorre definire al modulo di ingressi logici indirizzo 0x01 (Default), al modulo uscite logiche indirizzo 0x02, vedi post.

Nel programma troverai un programma ladder Logic, che appoggia l’ingresso DI0 del moduli di ingressi sull’uscita DO0 del modulo di uscita. Potrai aggiungere tutte le logiche che ti servono aggiungendo linee a questo file e/o aggiungendo altri programmi al progetto.

Il programma TRPComm esegue la letura e scrittura ciclica dei moduli di I/O, i programmi InputRead e OuputWrite, eseguono lo swap dei bits letti e da scrivere verso i moduli TRP per poter avere le variabili BOOL ordinate in funzione degli I/O sul modulo. Stampa programma, download programma.

Chiedo delucidazioni in merito all’esempio IOOverTRP che provato con successo su differenti produttori di IO modbus.

Sto attualmente eseguendo test di comunicazione con un Siemens S7-200 usato come slave modbus dello collegato allo SlimLine. L’unica modifica che ho fatto per poter leggere il succitato slave modbus è stato quello di impostare FCode=16#03 e impostare il parametro Address in modo opportuno.

Ho riscontrato la situazione che può dedurre dalla figura, ovvero che l’array TRPC26Read non si valorizza correttamente. Infatti dalla finestra Watch si valorizza correttamente solo il bit meno significativo dell’array mentre la visualizzazione di %MW100.0 dimostra che la comunicazione avviene correttamente.

Aggiungo un Tip che può essere utile a capire l’indirizzamento dei sistemi SlimLine. SlimLine è basato su di un procesore ARM che utilizza la memorizzazione dei dati nel formato little-endian, inizia dal byte meno significativo per finire col più significativo.

Quindi come puoi vedere dall’esempio la %MW100.0 è valorizzata con il valore 16#0005, quindi alla locazione con offset 0 dell’array TRPC26Read allocato allo stesso indiirizzo di %MW100.0 corrisponde LSB del valore della word, mentre alla locazione con offset 1 corrisponde MSB.

Essendo il valore della word 16#0005 il suo LSB sarà diverso da zero, cioè TRUE, mentre il suo MSB sarà uguale a o cioè FALSE. Se il valore della word fosse stato 16#0101 avremmo avuto sia MSB che LSB al valore TRUE.

Il formato utilizzato per le variabili REAL è IEEE 754 come detto in questo post, dai tuoi screenshots si evince che è lo stesso formato usato dal S7-200. Infatti in questo formato di rappresentazione, il valore REAL 2.0 vale in esadecimale 16#40000000 (Come si vede dalla finestra di debug su S7-200).

Attenzione! Nella lettura di variabili a 32 bits tramite modbus occorre prestare attenzione all’endianness dei dati, il protocollo modbus infatti non specifica in che ordine devono essere ritornate le due parti a 16 bits del dato a 32 bits. Quindi è possibile che in alcuni sistema venga ritornata la parte più significativa prima della parte meno significativa o viceversa.

Su SlimLine come già detto in altri posts si utilizza la little-endian che inizia dal byte meno significativo per finire col più significativo, e da quanto vedo è lo stesso tipo di rappresentazione che utilizza Siemens nel S7-200 (Probabilmente utilizza un processore ARM). Infatti se noti nella %MW100.16 che è il primo registro letto da modbus si trova la parte meno significativa del numero e nella %MW100.18 la parte più significativa.

Il tuo errore quindi è solo nella inversione delle word nella conversione WordToDouble.

Si certo la soluzione che hai prospettato è realizzabile, in questo post puoi trovare un esempio di come gestire da SlimLine i moduli di I/O distribuito tramite Modbus. Acquisiti i moduli appoggerai gli I/O su variabili di memoria dello SlimLine accessibili da Modbus. Il PC può essere connesso in Ethernet e lo stato degli ingressi acquisito tramite modbus TCP, utilizzando ad esempio un software SCADA (Vedi post), un applicativo sviluppato con ProfilabExpert (Vedi post) oppure un applicativo sviluppato ad Hoc con il linguaggio di programmazione da te conosciuto. Se lo sviluppo del protocollo modbus TCP è troppo complesso puoi sviluppare un protocollo di comunicazione calibrato sulle tue esigenze (Vedi post). Se devi solo visualizzare lo stato dei campanelli, in alternativa al PC ti consiglio l’utilizzo di un pannello operatore touch screen che ha già nativa la gestione del protocollo modbus TCP, inoltre volendo puoi gestire il suono del buzzer ed anche visualizzare lo storico di intervento dei campanelli. Il pannello può gestire anche storici su file permettendo di avere un report degli interventi dei campanelli relazionato con data/ora.