[Sergio Bertana]

The fact that the inverter doesn’t answer excludes a wrong register address problem. If the address is wrong usually the device answers with a modbus error data frame. So the suggestions are to focusing on serial mode, Modbus node and cable wiring.

It’s a little bit strange the reception of an 00 code, have you correctly terminated with a 120 ohm resistor on both sides, the RS485 line ?

[Sergio Bertana]

It seems that the inverter doesn’t answer to the Modbus request sent by the SlimLine, following some indications how to fix the problem.

Have you checked the serial mode set (The SlimLine default is 115200, e, 8), is it according to the Toshiba inverter requirements ?
Check serial connection, sometimes the D+/D- signals are misinterpreted, tries to reverse the connection.
The Modbus node sent by your program is 02, are you sure that the inverter has this modbus node ?
The register address is 0xFD01 (64769 decimal) it seems too high.
According to Modbus specifications the address sent is (Address-1) sometimes you have to add 1 to Address.
Activates the SpyOn, spying by a Telnet connection it can be seen how the FB is working (It’s a great help to troubleshooting).

[Sergio Bertana]

In effetti ci siamo accorti che nella libreria gestione SlimLine Linux (ElSLLinux) versione SFR064A700 per errore non sono state incluse le funzioni di gestione modulo uscite analogiche. Ho provveduto a rilasciare la nuova libreria SFR064B000 con due nuove funzioni (La libreria è scaricabile dalla pagina web del modulo CPU ARM9 Linux):bool_t eSLineAOMode(uint8_t Module, uint8_t Channel, uint8_t Mode); //Analog output set modebool_t eSLineAOValue(uint8_t Module, uint8_t Channel, float32_t Value); //Analog output set valueNel file ElSLLinux.h sono state anche aggiunte le definizioni dei vari modi di acquisizione e di gestione supportati dai moduli di I/O analogico (Ecco l’estratto del Manuale programmazione IEC61131-3).

[Sergio Bertana]

Visto che dici che in RS485 tutto funziona, per passare in RS232 basta come hai fatto correttamente tu definire sulla Sysfopen la COM0 al posto della COM2, tutti gli altri parametri sono invariati.

Non è che hai commesso l’errore classico di utilizzare un cavetto CBL057 per interconnettere i due dispositivi ? per la connessione devi incrociare i segnali Rx e Tx tra i due sistemi. Quindi ho utilizzi una accoppiata CBL054-CBL055, oppure ti autocostruisci un cavetto con i segnali incrociati.

Anche in questo caso l’attivare lo SpyOn può essere utile per capire cosa succede.

[Sergio Bertana]

Premetto che non comprendo perchè non puoi accedere direttamente in VNC al pannello esistente (Immagino perchè tu desideri crearti una pagina di accesso con le sole variabili che vuoi rendere accessibili da remoto). Il VNC server dei pannelli ha un timeout quindi se non chiuso correttamente dopo 10-15 minuti viene chiuso automaticamente dal pannello.

Sulle nuove versioni software è attivabile la multi connessione VNC (Vedi screenshot), sono accettate fino a 3 connessioni VNC contemporanee.

Il Cloud HMI cMT-SVR non supporta il VNC, ma permette la completa accessibilità all’impianto, compresi i dispositivi ethernet connessi al pannello (Esempio i PLC) permettendone la teleassistenza tramite EasyAccess 2.0. In questo modo eviti problemi di firewall e tutto funziona anche su reti NATtate senza IP pubblico.

Se poi il tuo problema è proprio di avere una pagina dedicata accessibile da remoto, puoi creare sul cMT-SVR le tue pagine ed accedervi da remoto con il cMT viewer (App gratuita disponibile per tutte le piattaforme Android, iOS e Windows).

[Sergio Bertana]

Non sono un esperto di javascript e di css, ma avevo già alcune soluzioni che utilizzando queste tecniche ti permettono di ottenere quello che hai bisogno, se vedi nelle aplicazioni Modem machine e Data exchange (I due programmi sono scaricabili dal sito), si fà già uso di queste tecniche per visualizzare  stati di I/O e stati di funzionamento della aplicazione abbinati a tecniche AJAX di rinfresco automatico della pagina web.Ho attinto il succo da quelle pagine ed ho preparato una pagina htm che appoggiandosi alla variabile USINT DB100.16 permette di gestire qualcosa di simile a quello che tu chiedi (Screenshot). Allego il file htm sorgente da trasferire nella cartella Storage dello SlimLine (Download).

[Sergio Bertana]

La parte più semplice della risposta è sull’hardware da utilizzare per la misurazione, puoi utilizzare un modulo CPU compact (Esempio CPU Compact Eth. LogicLab) abbinato a due moduli di espansione I/O analogico. Se la precisione (10 bit) del convertitore A/D presente sul modulo CPU a te è sufficente puoi usare i 2 ingressi del modulo CPU ed un solo modulo di espansione I/O analogico a 10 ingressi.

Il problema più difficile da risolvere è convertire i tuoi 500V in una tensione 0÷10 volt, ammesso di avere tutte le tensioni riferite ad un unico riferimento di GND puoi in teoria utilizzare dei partitori, ma con tensioni così elevate non è così semplice realizzare un partitore.

Una soluzione più sicura, ma certamente più costosa è utilizzare un isolatore galvanico per ogni ingresso, come ad esempio questo della Alter elettronica (Datasheet).

[Sergio Bertana]

Sicuramente per la portabilità del codice è preferibile non utilizzare riferimenti a variabili esterne all’interno di FB, ma se il FB si utilizza sempre su sistemi SlimLine in ambiente LogicLab è accettabile fare riferimenti a variabili esterne predefinite (Come SysDateTime), queste variabili sono definite nel target è sono sempre presenti.

Diverso è il caso in cui ci si riferisca a variabile esterne definite nel programma, spostando il FB da un programma ad un altro se la variabile globale non è presente si ha un errore di compilazione. Comunque è possibile gestire temporizzazioni anche senza riferirsi a variabili esterne.

Allego al topic un programma in cui ho realizzato un FB timer, esattamente come il FB eTON (Estratto manuale). Troverai il sorgente di un FB realizzato con una variabile esterna ed uno esattamente uguale utilizzando la funzione SysGetSysTime. Come si vede dalla stampa programma, la funzione SysGetSysTime ritorna il tempo in uS quindi per mantenere le definizioni in mS ho provveduto a dividere per 1000.

Naturalmente essendo la variabile di appoggio riferimento tempo di tipo UDINT, utilizzando la variabile esterna che torna il tempo in mS si potranno gestire temporizzazioni massime fino a circa 1200 ore. Mentre utilizzando la funzione che torna il tempo in uS si potranno gestire temporizzazioni massime fino a circa 1.2 ore (Download programma).

[Sergio Bertana]

Venendo nello specifico della tua domanda sembra un problema di comunicazione con il modulo CPU. Se il pannello non riesce a comunicare non visualizza gli oggetti grafici correlati alla comunicazione in errore. Lo strano è che tu riesca ad eseguire la definizione del valore di SetTime, questo indica che la comunicazione funziona.

Lo schema della connessione seriale è corretto, un dubbio potrebbe essere nelle impostazioni del protocollo seriale, è possibile impostare un ritardo comunicazione è sopratutto un numero di rinvio comandi (Vedi screenshot).

[Sergio Bertana]

In questo topic ho ripreso il progetto compilandolo con le ultime versioni dei programmi LogicLab e EasyBuilder Pro.

[Sergio Bertana]

Approfitto della domanda per rispolverare questo vecchio topic, ho importato il progetto HMIStartup e l’ho ricompilato utilizzando le ultime versioni sia di LogicLab che di EasyBuilderPro. Per facilitare il debug del programma pannello eseguendone il test direttamente sul PC con il simulatore (Senza il pannello fisico) ho modificato il tipo di connesione da seriale a ethernet con il protocollo Modbus TCP/IP (Screenshot).

Ricordo che occorrerà nel proprio progetto modificare nel programma pannello l’indirizzo IP del PLC in base all’indirizzo IP del modulo CPU a cui è collegato (Screenshot).

Inserisco nel topic il progetto modificato pronto da utilizzarsi (Stampa programma LogicLab, Download progetto).

[Sergio Bertana]

Vengo all’ultima domanda, Molti potrebbero essere i motivi percui la comunicazione non avviene, visto che mi dici che il FB ModbusMaster và in Fault si tratta sicuramente di un problema legato al protocollo. Ecco une serie di verifiche da fare…

Sei sicuro della corretta impostazione della seriale, l’indirizzo di nodo del nodo slave è corretto, il codice funzione che utilizzi è supportato dal sistema slave, l’indirizzo della variabile ed il numero di variabili definite nel comando sono supportate dal sistema slave…

Ricorda che il protocollo Modbus ha offset 1 sull’indirizzo e molti dispositivi non lo gestiscono, quindi magari devi sommare 1 all’indirizzo dato al FB ModbusMaster.

Puoi attivare il bit SpyOn e vedere nella console di spionaggio (Topic) i pacchetti Modbus per capire la causa del tuo problema.

[Sergio Bertana]

Immagino che sui moduli Slaves tu abbia utilizzato la gestione Modbus slave embedded gestita in automatico dal sistema operativo, il Modbus controlla i comandi arrivo da COM o ethernet e li gestisce di conseguenza ma non può prendere decisioni autonome. Quindi se il comando modbus dal sistema master scrive un registro che poi nel tuo programma viene copiato sulle uscite il valore rimarrà costante fino a quando non verrà ricevuto un comando Modbus di variazione. E’ evidente che se stacchi il cavo il comando non potrà arrivare e quindi le uscite riamrranno nello stato impostato. Per risolvere il problema hai diverse soluzioni.

Utilizzando la gestione embedded, puoi ad esempio dal master inviare ciclicamente un comando modbus di scrittura di un valore in un registro. Nel tuo programma slave controlli che vi sia questo valore e poi lo azzeri, se il registro non verrà valorizzato nel tempo di rinfresco è evidente che c’è un problema di comunicazione e quindi prendi le decisioni opportune (Esempio disattivi le uscite).

Utilizzando FB ModbusSlave, utilizzando il FB nel tuo programma controlli l’uscita Done (Si attiva ad ogni ricezione di un pacchetto Modbus) se non si attiva per un tempo di timeout c’è un problema di comunicazione.

Per connettere due moduli in RS232 non puoi utilizzare un nostro CBL057 ma devi utilizzare un cavo incrociato. Se vuoi puoi utilizzare due adattatori CBL054 e CBL055 tra di loro interconnessi. Altrimenti devi autocostruirti un cavo a 3 fili incrociando Tx ed Rx (Gli altri segnali non sono necessari).

[Sergio Bertana]

Il programma ELSLLinuxTester viene eseguito di default allo startup (Vedi file di shell /data/ELStarter.sh). Quando hai realizzato il tuo applicativo dovrai sostituire il nome del tuo programma nel file ELStarter.sh per permetterne l’esecuzione automatica allo startup.

Questo programma è in ascolto sulla porta 1000 e permette di gestire una serie di test sul modulo. Collegandosi con un telnet (Esempio Toolly) alla porta è possibile effettuare il login nel programma (Username e Password: Admin) e digitando ? è possibile avere un elenco dei comandi possibili (Vedi screenshot).

[Sergio Bertana]

Il modulo CPU ARM9 Linux viene fornito con un programma di test lanciato allo startup. Collegandosi in telnet sulla porta 23 (Con Toolly o PuTTY) e digitando il comando ps avremo un elenco dei processi attualmente in esecuzione ecco un estratto:

root@SlimLine:/# ps
PID   USER     COMMAND
    1 root     init [2]
    …        …
  1202 root     ./ELDevDiscovererD
 1205 root     ./ELSLLinuxTester

Come si vede il processo 1202 è il programma ELDevDiscovererD verificare la presenza del modulo sulla rete, mentre il processo 1205 è il programma ELSLLinuxTester che permete di testare il funzionamento del modulo. Questo programma utilizza la libreria ElSLLinux (La stessa inclusa nel programma di esempio che tu utilizzi). L’utilizzo contemporaneo da due processi di questa libreria non è possibile in quanto le risorse (Esempio il bus di espansione) non possono essere condivise. Quindi per eliminare il problema occorre terminare il programma ELSLLinuxTester, utilizza il comando kill 1205 (Naturalmente se il PID è come nel mio esempio 1205).

[Autore]

Post