[Sergio Bertana]

Ora è tutto molto più chiaro, il problema è che il simulatore non gestisce ne le comunicazioni (Seriale e TCP) né gestisce i files, ecco perché non riesci a fare quello che desideri. Per poter dialogare in Modbus ti serve proprio il target hardware (Un sistema SlimLine o Netlog).

Andando più approfonditamente nell’argomento ti posso dire che SimuLab (Cioè l’ambiente di simulazione) dà disponibili aperture di comunicazione via TCP/IP su localhost ma non con il protocollo Modbus. Queste informazioni le puoi avere direttamente dalla ditta che realizza LogicLab e SimuLab che è la ditta Axel. Ti mando un email al tuo indirizzo privato in cui ti allego tutti i riferimenti.

[Sergio Bertana]

Non abbiamo notizie di blocchi simile al tuo anche da utenti che utilizzano il pannello connesso a PLC Mitsubishi. Quindi tenderei ad escludere bugs nel driver di comunicazione PLC. Visto che hai già provveduto ad eseguire l’upgrade del firmware del pannello, credo non ti resti che compilare l’RMA ed inviarci il pannello per la riparazione.

[Sergio Bertana]

A partire dalla versione SFW184A800 del sistema operativo è stata introdotta la funzione SysSpyData che permette se abilitata di spiare da connessione Telnet dati di programma utente, è utilizzata in alcuni FB e funzioni per permetterne il test di funzionamento. Nel tuo caso specifico è utilizzata nel FB ModbusMaster per spiare i dati in transito sullo stream di comunicazione. Infatti gli errori sono tutti riferiti alla FB ModbusMaster.

Purtroppo per gli SlimLine MPS046Ax00 non è stata implementata questa funzione ma ti posso consigliare un workaround che ti permette di aggirare il problema. Come vedi dalla stampa di questo progetto ho realizzato una funzione SysSpyData esattamente uguale come argomenti alla funzione embedded, in questo modo LogicLab compila il progetto utilizzando nelle librerie la chiamata a questa funzione senza generare errore.

Occorre anche definire 3 costanti che definiscono il modo in cui la funzione esegue lo spy dei dati. Le costanti vanno definite nell’area di definizione delle variabili globali. Allego comunque il progetto sorgente per il download da cui si può esportare sia la funzione che le definizioni.

SPY_ASCII : USINT := 1; (* Ascii mode *)
SPY_BINARY : USINT := 100; (* Binary mode *)
SPY_ASCHEX : USINT := 10; (* Extended ascii mode *)

[Sergio Bertana]

Ecco la stampa di un semplice programma che utilizzando la funzione SysVarsnprintf crea il messaggio da inviare e poi usando la funzione SysUDPSktSend è possibile inviarlo in UDP. Come si vede ho reralizzato un PROGRAM in linguaggio ST che gestisce una temporizzazione, ad ogni secondo incrementa il valore di due variabili REAL e ne invia il valore in UDP.

Nel mio caso il valore è inviato all’indirizzo 192.168.0.42 su porta 2000, e come si vede dallo screenshot ho messo Toolly come server UDP in ascolto sulla porta e ricevo i dati inviati dallo SlimLine. Come carattere di inizio ho scelto “[” come separatore “-” e come terminatore “]”, ma puoi scegliere i caratteri che desideri, basta modificarli nella funzione SysVarsnprintf.

Per semplificarti la decodifica della stringa ricevuta, puoi anche fissare il numero delle cifre trasmesse modificando la formattazione del numero nella funzione SysVarsnprintf. %.2f forza 2 cifre decimali, .3f fissa al minimo 7 cifre 3 intere il punto e 3 decimali (Esempio se il valore è 95.32 verrà riportato come 095.320). Allego programma sorgente per download.

[Sergio Bertana]

Eseguendo il simulatore SimuLab all’interno di LogicLab si apre il pannello di simulazione che prevede la possibilità di avere alcune configurazioni già preimpostate. Attivando questi pannelli puoi simulare il modulo CPU base e quello Compact oltre ad un modulo di I/O sia logico che analogico.

Ma queste sono solo suggerimenti, per la simulazione è preferibile aggiungere pannelli custom e semplicemente trascinando nel pannello la variabile potrai gestirne la simulazione (Screenshot). Quindi nel tuoi caso aggiungi un pannello e poi trascini all’interno le variabili che utilizzi nel tuo progetto.

[Sergio Bertana]

Dici che apri la connessione TCP/IP ma verso che porta ? immagino tu desideri utilizzare il Modbus TCP quindi credo utilizzi la porta 502. Se è così ti ho già spiegato nei post precedenti come poter fare, ti rimando comunque alla lettura della Modbus Protocol Reference Guide e della Modbus messaging on TCP/IP implementation guide.

Per aiutarti posso ancora riproporti delle semplici stringhe modbus per leggere e scrivere un registro a 16 bits nella memoria dello SlimLine. Ipotizzando di dover accedere ad una variabile allocata nella DB 100.16 (Indirizzo modbus 40008). Ricorda che l’indirizzo Modbus ha offset 1 pertanto nel comando devi inviare indirizzo -1 (40007 -> 0x9C47) per meglio capire ti allego l’estratto del manuale.

Per leggere il valore devi usare il comando modbus Code 03: Read holding registers, che in esadecimale è 00 00 00 00 00 06 01 03 9C 47 00 01.

Per scrivere 0x1234 devi usare il comando modbus Code 10: Preset multiple registers, che in esadecimale è 00 00 00 00 00 09 01 10 9C 47 00 01 02 12 34.

Per scrivere 0x5678 devi usare il comando modbus Code 10: Preset multiple registers, che in esadecimale è 00 00 00 00 00 09 01 10 9C 47 00 01 02 56 78.

Ecco lo screenshot dell’invio dei comandi verso uno SlimLine effettuato con Toolly. Come vedi in rosso sono evidenziate le stringhe di risposta ai comandi di scrittura (Preset) ed in blu quelle di risposta ai comandi di lettura (Read). Attenzione alla configurazione di Toolly nel Config devi definire modalità HEX.

[Sergio Bertana]

Dopo quanto scritto precedentemente ecco la stampa di un programma che dimostra come utilizzare I/O nella task Fast. Come si vede vi sono due programmi uno eseguito in Slow che appoggia l’ingresso Di00M00 sull’uscita Do00M00, ed un programma eseguito in Fast che appoggia l’ingresso Di01M00 sull’uscita Do01M00 (Download programma). Punti da considerare.

Il modo di acquisizione ingressi e DI_I_8_LL in modo da evitare il debouncing hardware presente sui moduli.

Nella gestione delle uscite logiche viene impostato il Mask per mascherare il bit 1 (Quello relativo alla uscita Do01M00). Attenzione la mascheratura è definita a bit, se si gestiscono più bit devi fare la OR dei bits utilizzati. Esempio per mascherare i bits 0, 1, 4 devi scrivere 16#00000013.

Nelle altre tasks (Slow e Back) non devi utilizzare le uscite gestite nella task Fast.

[Sergio Bertana]

Tutti i moduli di I/O logici connessi al modulo CPU sono aggiornati automaticamente (Immagine di processo) e mappati nella tabella %IX e %QX nella task Slow. Gli ingressi sono acquisiti prima e le uscite sono gestite dopo, l’esecuzione del programma utente. Quindi l’immagine dello stato di un I/O è valida per tutta l’esecuzione della task slow.

Nella task Back, viene creata una immagine di processo “parallela” che riporta lo stato degli ingressi prima della esecuzione e gestisce le uscite dopo l’esecuzione del programma utente, anche questa “immagine” dello stato di un I/O è valida per tutta l’esecuzione della task ma riporta lo stato degli I/O così come sono stati gestiti dalla task Slow, aggiornati quindi con la velocità di esecuzione della task Slow.

Nella task Fast se si vuole gestire gli I/O alla velocità di esecuzione della task, occorre acquisirne il valore e gestirne l’attivazione con le apposite FB (SysGetPhrDI e SysSetPhrDO) e non utilizzando quelli mappati nella tabella %IX e %QX. Ora siccome la gestione degli I/O tramite il bus I2C richiede tempo CPU è preferibile utilizzare nella task Fast gli I/O del modulo CPU, od in alternativa cercare di utilizzare I/O sullo stesso modulo di estensione a gruppi di 8/16 in modo da potervi accedere con una unica chiamata alle funzioni di gestione. In questo topic viene trattato lo stesso argomento.

[Sergio Bertana]

Toolly oltre che trasmettere un file può anche salvare in un file tutto quello che riceve, se apri una istanza terminale su porta seriale puoi definire il file su cui viene salvato tutto quello che è ricevuto dalla porta seriale (Screenshot). Agendo sul tasto Config si può impostare il file in cui salvare tutto quello che  si riceve dalla istanza di terminale aperta.

Certo questa è una operazione da eseguire a mano, magari dovrai farti un programma tuo che automatizzi queste operazioni. NB, se usi Toolly puoi anche evitare di usare il software VirtualCOM, basterà aprire l’istanza terminale con una comunicazione di tipo TCP/IP direttamente sull’indirizzo IP del convertitore.

[Sergio Bertana]

La prima prova che consiglio di fare con i convertitori Ethernet/Seriale è proprio questa, utilizzare due PC oppure anche solo uno con il programma Toolly in emulazione terminale (Nel caso di un solo PC utilizzerò due istanze).

Una delle emulazioni terminale si connette direttamente via TCP/IP al convertitore Ethernet/Seriale (Senza usare il software VirtualCOM). L’altra istanza si connette ad una porta seriale nativa del PC oppure tramite un convertitore USB/Seriale, questa seriale è connessa con un cavo null modem alla porta seriale del convertitore Ethernet/Seriale.

Il test è proprio inviare i dati da un terminale e riceverli dall’altro e viceversa (Attenzione ai settaggi seriali, per il convertitore occorre definire i settaggi dalla sua pagina web). Quindi come si vede il dialogo è bidirezionale.

Poi si prosegue nella prova installando il software di vitualizzazione VirtualCOM e si collega l’istanza terminale di Toolly alla porta COM virtuale anziché via TCP/IP al convertitore (Questa è la prova che hai fatto tu). Ed anche in questo caso potrai testare la comunicazione bidirezionale tra le due istanze del terminale Toolly. Qui potrai anche testare che le impostazioni seriali del convertitore Ethernet/Seriale sono ora accessibili dalla porta COM virtuale proprio come se fosse una COM reale.

Quindi la risposta alle tue domande è si, certo il dialogo è bidirezionale proprio come se fosse una COM reale del PC, unica differenza è che essendo la comunicazione TCP/IP a pacchetti i dati seriali sono pacchettizzati e poi trasmessi e questo porta ad un ritardo di comunicazione che può essere pochi mS su reti Ethernet libere fino a diventare un tempo importante su reti molto trafficate o reti WiFi.

[Sergio Bertana]

Non conosco il software WNComm, se è un software di vitrtualizzazione porte su TCP/IP come il WinComm della Delrina fa esattamente questo. Ma attenzione ai tempi di ritardo nelle comunicazioni TCP/IP e WiFi si introducono tempi di ritardo, bisogna sempre provare l’applicazione prima di dire che funziona.

Tutti i convertitori Ethernet/Seriale che commercializziamo hanno a corredo un software di virtualizzazione porte COM. Il software di virtualizzazione fa proprio ciò che desideri, cioè rende disponibile una porta COMx in Windows.

[Sergio Bertana]

Devi scegliere l’oggetto Funzioni PLC e definire una nuova funzione (Ved screenshot), come  tipo di controllo scegli Esegui programma macro e poi definisci la macro da eseguire. Puoi scegliere la variabile da controllare sul PLC ed il tipo di Trigger.

Consiglio, siccome non sai quando il terminale ha acquisito lo stato della variabile dal PLC per essere sicuro della sua acquisizione e della conseguente esecuzione della macro devi temporizzare la variabile almeno 1 secondo. Io preferisco scegliere come trigger OFF<−>ON e poi inverto lo stato della variabile sul programma PLC ogni volta che desidero eseguire la macro. In questo modo non mi preoccupo del tempo di attivazione variabile.

[Sergio Bertana]

In questo topic ho trattato l’argomento lettura velocità con ingresso da proximity. Applicando il programma descritto potrai rilevare la velocità del nastro trasportatore master.

A questo punto basterà con una semplice formula matematica calcolare il valore di riferimento di tensione da applicare all’inverter di comando del nastro slave per farlo girare alla stessa velocità. Poi usando un modulo di uscita analogica potrai dare il riferimento calcolato.

Visto che il nastro slave è pilotato da un inverter non credo sia necessario rilevarne la velocità con il proximity in quanto l’inverter dovrebbe già garantire una velocità abbastanza precisa. Ma nel caso volessi creare un ulteriore loop di regolazione potresti rilevare anche qui la velocità e creare un feedback di tipo PID (Topic).

[Sergio Bertana]

Lo standard attuale prevede la definizione di oggetti quali funzioni e FB (Function block) che possono essere manipolati graficamente utilizzando la programmazione ladder o FBD.

Se per programmazione ad oggetti intendi anche la possibilità di definire classi, utilizzarne l’ereditarietà, il polimorfismo, ecc, è una via che lo standard IEC 61131 stà implementando nella sua terza edizione.

[Sergio Bertana]

Tutte le variabili globali mappate nella DB 100 sono accessibili da Modbus, SlimLine gestisce nativamente il protocollo Modbus Ascii, RTU ed OverIP. Le variabili della DB 100 sono accessibili con indirizzo Modbus 40000, quindi basterà che tu allochi le variabili che vuoi gestire dal tuo applicativo in Visual Basic nella DB 100 per poterle gestire tramite Modbus (Vedi topic, topic, topic), effettuando una ricerca nel forum troverai molte altre informazioni sul protocollo Modbus.

Tutto quanto detto prima naturalmente impone  che tu sviluppi od utilizzi un driver di comunicazione Modbus, ma se non vuoi fare questo puoi trovare altri topics che spiegano come realizzare un semplice protocollo di comunicazione proprietario. In questo caso scegli tu che protocollo di comunicazione utilizzare per fare dialogare il PC con lo SlimLine e quali variabili scambiare (Vedi topic, topic, topic)

[Autore]

Post