Empfehlung für Messwerterfassungssystem mit >100 analogen Eingängen

Devil120

Level-1
Beiträge
21
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin,

ich bin neu hier im Forum und auch neu in der Materie der Messwerterfassung. Etwas SPS-Programmiererfahrung besteht aber.

Es geht um Folgendes Projekt. Als Bachelorarbeit habe ich die Aufgabe, ein System für einen Prüfplatz zusammen zu stellen und eine erste Messwertaufnahme mit einem kleinen Anteil der später benötigten Sensoren zu ermöglichen.

Das Ziel ist im Anschluss eine Messwertaufnahme von 10 S/s für folgende Sensorsignale zu gewährleisten:

- 100 x Thermoelement Typ K
- 4 x Druck
- 4 x Infrarot (Temperatur)
- 2 x Helligkeit
- 1 x Differenzdruck
- 1 x Luftfeuchte

(hatte mir überlegt, alle Sensoren (bis auf die Thermoelemente) als Strom-Ausführung zu nehmen (4..20mA))

Rahmenbedingungen:

- soll für eine spätere Implementierung in LabView geeignet sein (evtl. starte ich auch schon direkt in LabView, dass ist noch nicht ganz sicher)
- alle Daten mit dem selben Zeitstempel
- zentrale oder dezentrale Speicherung ist egal
- eine Kamera soll ebenfalls mitlaufen, die den selben Zeitstempel besitzt
- eine besonders große Messgenauigkeit ist nicht von Nöten
- eine spätere Einbindung von Aktoren soll möglich sein
- eine Messdatenaufbereitung (Visualisierung) muss grundsätzlich während der Messung möglich sein

Nun habe ich mich schon eine geraume Zeit durch das Internet gewühlt und nach geeigneten Messsystemen gesucht.

Näher in Betracht gezogen habe ich bisher Beckhoff (EtherCAT, TwinCAT3) und die NI eigene Hardware, bei der ich die Messwertaufnahme direkt in LabView realisieren würde.
Allerdings halten sich meine Erfahrungen mit LabView in Grenzen und ich weiß nicht, ob das den zeitlichen Rahmen für meine Arbeit sprengt.

Meine Frage nun an euch - hat jemand schon einmal ein ähnliches System konzipiert und realisiert, sodass er mir einen Tipp bei der Auswahl geben kann?
Gibt es eine Möglichkeit, die Messwertspeicherung in FUP zu programmieren, oder komme ich im Fall von Beckhoff nicht um C++ herum?

Die Infos sind wahrscheinlich noch Lückenhaft, also haut bitte einfach raus, was ihr dazu noch wissen müsst.


Vielen Dank erst einmal im Voraus!

Viele Grüße
 
Zuletzt bearbeitet:
Twincat3, CX20xx Controller, 200 Analogkanäle skalieren und via OPC UA oder ADS Labview zur Verfügung stellen, zusätzlich könntest Du die Werte alle x Millisekunden in eine CSV Datei schreiben, klingt nach einer lösbaren Aufgabe.
 
Vielen Dank für die Antworten! Das klingt schon mal gut. Mir gefällt die Beckhoff-HW auch ganz gut. Vor allem die einfache Erweiterbarkeit ist klasse.

Benötige ich den CX20XX-Controller oder könnte ich auch einen EK9000 nehmen und über ein Notebook oder einen IPC die Steuerung laufen lassen?
 
Ich sag mal nein, denn der hat einen Modbus-Anschluss. Wenn Du tatsächlich die SPS auf einem "großen" PC laufen lassen möchtest und nicht auf einer CX (z.B. CX20XX, CX51XX) dann solltest Du die EK1100 nehmen. Du musst dann nur darauf achten, dass Dein PC eine Netzwerkkarte mit Intel-Chipsatz hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die Fragestellung kann schon noch weiter aufgemacht werden. Ist die Verwendung von Kompontenen aus der Industrie-Automation geplant? Dann ist der Weg über Beckhoff ein gangbarer. Alternativen gibt es natürlich hier auch viele:
  • Siemens Simatic
  • WAGO
  • CoDeSys + kompatible Produkte (kann preislich attraktiv werden)
Wichtig ist es dann hier die Randbedingungen genau zu beachten. Wie schon angesprochen die Messrate (~ 10 / s) und Zeitstempelung. Bei der Zeitstempelung gibt es dann schnell unterschiede in der Auflösung. Reichen hier +- 50 ms oder muss das im us-Raster genau sein?

Wenn LabView schon angesprochen worden ist, dann ist die Fragestellung nach der Datenspeicherung in den SPS-Komponenten eher unwichtig. Diese werden dann eher nur als reine Eingabe-/Ausgabemodule betrachtet und die Programmierung hier reduziert sich auf ein Minimum.

Auf der anderen Seite des Spektrums gibt es dann die klassischen Messdatenerfassungen:
  • NI
  • HBM
  • Delphin > Mein Lieblingsprodukt für Messungen während einer IBN
  • ...
Bei den "richtigen" Messdatenerfassungen sind die Möglichkeiten der Messdatenspeicherung, Analyse und Archivierung schon besser vorbereitet, wie dies bei einer SPS-Automatisierungslösung ist. Allerdings sind die angesprochenen > 100 Thermoelemente natürlich schon eine Ansage in der Anzahl der normalerweise recht teuren Module.

Allgemein kann man natürlich anmerken, dass die alten Grenzen zwischen SPS und Messdatenerfassung natürlich beständig schwinden.
 
Danke für deine Anregung. Die Genauigkeit der Messwerte ist nicht besonders wichtig, genauso die Genauigkeit des Zeitstempels. 50 ms reichen vollkommen aus.

Bei NI ist man alleine mit der Hardware schon bei über 11k€ + Software, weshalb ich da wahrscheinlich Schwierigkeiten bekomme, diese Summe zu rechtfertigen. Wenn das alles mit Beckhoff HW realisierbar ist, bin ich absolut zufrieden.

Mein Plan wäre jetzt, dass ein Notebook oder ein IPC direkt in den Schaltschrank kommt und die Funktion des Controllers übernimmt. Die Daten können dann dort gespeichert und anschließend ausgewertet werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde anstatt der CX20xx Reihe eher die CX51xx Reihe empfehlen. Eine CX5130 z.B. sollte mehr als ausreichend sein. Falls du dir unsicher bist, wende dich einfach mit deinem konkreten Anwendungsfall an den Beckhoff Vertrieb, der für deine Region zuständig ist.
 
Hallo Leute,
ich möchte gern eine kurze Rückmeldung geben und gleichzeitig nochmal zwei kurze Fragen stellen.

Habe jetzt ein System von Beckhoff hier stehen, was auch echt gut funktioniert. Es läuft soweit, dass die Messwerte alle 10 ms in eine CSV-Datei geschrieben werden.
Jedoch nur, wenn die CPU keine anderweitige Auslastung erfährt. So ergeben sich manchmal Sprünge von 11 ms bis ca. 17 ms zwischen den Messwerten, sodass ich nicht immer auf 100 Messwerte pro Sekunde komme. Es ist ein i7-6700TE, der Fehler liegt also eher in der Parametrierung bzw. in der Software.

- Hat jemand eine Ahnung wie ich ein festes (wirklich bombenfestes) Zeitintervall zum Schreiben setzen kann?

- Außerdem habe ich es erst einmal so realisiert, dass ich alle Messwerte mit 100 S/s in die CSV-Datei schreibe. Die Anforderung ist es, dass alle Messwerte mit min. 10 S/s erfasst werden und der Druck mit 100 S/s. Leider habe ich keine gute Idee gehabt, die Messwerte mit unterschiedlicher Frequenz aufzunehmen. Auch die CSV-Datei ist dann natürlich nicht einheitlich.
Falls jemand von euch auch schon einmal ähnliches umgesetzt hat - wie habt ihr das gelöst?

Vielen herzlichen Dank und einen guten Start in die neue Woche :)
 
Hat jemand eine Ahnung wie ich ein festes (wirklich bombenfestes) Zeitintervall zum Schreiben setzen kann?
Ich behaupte mal gar nicht. Die Dateibefehle laufen im Hintergrund ab, immer wenn Zeit ist und nicht in Echtzeit und da hat man meine ich auch keinen Einfluss drauf.
Was Du machen könntest wäre die Daten in etwas größeren Portionen zwischen zu puffern und dann weg zu schreiben, denn die Zeit die der Schreibvorgang benötigt steigt nicht proportional mit der Datenmenge.
 
ich hole mir die Zeit aus Windows mit NT_GetTime

EDIT: Ich glaube, dass Windows das Problem ist. Wenn irgendwelche Prozesse mit höherer Priorität (außerhalb von TwinCAT) aufgerufen werden, wird der Ablauf kurz unterbrochen.
Ich müsste mir also eine Software zur Festsetzung der Prioritäten in Windows besorgen und es damit mal versuchen, oder?
 
Zuletzt bearbeitet:
Es läuft soweit, ... Jedoch nur, wenn die CPU keine anderweitige Auslastung erfährt. So ergeben sich manchmal Sprünge von 11 ms bis ca. 17 ms zwischen den Messwerten, sodass ich nicht immer auf 100 Messwerte pro Sekunde komme.
- Hat jemand eine Ahnung wie ich ein festes (wirklich bombenfestes) Zeitintervall zum Schreiben setzen kann?

- Außerdem habe ich es erst einmal so realisiert, dass ich alle Messwerte mit 100 S/s in die CSV-Datei schreibe. Die Anforderung ist es, dass alle Messwerte mit min. 10 S/s erfasst werden und der Druck mit 100 S/s. Leider habe ich keine gute Idee gehabt, die Messwerte mit unterschiedlicher Frequenz aufzunehmen. Auch die CSV-Datei ist dann natürlich nicht einheitlich.
Zu Verschiebungen kommt es "automatisch" bei wechselnder Austastung der CPU. Am besten dafür sorgen, dass anderweitige Auslastungen im Rahmen bleiben. Halbwegs "bombenfest" geht nur, wenn keine anderweitigen Auslastungen auftreten und ausserdem genügend "Luft" bleibt, den schnellen Zyklus regelmässig vor Beginn des nächsten Zyklus zu beenden.

Du könntest ein Array mit den 10 Druckwerten (plus Zeitstempeln?) pro 100 ms auffüllen und die übrigen Messwerte alle 100 ms erfassen und alles zusammen alle 100 ms in die CSV-Datei schreiben.
Der Satzaufbau wäre dann in der CSV immer gleich - und die Belastung durch das Wegschreiben der Daten in die CSV verteilt sich dann hoffentlich so, dass der Jitter der alle 10 ms erfassten Druckwerte nicht zu gross wird.

Für den 100 ms Takt würde ich keine weitere Task nehmen, sondern die 10 ms Task und dort mitzählen und nur bei jedem 10. Aufruf das Wegschreiben des CSV-Datensatzes veranlassen.
 
Hat Twincat kein internen Uhr ?
Wenn es millisekunden-genau sein muss wurde Ich den Zeitstempel in den SPS auslesen, und Teil von die Daten sein die in den CSV geschrieben werden sollen.
 
Habe auch ein bisschen Angst wenn auf ein Flashspeicher jeden 10 ms geschrieben wird.
Wenn den Zeitstempel durch den SPS generiert wird, kann man ein Puffer von z.B. 100 Messungen in den SPS speichern. Und dann jeden Sekunde in die CSV schreiben.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dein csv-Datei schreiben wird doch bestimmt in einzelnen Teilschritten (Schrittkette) ausgeführt - wie viele Task-Durchläufe braucht das Schreiben, welche Zykluszeit hat die Task?

Harald

Die Zykluszeit beträgt 1 ms. Anscheinend braucht es dann 10 Zyklen für einmal Schreiben.
Es wird immer eine ganze Zeile aus Datum/Uhrzeit/Messwerte1... MesswertX geschrieben.

Hat Twincat kein internen Uhr ?
Wenn es millisekunden-genau sein muss wurde Ich den Zeitstempel in den SPS auslesen, und Teil von die Daten sein die in den CSV geschrieben werden sollen.

Doch die gibt es. Aber bei Windows bekomme ich auch eine millisekunden-genaue Zeit und es ist halt dieselbe Zeit des Videosignals der Ethernet-Kamera.

Habe auch ein bisschen Angst wenn auf ein Flashspeicher jeden 10 ms geschrieben wird.
Wenn den Zeitstempel durch den SPS generiert wird, kann man ein Puffer von z.B. 100 Messungen in den SPS speichern. Und dann jeden Sekunde in die CSV schreiben.

Das mit dem Puffer muss ich mir nochmal genauer anschauen. Bin halt erstmal froh, dass es überhaupt so gut läuft :D war ein ganz schöner Krampf für mich. Wenn ich durch den Puffer alles wieder umprogrammieren muss, wärs echt unschön :/

Vielen Dank erstmal für eure Anregungen.
 
Das mit dem Puffer muss ich mir nochmal genauer anschauen. Bin halt erstmal froh, dass es überhaupt so gut läuft :D war ein ganz schöner Krampf für mich. Wenn ich durch den Puffer alles wieder umprogrammieren muss, wärs echt unschön
Wirst Du wohl nicht drum rum kommen, wie schon geschrieben laufen die Prozesse vom Dataihandling im Hintergrund und werden ausgeführt, wenn gerade mal Zeit war, aber halt nicht zyklisch im Echtzeitkontext.
 
Es wird immer eine ganze Zeile aus Datum/Uhrzeit/Messwerte1... MesswertX geschrieben.
Das war ja auch mein Ansatz aus #14, aber ...
alle 100 ms 1 Datensatz schreiben mit Datum+Uhrzeit und Messwert1 .. MesswertX und Druckwert0(Uhrzeit+0ms), Druckwert1(Uhrzeit+10ms) .. Druckwert9(Uhrzeit+90ms).

Kann es sein, dass Deine Zeitsprünge darauf zurückgehen, dass der Zeitwert "weit hergeholt" ist (aus Windows statt aus der SPS)?
 
Zurück
Oben