[Sergio Bertana]

Credo che tutti gli eventi di allarme siano collegati a variabili BOOL sul programma PLC, variabili che tu sai in che condizione generano l’allarme. Mi spiego meglio può essere che l’allarme si generi se una certa variabile và in stato TRUE (Condizione forse più corretta) oppure se và in stato FALSE.

Intanto gestisci una variabile “OnMaintenance” di tipo BOOL che puoi settare da terminale o che setti da debug con LogicLab. Poi in tutti i rami di programma dove viene gestita la variabile BOOL di allarme se allarme attivo TRUE inserisci in AND negato la variabile OnMaintenance, se allarme attivo FALSE inserisci in OR la variabile OnMaintenance. In questo modo l’allarme non viene più attivato.

[Sergio Bertana]

Direi che hai descritto in modo dettagliato l’applicazione vediamo una idea di come realizzarla.

Intanto per l’interconnessione dei sistemi utilizzerei le rete ethernet che oltre ad essere più veloce permette di veicolare anche l’accesso ai sistemi remoti per la programmazione ed il test. Considerando che hai un pannello operatore avendo tutti i dispositivi in rete utilizzando EasyAccess sul pannello potrai eseguire l’accesso anche da remoto via Internet garantendo una facile manutenzione.

Per i 4+4 comandi ai motori utilizzerei pulsanti virtuali sul pannello e visto che non ti servono le analogiche nella postazione di comando puoi eliminare il modulo mixed I/O.

Utilizzando la connessione ethernet puoi utilizzare il modulo CPU MPS056B110 al posto del MPS054C110 con un risparmio di costi, che visto il numero di stazioni è interessante. Quindi come hardware avremo:

Postazione comando:

• MPS056B110 SlimLine Modulo CPU Cortex M7 Compact Ethernet LLab Base Relè
• PSP008A300 MDR-60-24 24Vdc 60W Power Supply

Stazione remota:

• MPS056B110 SlimLine Modulo CPU Cortex M7 Compact Ethernet LLab Base Relè
• PCB122D100 SlimLine Modulo I/O Mixed Signal Relé + RS232
• CBL045A000 Cavo estensione I2C SlimLine (5cm) (NON passante)
• PSP008A300 MDR-60-24 24Vdc 60W Power Supply

In riferimento al programma da realizzare, ipotizzo di avere sul PLC in postazione comando il FB DataTransfer in modalità client che si connette alla stazione selezionata dal pannello. Sulle stazioni è in esecuzione il FB DataTransfer in modalità server, questo permette di scambiare i dati tra di loro gestendo i comandi dell’operatore e visualizzando la posizione del motore tramite l’ingresso 4-20mA.

A fini diagnostici il PLC in postazione comando tramite il FB SysPing continuerà ad eseguire il ping delle stazioni permettendo in caso di errore di segnalarne la mancanza con allarmi visualizzabili sul pannello.

[Sergio Bertana]

In teoria quello che chiedi è fattibile, bisogna fare dei test per verificarne l’effettiva fattibilità, quindi non ti resta che armarti di buona volontà e provare. Devi utilizzare il FB HTTPClient, ecco alcune dritte riferite a programma di esempio ST_HTTPClient_ToFile.

Per la connessione alla telecamera seguendo l’esempio di Arduino devi modificare:

TCPClient.PeerAdd:=ADR('IP TELECAMERA'); //Peer address
TCPClient.PeerPort:=81; //Peer port

HTTPRq.RMethod:=HTTP_REQUEST#HTTP_GET; //HTTP request method
HTTPRq.Page:=ADR('snapshot.cgi'); //Web page
HTTPRq.Request:=ADR('user=NOMEUTENTE&pwd=PASSWORD'); //Request string

Se la connessionew è Ok in HTTPStatus avrai di ritorno il codice 200. Nel codice Arduino non vedo la richiesta dell’immagine, quindi suppongo che alla connessione la telemera ti ritorni immediatamente un flusso dati binario che tu puoi salvare su file nello stesso modo in cui lo salva il programma di esempio.

La parte di esempio che esegue il salvataggio dell’header ricevuto dalla telecamera (riferimenti ad HFile) la puoi eliminare. L’header ritornato lo puoi analizzare comodamente dalla console di spionaggio.

[Sergio Bertana]

Il parametro PHBeatTime serve a gestire il meccanismo di Consumer heartbeat. Impostando un tempo nel parametro PHBeatTime (Producer Heartbeat Time, in millisecondi), il nodo viene configurato per controllare la ricezione del messaggio dal nodo master (Registro 1016h Consumer Heartbeat Time). Se ogni tempo impostato +50mS non viene ricevuto il messaggio il nodo slave và in errore, il comportamento in caso di errore può essere configurato.

Questo meccanismo permette di settare ad una condizione di sicurezza predefinita il dispositivo di nodo slave nel caso non venga ricevuto dal nodo master il messaggio di heartbeat, condizione che potrebbe verificarsi se si interrompe la connessione CAN tra il master ed il dispositivo di nodo.

Ora visto che non la stai utilizzando puoi sicuramente lasciarlo settato a 0. Ma attenzione se non utilizzi l’heartbeat nel caso di sconnessione del nodo dal master le eventuali uscite digitali sul modulo rimarranno attive.

[Sergio Bertana]

Ho ripreso in mano il vecchio progetto e pensando alla tua esigenza di gestire più sensori in I2C localizzati distanti dal sensore di acquisizione ho utilizzato un modulo 817 con 4 optoisolatori che si trova a pochi euro su moltissimi siti in Internet. Collegando gli I/O di un nostro modulo di estensione statico come questo, è possibile arrivare al modulo con 2 ingressi e 2 uscite digitali con segnali a 24Vdc aumentando l’immunità al rumore.

Il modulo provvede ad abbassare il livello del segnale ai 5Vdc per il sensore, un alimentatore a 5Vdc fornirà la tensione di alimentazione al sensore e tramite due resistenze di pull-up da 2200Ohm fornirà il livello alto ai segnali Clock e Data del bus I2C. Sul modulo 817 ho cortocircuitato (Resistenza oOhm) alcune resistenze (Vedi schema elettrico).

Disponendo di molti I/O digitali con un solo modulo di estensione e un isolatore per ogni sensore potrai acquisire tutti i sensori di cui necessiti.

[Sergio Bertana]

Ingressi analogici differenziali:

Misurano la differenza di tensione tra due punti, anziché la tensione rispetto a un punto di riferimento comune (come la massa). Sono ideali per ambienti con rumore elettrico elevato, poiché i disturbi di modo comune (rumore che colpisce entrambi i fili allo stesso modo) vengono eliminati. Eccone i vantaggi:

• Elevata reiezione del rumore di modo comune (CMRR).
• Maggiore precisione in ambienti rumorosi.
• Riduzione delle interferenze di terra.

Ecco le applicazioni comuni:

• Misure di segnali a basso livello in ambienti industriali.
• Sensori remoti con lunghi cavi.

Ingressi analogici in modo comune (single-ended)

Misurano la tensione di un singolo punto rispetto a un punto di riferimento comune, solitamente la massa del sistema. Sono più semplici e meno costosi degli ingressi differenziali. Eccone gli svantaggi rispetto agli ingressi diffeenziali:

• Suscettibili al rumore elettrico e alle interferenze di terra.
• Minore precisione in ambienti rumorosi.

Ecco le applicazioni comuni:

• Misure di segnali ad alto livello in ambienti a basso rumore.
• Applicazioni di consumo e hobbistiche.
• Sistemi in cui il rumore non è un problema significativo.

In sintesi gli ingressi differenziali offrono una maggiore precisione e reiezione del rumore, ma sono più costosi. Gli ingressi in modo comune sono più semplici ed economici, ma sono più suscettibili al rumore. La scelta tra i due tipi di ingressi dipende dai requisiti dell’applicazione, in particolare dal livello di rumore elettrico presente nell’ambiente.

In pratica per acquisire segnali analogici di valore molto basso (Range 0-1V) la soluzione preferibile è l’ingresso differenziale, mentre con valori di tensione più elevati o per acquisire segnali analogici molto vicini al modulo di acquisizione si può efficacemente utilizzare l’ingresso in modo comune.

[Sergio Bertana]

Come dicevi nel manuale trovi lo schema di collegamento di una RTD con 2 ingressi in tensione, se vuoi acquisire i 4-20mA dovrai utilizzare la resistenza di shunt da 62Ohm connessa tra l’ingresso analogico e la massa. Ora con 62Ohm a 20mA avremo 1,24V quindi dovrai rimuovere il ponticello sull’ingresso.

Quando si usa questa configurazione occorre fare attenzione alla connessione verso GND, rimuovendo LK59 il pin 1 di P12 non è più il segnale GND ma diventa un igresso di sense per la corrente di alimentazione delle RTD. Quindi il riferimento GND lo si deve andare a prendere dal pin 2 o 3 di P9.

Dovendo acquisire un trasduttore a 2 fili dovrai alimentare il trasduttore fornendo la tensione al suo ingresso positivo con un alimentatore esterno (Puoi utilizzare anche lo stesso alimentatore che alimenta il sistema) portando il suo negativo al riferimento GND (Pin 2 o 3 di P9) vedi schema elettrico.

[Sergio Bertana]

L’errore a cui fai riferimento indica che il controller CAN su ricezione di un messaggio ha trovato il suo buffer di ricezione pieno quindi ha perso il messaggio.

Il fatto che ti capiti dopo 15 minuti dall’accensione si collega al tempo di funzionamento in demo del FB che è di 15 minuti. Infatti dopo questo tempo il FB non estrae più i dati dal buffer d i ricezione CAN.

Ho modificato il FB CANOpenMaster_v1 in modo che anche dopo il tempo di funzionamento demo estragga comunque i dati dal buffer di ricezione CAN in modo da evitare l’errore. La versione modificata del FB sarà distribuita con il nuovo package di librerie che per il momento è disponibile nella versione beta Pck055a05_.

Mi lascia perplesso che dici ” la Tx funziona sempre” questo mi fà pensare che tu abbia correttamente licenziato il FB quindi non dovrebbe essere lo scenario che ho descritto. Ha provato a vedere con la console di spionaggio che informazioni ti ritorna il FB ?

Per aeesere sicuro che il codice di licenza sia corretto, devi verificare il ritorno della funzione SysPCodeVerify se torna TRUE il codice di licenza è corretto.

[Sergio Bertana]

Il problema è nell’aver settato l’opzione Strict pointer check nel menù Project->Options->Code generation. Questa opzione che per sicurezza viene settata di default effetua il controllo sul tipo di pointer segnalando errore quando si valorizza un pointer con un indirizzo di variabile diversa dal suo tipo.

La variabile ChPtr definita come pointer ad USINT la valorizzi con l’indirizzo di una stringa.

ChPtr:=ADR(DString); //Character pointer

Per soluzionare puoi disabilitare lo Strict pointer check, ma la soluzione più corretta è utilizzare eTO_POINTER nel modo:

ChPtr:=eTO_POINTER(ADR(DString)); //Character pointer

eTO_POINTER() trasforma l’indirizzo in un puntatore a void ePVOID che essendo un tipo diremmo oggi “fluido” viene accettato da tutte le assegnazioni.

[Sergio Bertana]

Aggiungo che vista la tua esigenza di acquisire più sensori e magari a distanze superiori ai 1 o 2 metri, posso consigliare di utilizzare il FB I2CBusManager con I2CMode:=1. In questo modo i segnali del bus I2C sono gestiti utilizzando una routine software con degli I/O digitali, la gestione del bus ha frequenze decisamente inferiori ma con segnali optoisolati dal sistema. Questo permette di aumentare molto la distanza garantendo anche una immunità ai disturbi.

Anche in questo modo avresti il problema dell’unico sensore per ogni bus (Visto che l’indirizzo è fisso), ma utilizzando ad esempio il modulo MPS056B310 con 4 ingressi e 4 uscite potresti pilotare 2 diversi bus I2C ed acquisire 2 sensori.

In alternativa si pootrebbe realizzare un FB ad-hoc dove si utilizza un ingresso ed 1 uscita per il segnale DATA e con 3 uscite si possono gestire 3 segnali CLOCK da utilizzare per il comando di 3 sensori. In questo modo un unico modulo CPU potrebbe acquisire 3 sensori.

[Sergio Bertana]

Abbiamo già affrontato l’acquisizione di questi sensori vediamo di rispondere alle tue domande. Ipotizzando di collegare il sensore al bus di espansione del ns modulo CPU per l’acquisizione utilizzeremo la funzione SysI2CWrRd.

1. I sensori hanno interfaccia I2C ma come si evince dal manuale utente hanno indirizzo fisso (16#0A) quindi è possibile collegare un solo sensore al bus.
2. Essendo il bus I2C delle estensioni dei ns moduli CPU, un bus a 400Khz la distanza massima ipotizzabile in sicurezza potrebbe essere 1 o 2 metri.
3. Avendo il sesore unico indirizzo si può collegare 1 solo sensore.

Ecco il programma che abbiamo realizzato per l’acquisizione di un sensore a 16 zone. Nell’array Pn sono presenti le 16 temperature delle zone acquisite dal sensore.

PROGRAM D6TMeasure

VAR
    i : UDINT; (* Auxiliary variable *)
    CaseNr : USINT; (* Program case *)
    TimeBf : UDINT; (* Time buffer (uS) *)
    Errors : ARRAY[0..1] OF UDINT; (* Error counter *)
    I2CWrite : ARRAY[0..1] OF BYTE; (* I2C write buffer *)
    I2CRead : ARRAY[0..63] OF BYTE; (* I2C read buffer *)
    PTAT : REAL; (*Reference temperature (°C) *)
    Pn: ARRAY[0..15] OF REAL; (* Temperature points (°C) *)
END_VAR

// *****************************************************************************
// PROGRAM "D6TMeasure"
// *****************************************************************************
// Acquires a Omron MEMS Thermal Sensors D6T.
// -----------------------------------------------------------------------------

    // -------------------------------------------------------------------------
    // PROGRAM CASES
    // -------------------------------------------------------------------------
    // Program cases management.

    CASE (CaseNr) OF

        // ---------------------------------------------------------------------
        // Conversion command "Single Shot Mode high repeatability" clock
        // streching disabled.

        0:
        I2CWrite[0]:=16#4C; //Comando scrittura
        IF NOT(SysI2CWrRd(Address:=16#0A, WrBytes:=1, WrBuffer:=ADR(I2CWrite), RdBytes:=0, RdBuffer:=NULL)) THEN
            Errors[0]:=Errors[0]+1; //Error counter
            CaseNr:=0; //Program case
            RETURN;
        END_IF;

        // Save time to wait.

        TimeBf:=SysGetSysTime(TRUE);
        CaseNr:=CaseNr+1; //Program case

        // ---------------------------------------------------------------------
        // Wait conversion complete (Max time oh high repeatability 15 mS).

         1:
         IF ((SysGetSysTime(TRUE)-TimeBf) < 500000) THEN RETURN; END_IF;

        // Read the conversion results.

        IF NOT(SysI2CWrRd(Address:=16#0A, WrBytes:=0, WrBuffer:=NULL, RdBytes:=35, RdBuffer:=ADR(I2CRead))) THEN
            Errors[1]:=Errors[1]+1; //Error counter
            CaseNr:=0; //Program case
            RETURN;
        END_IF;

        // Acquire the reference temperature.

        PTAT:=TO_REAL(TO_INT((TO_UINT(I2CRead[1])*256+I2CRead[0])))/10.0;

        // Acquire the Pn temperatures.

        FOR i:=0 TO 15 DO
            Pn[i]:=TO_REAL(TO_INT((TO_UINT(I2CRead[3+(2*i)])*256+I2CRead[2+(2*i)])))/10.0;
        END_FOR;

        CaseNr:=0; //Program case
    END_CASE;

// [End of file]

[Sergio Bertana]

Il modem Telit EGX81-W a differenza dei modelli precedenti non ha l’auto baudrate, di default la comunicazione è settata a 115200, n, 8, 1. Quindi devi modificare il programma definendo il corretto baudrate (Ho corretto l’esempio portando da 9600 a 115200 il settaggio del baudrate). Ricordati di disabilitare il PIN sulla SIM.

Il modem inoltre non trasmette se il segnale CTS è basso, quindi occorre utilizzare il corretto cavo di connessione al modulo SlimLine, consiglio l’adattatore modem CBL055 ed il cavo di estensione CBL057. Tramite questi accessori il segnale DTR in uscita dal modulo CPU viene connesso sia al DTR (Pin 4) che al CTS (Pin 7) del modem.

Per individuare i problemi consiglio di attivare lo spionaggio e di verificare i risultati nella console di spionaggio. Ecco i risultati:

08:43:39.271687|ModemCore:Lg|Wait again:14 (S)
08:43:44.273058|ModemCore:Lg|Wait again:9 (S)
08:43:49.273750|ModemCore:Lg|Wait again:4 (S)
08:43:54.262965|ModemCore:Lg|----------------------------------------------[Modem power on]-
08:44:04.264664|ModemCore:Tx|AT[0D]
08:44:04.370939|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:04.372770|ModemCore:Tx|AT[0D]
08:44:04.478925|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:04.482193|ModemCore:Tx|AT&F[0D]
08:44:04.612816|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:04.614626|ModemCore:Tx|ATE0[0D]
08:44:04.721050|ModemCore:Rx|ATE0[0D][0D][0A]OK[0D][0A]
08:44:04.723145|ModemCore:Tx|AT+CMEE=2[0D]
08:44:04.828856|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:04.830659|ModemCore:Tx|ATV1[0D]
08:44:04.936732|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:04.938732|ModemCore:Tx|ATX3[0D]
08:44:05.044667|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:05.046470|ModemCore:Tx|AT&D2[0D]
08:44:05.152692|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:05.154843|ModemCore:Tx|AT+CNMI=0,0,0,0,1[0D]
08:44:05.276665|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:05.278483|ModemCore:Tx|AT+CMGF=1[0D]
08:44:05.384800|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:05.386806|ModemCore:Tx|AT+CSMS=0[0D]
08:44:05.500182|ModemCore:Rx|[0D][0A]+CSMS: 1,1,0[0D][0A][0D][0A]OK[0D][0A]
08:44:05.502472|ModemCore:Tx|AT+CPMS="SM","SM","SM"[0D]
08:44:05.616033|ModemCore:Rx|[0D][0A]+CPMS: 0,50,0,50,0,50[0D][0A][0D][0A]OK[0D][0A]
08:44:05.617653|ModemCore:Lg|-------------------------------------------------[Modem check]-
08:44:05.620538|ModemCore:Tx|AT[0D]
08:44:05.725870|ModemCore:Rx|[0D][0A]OK[0D][0A]
08:44:05.729313|ModemCore:Tx|AT+CSQ[0D]
08:44:05.842675|ModemCore:Rx|[0D][0A]+CSQ: 21,99[0D][0A][0D][0A]OK[0D][0A]
08:44:05.846344|ModemCore:Tx|AT+CREG?[0D]
08:44:05.953668|ModemCore:Rx|[0D][0A]+CREG: 0,1[0D][0A][0D][0A]OK[0D][0A]
08:44:05.957201|ModemCore:Tx|AT+COPS?[0D]
08:44:06.073693|ModemCore:Rx|[0D][0A]+COPS: 0,0,"WINDTRE",3[0D][0A][0D][0A]OK[0D][0A]
08:44:21.073883|ModemSMSReceive:Lg|---------------------------------[Check SMS received messages]-
08:44:21.077098|ModemCore:Tx|AT+CMGR=0[0D]
08:44:21.187832|ModemCore:Rx|[0D][0A]OK[0D][0A]

[Sergio Bertana]

Dallo screenshot non vedo dove finisce il segnale di Done, ma a parte questo c’è sicuramente una stranezza nella gestione dell’Enable, ti consiglio di non negare l’ingresso di Enable e di utilizzare in serie al segnale Connected un contatto normale chiuso di Done. In risposta alle tue domande:

1. L’utilizzo della FB ModbusMaster è corretto, il programma deve essere eseguito in task Back.
2. Come indirizzo IP e come porta devi definire quella richiesta dal dispositivo che interroghi. La porta 502 è la porta stanndard utilizzata dal protocollo Modbus/TCP. Quindi se così dice la specifica del tuo dispositivo è corretto, anche perchè se l’IP o la porta fossero errati non avresti mai l’uscita di Connected.
3. Il tempo di delay dipende da quanto è veloce a rispondere il dispositivo che interroghi. 250mS mi sembra già un tempo abbastanza lungo.
4. RxSize e TxSize vanno dimensionati in base alla lunghezza del frame di comando e del frame di risposta del comando Modbus. Tu leggi 2 registri (4Bytes) a cui aggiungi l’header (6 bytes). In totale meno di 16 bytes.
5. Visto che hai dei timeout puoi esagerare con il tempo di Timeout (1S), tanto per vedere se è davvero un problema di programma o se è il tuo dispositivo che non riesce a rispondere in 250mS.

Tieni comunque presente che 28 errori su quasi 19000 pacchetti scambiati, non è molto, anche se in Modbus/TCP solitamente si hanno pochissimi errori.

[Sergio Bertana]

C’è un po di confusione…

Le FB ModbusMaster collegate allo stesso SysTCPClient.File devono essere gestite in cascata, il Done della prima sull’Enable della successiva e così di seguito fino all’ultima FB il cui Done negato va connesso all’Enable della prima.

Non c’è nessun legame tra le FB Modbus collegate al File di FB SysTCPClient diverse, ognuna di esse opera dialogando con il proprio dispositivo e non interferisce con le altre. E’ proprio questo il vantaggio di poter operare in parallelo.

Dal tuo screenshot, vedo un contatto di Done di una FB ModbusMaster sull’Enable della prima, ma non capisco se è il Done dell’ultima FB della cascata di quelle connesse a quel SysTCPClient. Inoltre si tratta di un Done normale, mentre dovrebbe essere un Done negato.

L’errore che tu vedi è proprio indicativo di più FB Modbus master che sono eseguite contemporaneamente sullo stesso File, in pratica una “Ruba” i dati all’altra che riceve un transaction identifier errato. Credo che i tuoi problemi sono tutti nella errata gestione delle cascate.

[Sergio Bertana]

L’Auto-APN consente al router di analizzare la scheda SIM e selezionare l’APN corretta da un elenco precaricato nel firmware del router. Ciò significa che il router può essere spedito in tutto il mondo senza richiedere una configurazione APN per le SIM che saranno inserite.

Il router acquisisce il Mobile Country Code (MCC) ed il Mobile Network Code (MNC) dalla SIM inserita e erca in una tabella all’interno del proprio firmware l’APN relativa alla SIM inserita. Siccome si aggiungono nuovi operatori  ad ogni giorno è evidente che la tabella presente nel firmware del router potrebbe non essere aggiornata con i nuovi operatori. Eseguendo un update del firmware si provvederà anche ad aggiornare l’elenco degli operatori.

Tra i routers da noi commercializzati l’unico modello che supporta l’Auto-APN è il Router cellulare industriale 4G LTE R200, nel caso l’APN della SIM inserita non sia presente nel firmware è possibile da pagina web inserirla manualmente. Il router è basato sul sistema operativo OpenWRT permettendo così anche l’installazione di moltissimi package software disponibili.

Il package APN Database webui permette di visualizzare su pagina web tutti providers mappati nel firmware del router permettendone la modifica e/o la definizione di nuovi operatori.

Tra i package più interessanti citiamo OPC-UA server e client, ZeroTier, AWS IoT Core, Azure IoT Hub, ecc…

[Autore]

Post