Problema di comunicazione con CPU SlimLine

[Anonimo]

Volevo segnalare un problema di comunicazione riscontrato su una configurazione hardware da noi recentemente messa in funzione, e per richiedere supporto tecnico nell’individuazione della causa. Configurazione del sistema

• CPU MPS055A200, comunicazione via Ethernet
• 5 slot totali così composti:
• 2x PCB124D200
• 1x PCB124B100
• 2x PCB126C130 (schede analogiche)

Durante il normale funzionamento del nostro software interno, che effettua operazioni di lettura e scrittura sui PIN digitali (ingressi/uscite), si verifica in modo intermittente una perdita di connessione con la CPU, che rende impossibile l’esecuzione dei comandi fino al ripristino della comunicazione.

Abbiamo effettuato test disconnettendo le due schede analogiche PCB126C130: in questa configurazione il problema sembra non manifestarsi, anche prolungando i tempi di test. Questo ci porta a sospettare che il problema sia correlato in qualche modo alla presenza/gestione delle schede analogiche, anche se al momento non operiamo letture/scritture dirette su di esse durante i test in questione.

La comunicazione con il PLC avviene tramite una libreria sviluppata internamente in C#, già utilizzata con successo su altre configurazioni simili da noi installate (sempre con CPU MPS055A200 e schede digitali PCB124). La differenza principale rispetto a tali configurazioni funzionanti è quindi il numero superiore di slot occupati (5 contro un numero inferiore) e, soprattutto, la presenza delle due PCB126C130.

Sono noti casi analoghi di perdita di connessione legati alla presenza di schede analogiche PCB126C130, anche in assenza di comunicazione attiva con esse?

Esistono limiti noti riguardo al numero massimo di slot/schede gestibili in comunicazione Ethernet con la CPU MPS055A200, o configurazioni minime di polling/timeout da rispettare in presenza di schede analogiche?

Esistono eventuali parametri di configurazione (timeout, ciclo di scansione, buffer di comunicazione) che potrebbero necessitare di una regolazione specifica per questa configurazione?

E’ disponibile un tool diagnostico o un log di sistema della CPU che possa aiutarci a isolare la causa della disconnessione.

[Sergio Bertana]

Se ti colleghi in telnet al sistema con il comando Syslog puoi trovare una indicazione del tuo problema. Ma molto probabilmente la causa è che nel tuo sistema vi sono 2 schede di acquisizione analogica PCB126C130 che gestiscono ciascuna 10 ingressi analogici per un totale di 20 ingressi analogici.

Per l’acquisizione degli ingressi analogici si utilizza il FB SysGetAnInp, ora probabilmente tu hai gestito tutte le acquisizioni consecutivamente in un program che immagino sia eseguito in task Slow. Come indicato nel capitolo Multiplexing acquisizione del manuale del FB l’accesso al modulo di acquisizione sul bus di estensione richiede un tempo variabile tra i 300-500uS. Quando si esegue l’acquisizione di molti canali nel tuo caso 20 è richiesto un tempo totale di 6-10mS. Siccome il task Slow è di default eseguito ogni 10mS può succedere che nel caso peggiore il tempo di esecuzione del task superi i 10mS e questo provoca l’arresto della esecuzione programma ed un riavvio dello stesso con conseguente perdita della comunicazione.

Quindi per risolvere puoi multiplexare le acquisizioni come indicato nell’articolo, comunque è preferibile gestire le acquisizioni analogiche in un program eseguito in task Back che non essendo real time i 20mS di esecuzione non creano nessun problema.

[Autore]

Post