Modello di progettazione per un banco di prova meccanico automatizzato

5

Sfondo

Ho un apparecchio di prova con un numero di dispositivi di acquisizione dati / comunicazione su di esso che viene usato come test di fine linea per un prodotto.

A causa di tutti i vari sensori usati nel banco e della necessità di eseguire la procedura di test quasi in tempo reale, sto avendo difficoltà a strutturare il programma per essere più amichevole da modificare in seguito. Ad esempio, un dispositivo di acquisizione dati USB di National Instruments viene utilizzato per controllare un'uscita analogica (carico) e monitorare un ingresso analogico (corrente), una bilancia digitale con un'interfaccia dati seriale, un manometro con un'interfaccia dati seriale diversa e il prodotto è interfacciato tramite una DLL proprietaria che gestisce la propria comunicazione seriale.

La parte difficile

L'aspetto "in tempo reale" del programma è il mio più grande punto di svolta. Ad esempio, ho bisogno di tempo per quanto tempo il prodotto deve andare dalla posizione 0 alla posizione 10.000 al decimo di secondo. Mentre è in viaggio, ho bisogno di accelerare un output del NI DAQ quando raggiunge la posizione 6.000 e farlo scendere quando raggiunge la posizione 8.000. Questo tipo di controllo sembra facile sfogliando i documenti LabVIEW di NI, ma per ora sono bloccato con C #. Tutta la comunicazione esterna viene eseguita tramite il polling, il che rende molti loop fastidiosi.

Ho schiaffeggiato un modello Consumer Consumer sfuso in cui il thread del produttore scorre leggendo i sensori e imposta le uscite. Il thread Consumer esegue funzioni contenenti cicli temporizzati che interrogano il Producer per i dati correnti ed eseguono i comandi di movimento come richiesto. Il thread UI esegue il polling di entrambi i thread per l'aggiornamento di alcuni indicatori che indicano l'avanzamento del test corrente.

Non so da dove cominciare

Esiste uno schema più appropriato per questo tipo di applicazione?

Ci sono buone risorse per scrivere loop di controllo in software (non LabVIEW) che si interfacciano con sensori esterni e che altro?

    
posta JJS 12.06.2012 - 20:28
fonte

2 risposte

1

Questa è una buona domanda che si basa molto sul contesto. Il mio approccio sarà quello di descrivere i modelli disponibili per la tua recensione. La seguente è una panoramica di alto livello.

Sto cercando nel libro del pinnacolo Design Patterns - Elements of Reusable Object-Oriented Software , di Gamma, Helm, Johnson e Vlissides. È scritto per C ++, ma sarebbe ampiamente applicabile in C #.

  1. anti-modello. Uno degli aspetti negativi nella progettazione di modelli è la possibilità di applicarli solo per il gusto di farlo. È importante rendersi conto che questi schemi risolvono problemi specifici e non dovrebbero essere implementati a meno che il problema non esista. Fare così sarebbe un anti-pattern.

  2. facciata. 'Fornire un'interfaccia unificata a un insieme di interfacce in un sottosistema.' Sembra potenzialmente utile per raggruppare tutti i tuoi oggetti disparati in una singola interfaccia. Ciò semplificherà la tua capacità di accedervi se tutti fossero raggruppati in un "Singleton" chiamato, qualcosa come Sensori o Consumatori.

  3. Singleton. Garantire una singola istanza di un oggetto. Questo può essere utile in collaborazione con altri modelli. Questo può essere comunemente usato come oggetto Manager o Proxy, per esempio.

  4. Proxy. 'Fornire un segnaposto surrogato per controllare l'accesso.' Potrebbe essere utile rivedere per astrarre i punti di connessione.

  5. Catena di responsabilità, osservatore, abbonato editore. Queste sono le nozioni di disaccoppiamento delle dipendenze dell'interfaccia. Uno di questi potrebbe essere utile per te tra il tuo Producer Consumer, in modo che il tuo produttore non sia sospeso in attesa che un consumatore possa funzionare o rispondere. Invece ciò che può accadere è che gli eventi consentono una separazione tra i due.

  6. Strategia. "Una famiglia di algoritmi, incapsulano ciascuno e li rendono intercambiabili." Questo può essere utile per te se hai comportamenti diversi che devono cambiare dinamicamente per stati diversi.

  7. Iterator. Ciò potrebbe fornire un'ottimizzazione per l'accumulo di loop.

Ancora una volta, questa è una panoramica di alto livello. Sono certo che alcuni di questi non saranno adatti alla tua implementazione, ma rivederli può dare una buona idea di quali sono i metodi di ottimizzazione disponibili.

Infine, tieni presente che questi modelli sono applicati al meglio in Design Time. Se hai un'implementazione legacy piuttosto solida, un alto livello di refactoring complesso sarebbe un'aspettativa ragionevole.

Dai anche un'occhiata ai modelli specifici di C #. Spesso i modelli originali posano sopra il morph mentre trascendono le lingue. Possono essere essenzialmente lo stesso schema, ma con requisiti specifici di implementazione differenti, possono cambiare nome. Come PubSub / Observer.

Spero che aiuti. Ti auguro il meglio! Nash

    
risposta data 13.06.2012 - 17:52
fonte
1

Hai l'hardware che hai. Tuttavia ... il sistema operativo Windows non è stato progettato per un timing preciso, come probabilmente sapete. I controller periferici (nei dispositivi di acquisizione dati) solitamente funzionano molto meglio di Windows.

Idealmente, il controller periferico avrebbe una funzionalità in cui può ricevere una lista di comandi, che avrebbe tempo ed esecuzione. Essenzialmente, si avrebbe thread in tempo reale in esecuzione su un controller dedicato.

Controllo distribuito.

    
risposta data 02.08.2014 - 07:39
fonte

Leggi altre domande sui tag