Risposte nei forum create
-
Post
-
La funzione STO se attiva evita la partenza inaspettata del motore quando attiva disabilita l’uscita dell’inverter.
Per attivare lo STO occorre scollegare dal +24Vdc i segnali H1 ed H2 dell’inverter (Togliere i ponticelli precablati sui 2 morsetti rossi). A questo punto è possibile eseguire la connessione dei 2 segnali H1 ed H2 al +24Vdc utilizzando un relè o un pulsante di sicurezza. I 2 segnali vanno sempre connessi/disconnessi contemporaneamente.
All’intervento della funzione STO l’inverter và in allarme e normalmente dopo la riattivazione dello STO occorre eseguire un reset. Agendo sulla prima cifra delle centinaia del parametro P11.16 è possibile modificare il comportamento.
- 0xx, allarme STO bloccato: A seguito di una condizione STO è necessario un reset dell’inverter.
- 1xx: allarme STO sbloccato: L’allarme STO è disattivato automaticamente.
Lo schema è corretto, per completezza di risposta aggiungo alcune informazioni.
I 2 ingressi del modulo sono isolati galvanicamente tramite optoisolatori che accettano segnali sia positivi che negativi. Quindi puoi come nel tuo caso connettere il DICom a massa e pilotare gli ingressi con un segnale positivo, oppure collegare il DICom ad un segnale positivo e pilotare gli ingressi collegandoli a massa (Il range è 5-30Vdc, 7mA@24V).
Le 2 uscite digitali sono gestite con optoisolatori Mosfet, quindi puoi come nel tuo caso collegare il DOCom ad un segnale positivo e pilotare il carico in uscita collegato verso massa, oppure collegare il DOCom a massa e e pilotare il carico in uscita collegato verso un segnale positivo (Il range è 250mA@40V).
Le uscite OptoMOS non sono protette quindi per occorre proteggerle come hai fatto correttamente tu con un fusibile extrarapido da 250mA. Naturalmente se metti un fusibile sul comune limiti la corrente totale in uscita a 125mA per canale se entrambi i canali sono attivi contemporaneamente. Per sfruttare l’intera potenza in uscita puoi utilizzare un fusibile da 250mA per ogni canale.
Nessun problema solo che non capivo il nesso con le elettrovalvole…
Infatti il mio sufggerimento era di abilitare il FB parametrizzato per la scrittura solo quando serve scrivere, naturalmente tutto sarebbe molto più semplice lavorando in linguaggio ST e gestendo il programma in case con lo statement CASE.
TRovi molti programmi realizzati in questo modo puoi prendere spunto da esempi che trovi nel forum.
Mi sono un pò perso… si parlava di energy meter SDM120 ed ora saltiamo ad elettrovalvole…
Ma venendo alla tua domanda hai appreso come mettere in cascata più FB ModbusMaster per effettuare la lettura dei registri da diversi strumenti. Ora quando devi scrivere aspetti il Done dell’ultimo FB in cascata e anzichè ripartire con la sequenza togliendo l’Enable del primo, farai partire un un ulteriore FB ModbusMaster che configurerai di volta in volta per la scrittura del registro che ti occorre.
Per la connessione ai PLC Schneider M340/M580 puoi riferirti al manuale connessione PLC di cui ti allego estratto.
Attenzione il firmware della CPU del PLC deve essere 2.70 o superiore.
Premesso che non ho ben capito cosa vuoi ottenere… ma se vuoi mandare una eMail quando gli ingressi analogici vanno in fault basterà inviarla sul fronte di attivazione errore di acquisizione così avrai una sola mail indipendentemente dal tempo in cui stà in errore.
Per quanto riguarda le temporizzazioni io utilizzo sempre la funzione SysGetSysTime eseguendo il controllo su di un tempo di riferimento, e come detto prima la temporizzazione massima è di circa 70 minuti. Non capisco la tua perplessità sulla ripartenza del tempo, essendo un calcolo a riporto circolare funziona sempre correttamente. Certo l’unico controllo da fare è alla accensione dove dovrai memorizzare il tempo di riferimento. Il programma che ti posto sotto esegue l’inversione di BOut ogni 30 minuti.
VAR TimeBf : UDINT; (* Time buffer (uS) *) BOut : BOOL; (* Blink output *) END_VAR IF (SysFirstLoop) THEN TimeBf:=SysGetSysTime(TRUE); END_IF; IF ((SysGetSysTime(TRUE)-TimeBf) >= 1800000000) THEN TimeBf:=SysGetSysTime(TRUE); BOut:=NOT(BOut); END_IF;Nelle funzioni non viene allocata memoria, i parametri in ingresso, uscita e le variabili interne sono tipicamente appoggiati su registri e non su aree di memoria, quindi ci sono limitazioni sulla dimensione e sul riferimento agli stessi all’interno della funzione. Cito ad esempio l’impossibilità di utilizzare lo statement ADR riferito ad un parametro o variabile.
Nei FB invece viene allocata memoria per l’appoggio dei parametri e delle variabili e questo permette di utilizzare qualsiaso tipo di dato. Inoltre nei FB possono essere usati riferimenti a variabili globali di programma con la keyword EXTERN.
Ma se vuoi defire come parametro in ingresso da una funzione parametri di tipo definito da te, puoi passare il parametro come riferimento e non come valore indicando come tipo l’indirizzo della tua variabile. Ecco la definizione della funzione.
FUNCTION MyFun: BOOL VAR_INPUT In : @MYSTRUCT; END_VAR @In.V2:[email protected]; MyFun:=TRUE;Ecco il programma dove viene eseguita.
PROGRAM MyProgram VAR MyVar : MYSTRUCT; Res : BOOL; END_VAR MyVar.V1:=LREAL#10.0; Res:=MyFun(ADR(MyVar));L’ingresso Delay del FB ModbusMaster serve proprio a questo, in pratica terminato il comando modbus si attiverà per un loop di programma l’uscita Ok, che potrai usarla per la conversione dei dati, ma l’uscita Done si attiverà solo dopo il tempo definito in Delay.
Quindi se colleghi pù FB Modbus in cascata la seconda partirà dopo il tempo di delay della prima, la terza dopo il tempo di delay della seconda e così via. Fino all’ultima della cascata che dopo il tempo di delay definito farà ripartire la prima.
Non sbagli, ci sismo dimenticati di pubblicare sul sito per il download l’ultima versione della libreria eLLabLogLib. Ho provveduto a farlo quindi basterà scaricare la nuova versione di libreria ed importare il FB.
Probabilmente nel tuo progetto che hai incluso l’intera libreria eLLabUtyLib e questo comporta l’inclusione di tutti gli oggetti della libreria anche se non sono utilizzati nel tuo programma. Noi sconsigliamo di fare questo ma di includere solo gli oggetti che servono (Vedi articolo).
Altro consiglio… vedo che il testo dell’errore riporta il nome della funzione SysVsnprintf tutto in maiuscolo, questo è perchè non hai settato la flag Case sensivity nel progetto (Screenshot). Il consiglio è di settarlo in modo da mantenere il case sui simboli.
Il tuo problema è che stai compilando per un sistema XTarget12, mentre le nuove librerie sono sviluppate per sistemi XUnified, se tu avessi importato solo gli oggetti dalla vecchia libreria ora avresti potuto importare solo l’FB PIDMng_v2 continuando ad utilizzare i vecchi oggetti già importati nel tuo progetto.
Cosa fare, puoi eseguire un upgrade del sistema ad XUnified (Vedi articolo) oppure includere nel tuo progetto la libreria eLLabXUnifiedAdjLib che ti permette di utilizzare tute le nuove librerie (Vedi articolo).
Aggiungo che nel nuovo FB di gestione PID ho utilizzato calcoli in float a 64 bits quindi per utilizzarlo devi avere l’ultima versione di LogicLab che permette di utilizzare i numeri a 64 bits.
I sistemi Cortex M7 sono basati su di un sistema operativo real time sviluppato da noi e non possono eseguire applicativi.
Se vuoi utilizzare Node-RED sui nostri prodotti devi scegliere il modulo CPU MPS055 basato su Raspberry. nella zona knowledge trovi informazioni sulla installazione ed un esempio di utilizzo.
Per aggiornare i sistemi CortexM7 ad XUnified devi scaricare il PCK051.
Con la versione XUnified abbiamo risolto anche alcuni BUGs presenti su XTarget_12, il primo riguarda la risposta alle richieste GET sulle pagine dinamiche (Pagine con estensione htm) nella versione XTarget_12 venivano ritornate le informazioni di Cache-Control.
Cache-Control: max-age=300 ETag: "1612163484:149"
Questo forzava il caching della pagina da parte del browser e quindi non veniva più richiesta al server, per sopperire al problema nella richiesta get veniva aggiunto alla pagina un numero random per simulare richieste diverse.
Per quanto riguarda le richieste POST, nell’XTarget_12 viene eseguito un controllo case sensitive sull’header e questo a volte genera problemi di decodifica. Nell’XUnified il controllo ora e case insensitive.
Quindi per risolvere i tuoi problemi ti consiglio di eseguire l’upgrade del sistema a XUnified.
Buona l’idea di abbandonare XMLHttpRequest e di utilizzare le più moderne API Fetch, ho quindi provveduto a modificare gli esempi riportati nella knowledge.
Se scarichi l’esempio citato nell’articolo troverai una pagina gestita con l’API Fetch in cui si aggiornano in AJAX i valori con richieste in GET e si impostano valori in POST.
Ho provato a scrivere un esempio del programma…
VAR i : UDINT; (* Auxiliary variable *) IDx : USINT; (* Index *) ArrayA : ARRAY[0..143] OF BYTE; (* Array appoggio lettura Modbus *) ArrayB : ARRAY[0..36] OF REAL; (* Array appoggio valori acquisiti *) END_VAR // Simulo i valori acquisiti dallo strumento. i:=Sysmemmove(ADR(ArrayA[0]), ADR(16#42C81234), 4); //Carico 100.036 i:=Sysmemmove(ADR(ArrayA[4]), ADR(16#44022BC7), 4); //Carico 520,684 i:=Sysmemmove(ADR(ArrayA[140]), ADR(16#4733B0D8), 4); //Carico 46000,844 // Eseguo la conversione in REAL. FOR IDx:=0 TO 35 DO i:=BEArrayToVar(REAL_TYPE, ADR(ArrayB[IDx]), ADR(ArrayA[IDx*4])); END_FOR;Per il calcolo dei valori in esadecimale ho utilizzato un convertitore IEE754 on line.
