sistemi di controllo e acquisizione per nuovo progetto

[labale]

Buongiorno a tutti,

il reparto di R&D presso il quale lavoro sta sviluppando un nuovo progetto di creazione di un bench test per giranti marine; trattasi di "stelle" in gomma che girano all'interno di case in ottone per raffreddare i motori delle barche di qualisasi dimensione. Il progetto prevede che ogni postazione sia dotata di vasca con controllo della temperatura tramite chiller a cui viene mandato un setpoint tramite modbus, un motore brushless con encoder e relativo azionamento in ethercat, un sensore di pressione in tensione , un flussostato anch'esso con uscita in tensione e due elettrovalvole. Questo per quanto riguarda le postazioni. Per quanto riguarda le esigenze di software è stato creato un prototipo che consente di creare programmi in maniera interattiva tramite il trascinamento di icone rappresentanti delle funzioni, faccio un esempio: a tre minuti si mette una funzione "apri valvola 1"- a 5 chiudi "valvola 1" ecc.. Per le caratteristiche che possiede il programma andrà sviluppato o in C o in Python. Il problema è che non sappiamo quale sistema utilizzare per acquisire i dati e comandare l'hardware, si era pensato in un primo tempo national instruments ma le frequenze di campionamento di cui necessitiamo sono al max 100Hz quindi ci è sembrato eccessivo. Poi una soluzione con PLC Omron ma non so se si possa creare un programma in linguaggio da compilatore (C o Python) da interfacciare in maniera facile con il PLC integrandone le funzioni all'interno del codice facendolo funzionare solo da slave. So che ci sono molte altre soluzioni tra national e PLC ma non ne ho conoscenza, qualcuno mi potrebbe suggerire altre soluzioni e consigliarmi tramite la propria esperienza? 

Grazie

[Livio Orsini]

Guarda il catalogo National Instruments.

[max81]

Potresti prendere in considerazione Beckhoff, hanno delle schede di acquisizione analogiche ad alta velocità, inoltre visto che utilizzi l'ethercat puoi comunicare con gli azionamenti senza problema.
https://www.beckhoff.com/english.asp?scientific_automation/default.htm

 

Per comunicare con il PLC ci sono varie strade, DLL per .Net fornite da beckhoff, OPC Server, Modbus TCP.

[ETR]

Ciao Labale, scusa la franchezza, ma sai che ho capito poco. Tralasciando il coordinamento dei vari componenti e presupponendo un ingerenza del comprato software, secondo me andava focalizzato il tutto su cosa dovevi acquisire e non con cosa. Ci si è persi nel software, quando, come suggerisce Livio, National avrebbe avuto soluzioni chiavi in mano (quasi) ma con hardware dedicato.

 

Se poi ti avesse spaventato la programmazione con Labview, avremmo optato sul PLC, sempre non considerando ancora la parte software, ma le esigenze di campionamento, quindi deciso l'hrdware avremmo sviluppato tutto su questa piattaforma.

A questo punto il suggerimento di Max è corretto e probabilmente derivante dalla citazione di Ethercat, io potrei dirti B&R, ma comunque non abbiamo ancora definito che esigenze tu abbia.

 

Secondo me la cosa più semplice, sarebbe un PC, tralasciando qualsiasi elemento PLC, abbinando schede di acquisizione dedicate ed al massimo schede IO da PLC in modbus TCP. Non stiamo parlando di realtime, dato che sono degli stress test e quindi una volta finalizzato il comando dell'azionamento che procederà autonomamente, devi solo acquisire, acquisire ecc.

 

Su banchi di test, la distinzione di base è : se necessiti di prestazioni, hardware dedicato e national (che adesso ha anche prodotti più accessibili di anni fa). Se necessiti di integrare più funzioni di real time, con motion, il PLC gestisce il codice di basso livello e poi un PC acquisisce i dati nella maniera che più ti aggrada (meglio sarebbe ridurre al minimo le conversioni e semplificare avendo direttamente accesso al dbase, come SQL o MySQL, dal PLC).

 

La parte di C o Phyton ti serve per l'interfaccia e la generazione dei pattern di test ? Con la nuova versione di Automation Studio, la B&R tramite i componenti mapp ti avrebbe facilitato se non eliminato tutta la parte sviluppata. Io ti parlo di questa ma ci saranno anche altre soluzioni di altre case.

 

Considera solo che : alla vasca vai in modbus, presumo RTU (quindi su un regolatore stand alone), all'azionamento in Ethercat, sulle analogiche magari andrai con delle schede dedicate dal PC in USB e al PLC (che magari gestirà i digitali) dovrai andarci magari con un protocollo dedicato, oppure diciamo Modbus TCP se scegli bene.

 

Non considerare le mie osservazioni come critiche fini a se stesse, ma purtroppo da queste situazioni ci sono già passato e lo sviluppo interno non è sempre la via più economica.

 

Comunque, qualsiasi sia la piattaforma che più ti aggrada, cerca dei gateway modbus TCP, capaci di metterti a disposizione su registri pre determinati, direttamente senza programmazione, le variabili analogiche e digitali. Con librerie opensource Modbus TCP, potresti arrivare ad un buon compromesso con quanto hai già sviluppato perchè come ti dicevo non dovresti avere problemi con il realtime del PC. Per l'RTU un convertitore USB-485 ti costa una cippa e l'unico ostacolo da gestire un po' è l'azionamento. Se non hai la possibilità di arrivare direttamente con Modbus TCP sull'oggetto, tra la scheda ethercat per il PC e prendere un convertitore ethercat/modbus tcp, considera alcmeno l'unificazione del drive di comunicazione del tuo sistema.

 

Ciao

 

 

[labale]

Buongiorno, grazie delle risposte. Grazie a tutti per le risposte. 

Rispondo a ETR:

la parte in Python o C serve per costruire una GUI ergonomica ove monitorare l'andamenteo delle prove e costruire dei pattern di test tramite oggetti grafici (come in alcune presse ENGEL). National è una soluzione che ho considerato ma è costosa, anche se il costo maggiore è dato dalla programmazione. Quello che non capisco dal tuo post è se in parole povere dal programma riesco a comandare il PLC facendogli eseguire delle operazioni direttamente chiamando delle funzioni all'interno del programma. Non ho visto librerie per C o C++ sul sito Omron, al contrario di National che ha di tutto. E' possibile? Cosiderate che un PLC potente di Omron che soddisfa tutte le nostre esigenze in termini di acquisizioni costa circa 60% meno di un elemento NI. Ripeto, a noi 250KHz/sec di frequenza acquisizione non ci serve a nulla.

 

[Livio Orsini]

Quote

Non ho visto librerie per C o C++ sul sito Omron,

 

Son pochissimi i PLC che si possono programmare in "C"; è una questione commerciale per obbligare il cliente alla fedeltà.

Quote

se in parole povere dal programma riesco a comandare il PLC facendogli eseguire

 

Il vero problema è tra il PLC ed il dispositvo HMI/SCADA. Se quest'ultimo ha resisdente i driver per interfacciarsi con il PLC non ci sono problemi. Ovviamente è necessario che il programma PLC preveda l'attivazione di determinate funzioni tramite comandi da HMI. In genere è sufficiente che lo HMI alzi o abbassi un flag nel PLC.

[ETR]

Ciao Labale, se guardi B&R e Beckoff accettano programmazione in C e/o C++

 

B&R

 

Beckoff

Ciao

[labale]

Grazie Livio per la risposta tecnica. 

ETR ho visto!!architettura Intel i! Ho già chiamato il servizio clienti per una visita del loro agente di zona. Hanno un metodo simile a national che consente di riutilizzare del codice esistente. Fantastico.

Livio, un ingegnere mi ha descritto la situazione anche con i bus di comunicazione dei vari produttori..Vi terrò aggiornati. Siete gentili e competenti.

Grazie a tutti

[lelos]

ciao

fare un protocollo di comunicazione per i plc omron è spiegato nei manuali della omron.

Se non hai tanti in/out perché non monti una scheda i/o sul pc o una scheda master cc.link (o altre reti) in  modo da poter pilotare valvole , leggere analogiche comandare motori ecc.ecc.?

ci sono schede pci di tutti i tipi , usi il linguaggio che vuoi e fai quello che vuoi .