[Sergio Bertana]

L’oggetto registrazione dati (Data Sampling) permette di effettuare la registrazione si su base tempi che su evento trigger, in questo caso è possibile comandare da PLC la lettura dei dati da salvare nella registrazione. Occorre definire una variabile BOOL nell’area PLC a cui il terminale si connette per effettuare il trigger, si possono definire tre tipi di trigger.

[OFF->ON] This will trigger data sampling when the status of assigned address changes from OFF to ON.
[ON->OFF] This will trigger data sampling when the status of assigned address changes from ON to OFF.
[ON<->OFF] Trigger data sampling when the status of assigned address is changed.

Non c’è un tempo minimo definito per la gestione del trigger, occorre lasciare al terminale il tempo per acquisire il cambiamento di stato della variabile. Normalmente il terminale esegue la lettura delle variabili molto velocemente e quindi tempi di variazione superiori al secondo sono sicuramente sufficenti. Non vi è un feedback verso il PLC per confermare l’avvenuta acquisizione del trigger da parte del terminale.

[Sergio Bertana]

Per cercare di dare una risposta alla tua domanda ricordo come il pannello operatore opera durante il salvataggio dei dati.

I dati storici non sono immediatamente salvati nel file storico, sono memorizzati in memoria e solo quando la dimensione dei dati raggiunge una certa dimensione (Non sò esattamente quanto, ma oltre ad 1 Kb), ne viene eseguita la scrittura sul file.

La scrittura dei dati è invece eseguita immediatamente se si stà visualizzando una pagina del pannello dove è riportato il trend. In alternativa è possibile forzare la scrittura immediata dei dati nel file agendo sulla variabile LB-9034 Save event/data sampling to HMI, USB disk, SD card (set ON).

[Sergio Bertana]

C’è un bug nell’aggiornamento del real time clock su SlimLine da terminale. Il problema è stato risolto con la versione del sistema operativo “SFW167D110”. Puoi eseguire il download dal nostro sito della nuova versione.

[Sergio Bertana]

Certo che è possibile inserire in un un unico file per ogni singola registrazione più variabili, nell’oggetto di registrazione dati Data sampling, nella zona record dati aprire la cartella formato dati agendo sul tasto Data Format, ed inserire tutte le variabili che si desiderano salvare nel record (Vedi screenshot). Ecco il report in formato Excel del file storico salvato dal terminale (Report storico).

Da questa finestra è possibile aggiungere le variabili desiderate. Naturalmente l’allocazione delle variabili partirà dall’indirizzo definito nel campo Read Address (Nel mio esempio la LW 10) e le variabili saranno quelle allocate agli indirizzi successivi da quello definito. Per ogni variabile è possibile definirne il tipo che può essere diverso variabile per variabile.

Attenzione! Se il tipo di variabile è di dimensioni maggiori del tipo definito nel Read Address il loro indirizzo di allocazione crescerà di un multiplo del tipo. Esempio il Real address è un unsigned int (16 bit) e alcune variabili sono Float (32 bit) la loro allocazione utilizzerà lo spazio di 2 variabili unsigned int.

[Sergio Bertana]

Per rispondere alla richiesta iniziale, da quanto si legge sul post precedente è evidente che realizzato lo scambio di memoria tra due sistemi SlimLine, basterà appoggiare nella memoria in scambio variabili BOOL dove si appoggiano gli stati degli I/O da scambiare tra i due sistemi.

Nella domanda però mancava l’indicazione dei tempi richiesti dalla applicazione, ho realizzato come esempio due programmi uno denominato Master ed uno denominato Slave. Il Master invia tramite modbus su linea seriale 2 ingressi verso lo Slave ed acquisisce 2 ingressi dallo Slave. Se non interessa lo scambio bidirezionale di I/O si può eliminare la parte non interessata.

Ho testato lo scambio bidirezionale di I/O tra i due sistemi ed ho rilevato tempi di scambio compresi tra 15 e 40 mS. Naturalmente lo scambio unidirezionale, ingressi di un sistema inviati verso l’altro sistema (Come nel tuo caso), richiedono la metà del tempo. Allego stampa e sorgenti programmi Master e Slave di esempio.

[Sergio Bertana]

La comunicazione tra due (O più) sistemi SlimLine può avvenire in due modi, utilizzando la porta seriale, oppure tramite rete Ethernet.

Per la comunicazione seriale è disponibile il blocco funzione sModbusRTUMaster per la gestione della comunicazione modbus Rtu master. Collegando la seriale di un modulo CPU con la seriale di un altro modulo CPU, oppure creando una rete RS485 tra le seriali di diversi moduli CPU. Su uno dei moduli CPU è possibile realizzare un programma, che utilizzando il blocco funzione sModbusRTUMaster, può leggere e scrivere variabili nella memoria degli altri moduli CPU (Vedi post).

La comunicazione seriale e di tipo master/slave e ci può essere un solo master nella rete, quindi il modulo con il programma master farà un polling di interrogazione/scrittura dei vari moduli slaves.

Se invece si utilizza la comunicazione su rete Ethernet, è disponibile il blocco funzione UDPDataTxfer, che permette lo scambio di variabili di memoria con protocollo UDP. La connessione UDP a differenza di quella seriale permette di creare una rete multimaster e quindi nel caso di reti con più di due sistemi i vari sistemi possono scambiarsi dati tra loro senza dover passare (In triangolazione) da un sistema master.

[Sergio Bertana]

La task Slow è eseguita tipicamente ogni 10 mSec (E’ possibile impostare un tempo di esecuzione diverso vedi funzione SysSetTaskLpTime). Eseguendo il programma inserito nella task ogni 10 mS tutte le temporizzazioni avranno degli errori che possono arrivare ad eguagliare nel caso peggiore il tempo di esecuzione della task (10 mS).

Nel tuo caso dovendo gestire tempi di 30 mS è evidente che l’errore che ti devi aspettare è relativamente grande rispetto a quanto il tuo programma necessita e quindi l’effetto sulla gestione dell’uscita colla sarà evidente. Per risolvere il problema occorre che tutta la logica di gestione programma sia eseguita molto velocemente, almeno 10 volte più veloce dei tempi che tu devi gestire).

Per ottenere questo puoi semplicemente eseguire il programma nella task fast del sistema, questa task è eseguita di default ogni 1 mS, ma volendo usare tempi minore puoi definire il tempo di esecuzione con  la funzione SysSetTaskLpTime.

Attenzione! Per avere la gestione immediata degli I/O durante l’esecuzione di un programma nella task fast, occorre acquisire gli input con la funzione SysGetPhrDI e gestire le uscite con la funzione SysSetPhrDO. Se sono sufficienti 2 I/O è preferibile utilizzare gli I/O del modulo CPU con il blocco funzione CPUModuleIO.

Allego un programma LogicLab che gestisce nella task fast il ciclo colla così come me lo hai descritto (Stampa e Download programma).

[Sergio Bertana]

Nel post precedente mancano alcune indicazioni, inoltre la porta 8000 non è la porta utilizzata per il Pass-Thru ma è la porta utilizzata per la connessione con altri terminali in modo remoto.

Allego elenco delle porte utilizzate dai terminali (Download).

[Sergio Bertana]

L’esempio pur essendo un dimostrativo riporta esattamente un reale programma PLC.

Nelle logiche di marcia arresto è condizione indispensabile utilizzare come pulsante di marcia un pulsante normalmente aperto (no), e come pulsante di arresto un pulsante normalmente chiuso (nc).

Questo garantisce di poter sempre arrestare il motore anche in caso di rottura del filo di collegamento del pulsante di arresto. L’eventuale rottura del filo spegne l’ingresso pulsante di stop del PLC (PbStop) forzando lo spegnimento dell’uscita comando motore (Motor).

E’ per questo motivo che nella realizzazione del programma ladder di una sequenza di marcia/arrresto per il pulsante di stop è utilizzato un contatto normalmente aperto. Il pulsante di stop di tipo (nc) attiverà sempre l’ingresso del PLC, ed il relativo contatto nella sequenza logica ladder sarà sempre attivo (chiuso).

Concordo con te che nell’esempio per il simulatore poteva essere utilizzato un contatto normale chiuso, era più intuitivo l’utilizzo, ma abbiamo preferito seguire le indicazioni applicative reali.

[Sergio Bertana]

L’ATC-108 utilizza al suo interno un convertitore DC/DC per l’alimentazione della parte seriale RS232, questo oltre a garantire l’isolamento galvanico garantisce anche la compatibilità con i livelli di tensione in uscita sui segnali RS232 (Vedi post).La porta RS232 dell’ATC108 è del tutto simile a livello elettrico alla porta RS232 di un PC. Quindi anche se i dispositivi che prelevano la loro alimentazione dai segnali della RS232 (RTS, DTR, a volte anche dallo stesso Tx) nascondono sempre qualche insidia, credo non vi siano problemi di funzionamento.

[Sergio Bertana]

Tu mi chiedevi di poter variare l’indirizzo di memoria MX100 utilizzando una variabile ecco come puoi scriverlo semplicemente in linguaggio ST.

VAR
  Pointer : @USINT; { DE:”Variable pointer” }
  Offset : UINT; { DE:”MX100 address offset” }
END_VAR

Pointer:=ADR(%MX100.0)+Offset;

Scrivendo nella variabile Offset il valore desiderato, in Pointer verrà ritornato il suo indirizzo che potrai passarlo alla funzione eMemCpy. Volendo copiare 16 bytes da MX100.200 in MX100.100 dovrai scrivere.

Offset:=200;
Dummy:=eMemCpy(ADR(%MX100.100), ADR(%MX100.0)+Offset, 16);

[Sergio Bertana]

Con i puntatori si può accedere a qualsiasi parte della memoria del sistema, ma in caso di errore si può accedere a qualsiasi variabile senza alcun controllo creando anche problemi gravi di funzionalità del programma. E proprio per questa loro pericolosità che l’uso dei puntatori è deprecato nella programmazione IEC61131.

In LogicLab esiste la possibilità di utilizzare i puntatori, in linguaggio ST, un puntatore si identifica con il simbolo @ posto davanti al tipo di variabile a cui il puntatore si riferisce. Quindi avremo dei puntatori di tipo @USINT, @INT, @REAL ecc. uno per ogni tipo di variabile gestita.

L’operando ADR (Utilizzabile in tutti i linguaggi) ritorna l’indirizzo di una variabile, in linguaggio ST si può anche utilizzare il simbolo ? davanti al nome della variabile. Quindi la definizione ADR(%MX100.10) ritornerà l’indirizzo della variabile MX100.10. La definizione ADR(MiaVar) o ?MiaVar ritornerà l’indirizzo della variabile MiaVar.

Ho realizzato un semplice programma con implementata la funzione eMemCpy che esegue copia tra due aree di memoria. Ecco la stampa del programma ed il programma sorgente, di seguito il codice della funzione eMemCpy.

WHILE (Size > 0) DO
  @DestBf:=@SrcBf; (* Trasferisco dato in memoria *)
  Size:=Size-1; (* Buffer size *)
  SrcBf:=SrcBf+1; (* Source buffer address *)
  DestBf:=DestBf+1; (* Destination buffer address *)
END_WHILE;

[Sergio Bertana]

Aggiungo note sul modo in cui è gestita la trasmissione seriale sullo SlimLine. Esiste un buffer di spooling in cui le funzioni che inviano dati sulla seriale trasferiscono i dati da trasmetere. Il sistema operativo poi provvede ad inviare i dati caricati nel buffer sulla porta seriale.

Se sono caricati più dati nel buffer di quelli che la porta seriale riesce a trasmettere si genera un overflow, ed i precedenti dati seriali in uscita, presenti nel bufer vengono sovrascritti. Per evitare questo o si è certi che il tempo di caricamento dei dati nel buffer, è sufficentemente lento da permettere alla porta seriale di inviarli in uscita. Oppure si controlla lo spazio disponibile nel buffer prima di caricare i dati con la funzione SysGetOSpace.

Ho modificato l’esempio precedente aggiungendo nella funzione FTest il controllo sullo spazio nel buffer di trasmissione prima di caricare i dati da trasmettere.

IF (SysGetOSpace(FpCom) < (Lenght+4)) THEN RETURN; END_IF;

Allego progetto modificato con il controllo dello spazio nel buffer di trasmissione per il download allego anche stampa progetto.

[Sergio Bertana]

Ho dato una occhiata al tuo programma ed in effetti ho visto l’errore che tu riporti, sinceramente non capisco la reale fonte del problema, e purtroppo in questi giorni di festività non posso contattare l’esperto.

Però ho provveduto a correggere una serie di imprecisioni che il tuo programma aveva, e con un semplice workaround ho sistemato anche la funzione FTest per farla funzionare secondo le tue aspettative. Ti riporto le correzioni fatte.

Nel progetto conviene sempre attivare il tick Case sensivity, nel menù Project-> Options (Screenshot). In questo modo si controlla il case delle lettere nei nomi di variabili e funzioni evitando di dare nomi a variabili che possono essere in contrasto con nomi già predefiniti.

Il tuo programma Main tramite la chiamata alla funzione FTest esegue l’invio di dati sulla seriale, è conveniente eseguire i programmi che gestiscono le seriali, i sockets, i files, sempre nella task di Back. E’ inutile sovraccaricare di lavoro le tasks Fast e Slow, rallentando l’esecuzione della logica, con operazioni che potrebbero essere lente.

Il workaround per risolvere l’errore è stato di modificare il tipo del parametro StrCmd, anzichè definirlo STRING l’ho definito di tipo @USINT (Puntatore a USINT). In questo modo nella chiamata alla funzione occorre passare l’indirizzo della stringa da inviare sulla seriale Result[0]:=FTest(FpCom0, ADR(StrCmd1));. La chiamata funziona anche definendo direttamente la stringa in linea Result[1]:=FTest(FpCom0, ADR(‘Hello!’));.

Nel programma Main, ho condizionato la chiamata alla funzione FTest per eseguirla una sola volta ad ogni cambiamento di stato della variabile SysClock1000. Chiamandola sempre come nel tuo programma, siccome il programma è eseguito ciclicamente avresti creato overflow nel buffer di trasmissione. Il programma eseguito ogni loop time di qualche mS (Magari anche meno di 1 mS) avrebbe caricato la stringa nel buffer di trasmissione seriale, la trasmissione su seriale anche a 115200 baud richiede almeno 90 uS per ogni carattere.

Allego il progetto modificato e funzionante per il download.

[Sergio Bertana]

In alternativa od in aggiunta al pannello operatore Weintek, puoi utilizzare un nostro sistema SlimLine, programmabile in IEC 61131 con il software garatuito LogicLab.

Con solo il modulo CPU, puoi, semplicemente utilizzando il blocco funzione sModbusRTUMaster (Estratto manuale), dialogare in modbus RTU con i controlli di stringa. Tramite gli I/O logici (2 sono presenti sul modulo CPU) puoi gestire segnalazioni di allarme. Utilizzando i blocchi funzione di invio e ricezione SMS puoi gestire l’invio di allarmi e/o report di stato tramite messaggi SMS (Vedi post).

Al modulo CPU puoi collegare un pannello operatore Weintek per la visualizzazione dei dati.

[Autore]

Post