Risposte nei forum create
-
Post
-
Non capisco cosa intendi per “non si attiva la TCPServer” hai provato a vedere il comando SysLog da Telnet per vedere che errori segnala ?
Stai utilizzando gli esempi copiati ed incollati dalla nostra Knowledge oppure hai qualcosa di diverso ?
Nel nostro esempio l’istanza del FB TCPDataExchServer è sempre attiva e gestisce 2 connessioni client ed avendo attivato il bit AutoTxD nella struttura dati provvede ad inviare i dati al client in modo automatico.
Probabilmente hai inserito tutta la gestione dell’arresto in task Back la cui esecuzione dipende dall’impegno del processore nell’eseguire le altre operazioni. Normalmente la gestione del Modbus non incide in modo determinante sul tempo di esecuzione.
Diversa è l’eventuale gestione del disco che a seconda dell’operazione che stai eseguendo potrebbe fare variare il tempo anche di 100-300 mS. A tal proposito ricordo che il sistema autonomamente provvede a registrare log su disco e quindi potrebbe in caso di record di log da salvare creare un jitter di esecuzione della task Back.
Se vuoi avere una esecuzione real time (con tempi certi senza jitters) devi mettere l’esecuzione di tutta la gestione del posizionamento in task Slow (Eseguita di default ogni 10 mS) o nella task Fast (Eseguita di default ogni 1mS). I tempi di esecuzione sono modificabili da programma.
Ma ricorda che devi gestire nella stessa task anche le uscite di comando del driver, se la gestione la inserisci nella task Slow non devi fare nulla, l’immagine di processo gestisce gli I/O nella task Slow.
Se invece inserisci la gestione nella task Fast devi usare il FB SysSetPhrDO ma verifica il tempo di esecuzione della task per non uscire dal tempo massimo (Eventualmente aumenta il tempo). La gestione delle s chede periferiche di I/O richiede un certo tempo 100-300 uS e tu devi leggere l’encoder e settare le uscite quindi occupi già oltre la metà del tempo disponibile. Nota: per velocizzare puoi usare gli I/O del modulo CPU, in questo caso il tempo di gestione è una decina di uS.
Immagino che la connessione sia ethernet con il protocollo Modbus TCP, puoi tranquillamente collegare più terminali ai sistemi SlimLine, di default sono gestite 3 connessioni Modbus TCP simultanee ma puoi aumentarne il numero dalla pagina web di configurazione.
Siccome anche l’ambiente di sviluppo LogicLab usa una connessione Modbus TCP ti conviene sempre abilitarne una in più dei terminali connessi al sistema.
Credo tu abbia utilizzato il FB IOEncoder per l’acquisizione visto che utilizzi un normale modulo di I/O, in questo caso la gestione della quadratura encoder è tutta demandata al software che campiona i due ingressi encoder in base alla velocità di esecuzione del FB che essendo in programma eseguito in task Fast è di 1 mS.
Se vuoi reattività e sopratutto non vuoi perdere impulsi di conteggio sugli encoder devi utilizzare il FB SysGetEncoder con i moduli di estensione che integrano la gestione encoder in modo hardware permettendo di gestire segnali fino a 50 kHz. Utilizzando queste schede non è più importante in che task ne esegui l’acquisizione perchè il valore ritornato dalla acquisizione è il valore del contatore gestito in modo hardware.
Se cerchi nel forum troverai altri posts che trattano l’argomento.
Aggiungo al post precedente che la configurazione dell’inverter è possibile dal tastierino addossato o più semplicemente tramite l’apposito software di configurazione (Vedi articolo).
Essendo dotato di interfaccia RS485 con protocollo Modbus, è anche possibile collegarlo al sistema DCS utilizzando una connessione seriale evitando tutta una serie di cablaggi e con possibilità di gestire un maggior numero di variabili.
E’ anche possibile e connettere i segnali logici ed analogici del DCS ad un nostro sistema programmabile SlimLine che si interfaccierà all’inverter in Modbus (Vedi FB apposita).
L’inverter è configurabile attraverso parametri ed è sicuramente possibile ottenere quello che ti occorre.
a) Ingresso S1, configurabile da parametro P05.01. Impostando valore 1 (Valore di default ) attivando l’ingresso si comanda la rotazione del motore “1:Forward rotation operation”.
b) Ingresso S3, configurabile da parametro P05.03. Impostando valore 7 (Valore di default ) attivando l’ingresso si esegue il reset degli allarmi “7:Fault reset”.
c) Uscita RO1, configurabile da parametro P06.03. Impostando valore 1 (Valore di default ) l’uscita si attiva se motore in rotazione “1:In operation”.
d) Uscita RO2, configurabile da parametro P06.04. Impostando valore 5 (Valore di default ) l’uscita si attiva se inverter in errore “5:The inverter fault “.
e) Ingresso analogico AI2 spostando lo switch relativo per ingresso in corrente. Configurabile dai parametri P05.31~P05.36.
f) Uscita analogica AO1 spostando lo switch relativo per uscita in corrente. Configurabile dai parametri P06.14~P06.21.
La normativa ISA 18.2 inizialmente redatta nel 2009 è stata rivista nel 2016, rappresenta una buona pratica ingegneristica, generalmente accettata, per identificare e promuovere la gestione degli allarmi.
Non conosco nei particolarì la normativa, che comunque è acquistabile presso il sito isa.org, ma so che molti dei ns clienti che utilizzano pannelli Weintek hanno realizzato gestioni di allarmi complesse seguendo le line guida della normativa. In generale per essere in linea con la normativa non solo occore che il terminale ne permetta di seguire le indicazioni, ma occorre che chi scrive il programma sul terminale le abbia ben chiare e le segua fedelmente.
Dal punto di vista della gestione, il terminale permette di definire per ogni allarme oltre al colore del testo anche la sua categoria in modo da poterli raggruppare nella visualizzazione (Screenshot).
Mi parli di RW ed LW, ma questi sono i riferimenti alle variabili interne al pannello, quando leggi variabili dal PLC devi fare riferimento alla sintassi del PLC che stai utilizzando.
Se usi un nostro sistema SlimLine con protocollo Elsist modbus per le variabili numeriche devi utilizzare il tipo MW se variabili a 16 bits o MDW se variabili a 32 bits (Screenshot). Il protocollo Modbus agisce sulle variabili allocate nella DB100 e come indirizzo devi usare l’indirizzo di allocazione diviso per 2 cui sommi 40000.
Poi cosa intendi per blocco dedicato solo alla lettura di numeri, l’oggetto Numeric fà proprio questo.
Proverei a rimuovere dal progetto il nascondi cursore cosi da capire se almeno il mouse sta lavorando correttamente (Screenshot).
Dalla versione C del sistema operativo si è gestito il file system a FAT32, ora la FLASH interna al modulo è vista come disco C: e la memoria SDCard è vista come disco D:.
Quindi i comandi “Format Storage” e “Format SDCard” sono spariti ora si usano i comandi “Format C:” e “Format D:” (Vedi topic). Nota: Non occorre formattare il disco C: perchè è già formattato di default e con la formattazione si perderebbero i file di configurazione.
L’accesso ai files da programma mantiene la compatibilità, quindi i percorsi del tipo “Storage/File…” o “SDCard/File…” sono gestiti, ma occorre creare la cartella Storage sul disco C: come indicato da questo articolo.
Ricordo che nella versione C viene gestita la sicurezza sull’accesso delle cartelle quindi se si desidera sostituire la pagine Web di default occorre scrivere le proprie pagine nella cartella “C:/Web“.
Il valore letto dal FB ModbusMaster è già un valore REAL quindi non devi effettuare casting con l’operatore TO_REAL ma basta semplicemente che tu definisca la variabile variabile_1 di tipo REAL.
Siccome Modbus non specifica l’endiannes dei dati ritornati su più word, potrebbe essere che acquisendo variabili espresse su 2 word (UDINT, DWORD, REAL) ci si ritrovi con MSW e LSW invertiti (Ma non mi sembra questo il tuo caso). Nel caso fossero invertiti puoi usare la funzione VarSwap per sistemarli.
Gli operatori di casting TO_REAL, TO_INT, ecc non eseguono operazioni servono solamente per informare il compilatore che nel programma si stà facendo un trasferimento di un valore da una variabile di un tipo in una variabile di un’altro tipo.
La soluzione più semplice è mappare due Device/Server, uno sarà il tuo PLC Siemens e l’altro sarà un server Modbus su connessione Ethernet.
Nella finestra di impostazione del server Modbus puoi spuntare la voce Modbus TCP/IP Gateway, e così è possibile definire una Mapping Table. Come vedi nella mapping table potrai abbinare ai registri Modbus le corrispondenti variabili Siemens. Avendo 4 DB da mappare dovrai dare un range di 512 words per ogni mappa. Spero che lo screenshot sia esaustivo.
Scusa se ho un po corretto il tuo post riportando solo le cose essenziali, cioè la stringa da inviare al display. Nel tuo programma l’errore era che nell’utilizzare la funzione Sysfputc non hai usato il corretto file pointer. Ho corretto il tuo programma utilizzando la funzione Sysfwrite.
VAR Start : BOOL; (* Comando start *) Pulse : BOOL; (* Pulse *) i : UDINT; (* Auxiliary variable *) DData : ARRAY[0..7] OF BYTE; (* Display data *) Serial : SysSerialPort; (* Serial port management *) END_VAR // ***************************************************************************** // PROGRAM "DisplayOut" // ***************************************************************************** // Questo programma esegue l'invio di una stringa ad una stampante. // ----------------------------------------------------------------------------- // ------------------------------------------------------------------------- // INITIALIZATION // ------------------------------------------------------------------------- IF (SysFirstLoop) THEN // Inizializzo porta seriale. Serial.COM:=ADR('COM0'); //COM port definition Serial.Baudrate:=9600; //Baudrate Serial.Parity:='N'; //Parity Serial.DataBits:=8; //Data bits Serial.StopBits:=1; //Stop bits Serial.DTRManagement:=DTR_AUTO_WO_TIMES; //DTR management Serial.DTRComplement:=FALSE; //DTR complement Serial.EchoFlush:=FALSE; //Received echo flush Serial.DTROnTime:=0; //DTR On time delay (mS) Serial.DTROffTime:=0; //DTR Off time delay (mS) Serial.FlushTm:=0; //Flush time (mS) Serial.RxSize:=0; //Rx buffer size Serial.TxSize:=0; //Tx buffer size // Preparo messaggio da inviare. DData[0]:=13; //0D HEAD 1 DData[1]:=3; //03 HEAD 2 DData[2]:=1; //01 HEAD 3 DData[3]:=1; //01 ID DData[4]:=1; //01 COMMAND 1 = NEXT 2= ON DEMAND DData[5]:=1; //01 NUMERO PAGINA O NEXT SE 1 E COMMAND 1 DData[6]:=0; //00 DData[7]:=0; //00 END_IF; // ------------------------------------------------------------------------- // ESEGUO INVIO MESSAGGIO // ------------------------------------------------------------------------- // Controllo variazione comando start. IF (Start <> Pulse) THEN Pulse:=Start; //Pulse // Eseguo invio solo su fronte attivazione. IF (Start) THEN i:=Sysfwrite(ADR(DData), 8, 1, Serial.File); END_IF; END_IF; // [End of File]Aggiungo che utilizzando un nostro sistema SlimLine è possibile con il FB FPTClient eseguire il trasferimento automatico di un file da un server FTP (Esempio il pannello operatore) su di un’altro server FTP (Esempio il PC).
In fondo alla pagina di manuale si trova il programma FTPFileTransfer che esegue proprio questa operazione tra due pannelli operatore Weintek. Basta copiare ed incollare l’esempio nel proprio programma LOgicLab ed eseguirlo.
Con i pannelli iE/xE/iP puoi usare il server di stampa remota, installi il programma EasyPrinter (Lo trovi nella cartella di installazione di EasyBuilder) su di un PC in rete, tramite l’oggetto Backup puoi inviare il file direttamente al PC che lo salverà in una cartella predefinita.
Per quanto riguarda la serie CMT usando un action trigger è possibile trasferire file presenti su una USB connessa al pannello ad un server FTP di un PC in rete tramite la funzione trasferimento file.
