Alternative zu NI CompactRio System gesucht Vorschläge/Erfahrung/Hersteller?

[STEP7_NEWBEE]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an Alle,

Wie der Beitrag schon verrät suchen wir gerade eine Alternative zu einem CompactRIO System von National Instruments.

Unser Problem ist zum einen, dass man relativ wenig LabVIEW Programmierer findet und auf der anderer Seite der Preis dieser Echtzeitsysteme.
Bei uns ist das Ganze im wesentlichen historisch gewachsen und jt .. oh Schreck .. wer programmiert uns diese Systeme? - für die ersten Tests und Implementierungen sind diese Systeme super!.. aber

wir sind der Auffassung das auch heutige Industrie PC`s unsere Anforderungen erfüllen werden...

Derzeit ist das System so aufgebaut: Daten werden mit 9Khz aufgezeichnet und via CAN an den RIO übergeben. Am Rio findet hierbei vor allem die Datenauswertung / Speicherung statt, der FPGA wird für eine FFT verwendet..
Auch die Echtzeitfähigkeit ist für das System wichtig (garantierte Reaktion im 2 bis 3ms Bereich ) / das ist die schnellste Reaktionszeit die wir benötigen

Wichtig sind für uns vor allem: die Offenheit eines Systems.. - gute Erweiterbarkeit , gute Anbindung an gängige Steuerungen - "einfache" Erweiterung über Schnittstellenkarten um mit gängigen Bussystemen zu sprechen. Profinet, Profibus, Ethercat usw.

Visualisierung und Speicherung

Und Programmierung des Systems in unterschiedlichen Sprachen möglich: am Besten C++/Python/Matlab, wobei es auch möglich sein sollte Labview Funktionen zu implementieren. -

Habt ihr Tipps / Erfahrungen mit welchen Steuerungsherstellern man diese Anforderungen am Besten umsetzen kann?

Mir wäre auf die Schnelle Beckhoff eingefallen, ich weiß aber nicht wie gut sich auf diesen Systemen Signalverarbeitungsfunktionen umsetzen lassen ?
Welche Systeme verwendet ihr zum Berechnen von FFT`s bzw. wenn ihr zeitkritische Anwendungen umsetzt? (B&R ? Siemens? Beckhoff? andere Hersteller? )

Freue mich über jeglichen Input von euch!

Vielen Dank im Voraus!

LG

 

[roboticBeet]

Bei den klassischen Steuerungsherstellern kenne ich mich mit dieser Form der Signalverarbeitung nicht aus. Beckhoff hat aber in der Tat ein großes Messtechnik Portfolio.

Alternativ würde mir ähnlich zu den NI RIOs noch dSPACE Hardware zusammen mit Matlab und Simulink einfallen. Das ist dann aber auch mehr auf der Prototyping-Ebene. Die bieten ebenfalls EtherCat und Profibus Schnittstellen zu SPSen etc an.

 

[Guga]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kenne nur Beckhoff (auf diesem Niveau) und dort könntest du meiner Ansicht deine Wünsche umsetzen..
Klassischer Ansatz um von "außen" zu programmieren (also Python, Labview, C#).:
a) Daten per ADS austauschen -> da wird es irgendwann mit der Reaktionszeit schwierig. 2-3msec wenn dein Programmierzeugs "wo anders" läuft ist wohl nicht mehr zu halten
b) Matlab / Labview generiert ein Codeschnipsel das in die TwinCAT Echtzeit eingebunden wird. C++ geht auch - allerdings bist du limitiert auf DLLs die im Echtzeitkontext laufen, also mit der C++ funktion geschriebene DLLs.

Bausteine/Möglichkeiten um FFTs u.ä. zu rechnen gibt es auch verschiedene. Im Echtzeitkontext als PLC Bibliothek z.B. mit TF3510.
Egal wo du findig wirst, ich würde auf jeden Fall schauen ob das man die Messwerte "nativ" in das System bringt und somit irgendwelche Gateways (CAN) außen vor zu lassen.
Bei Beckhoff wäre das also EtherCAT. Im Portfolio haben die diverse Messklemmen >9kHz (ELM-Klemmen) können und das auch mit einer für mich ausgewogenen Verhältnis von Genauigkeit und Preis/Kanal).

Welche anderen Mütter noch schöne Töchter haben kann ich dir leider nicht sagen.

Guga

 

[MRupf]

Software basierte Echtzeit könnte auch spannend sein für die Anwendung. Damit wird die Hardwareabhängigkeit reduziert und die Programmierung kann in einer Hochsprache wie C++ erfolgen und auch andere Bibliotheken einfach eingebunden werden.

Als Vertriebskanal von Sybera bin ich da natürlich voreingenommen.
Mir gefällt dabei das EtherCat, EthernetIP und Profinet Stack verfügbar ist und auf einem Windows Rechner, mit der entsprechenden Hardware und Ethernet Karte (Intel, Realtek), Jitterzeiten von <10us bei Zykluszeiten von 1ms machbar sind.

Es gibt dabei auch noch weitere Anbieter, aber inzwischen sind die Software Stacks ziemlich gut und ich würde das zumindest mal anschauen ob die freiere Wahl der Umgebung (HW, Progammierung) für euch passen könnte.

 

[maxder2te]

Prinzipiell sollte sich das auch auf B&R Hardware einfach lösen lassen.

Die Entwicklungsumgebung ("Automation Studio") unterstützt C/C++ von Haus aus nativ und als Echtzeit-Tasks, auch Targets für Matlab/Simulink gibts. Die Hardware gibts auch in allen Leistungsklassen, Reaktionszeiten < 1 ms sollten da problemlos machbar sein.
Das Standard-Busssystem heißt "Ethernet Powerlink" und ist taktsynchron konzipiert, Profinet, Profibus, diverse CAN-Derivate, Ethernet/IP, Moduus/TCP gibts als Master, EtherCAT als Slave.

 

[STEP7_NEWBEE]

Zuviel Werbung?
-> Hier kostenlos registrieren

Vielen Dank schon einmal an alle für die Inputs!

@MRupf: wie würde denn so ein System klassischer Weise aussehen? - gibt es vl ähnliche Referenzen? .. ein Video auf Youtube habe ich zumindest schon einmal gefunden

LG

 

[STEP7_NEWBEE]

Kenne nur Beckhoff (auf diesem Niveau) und dort könntest du meiner Ansicht deine Wünsche umsetzen..
Klassischer Ansatz um von "außen" zu programmieren (also Python, Labview, C#).:
a) Daten per ADS austauschen -> da wird es irgendwann mit der Reaktionszeit schwierig. 2-3msec wenn dein Programmierzeugs "wo anders" läuft ist wohl nicht mehr zu halten
b) Matlab / Labview generiert ein Codeschnipsel das in die TwinCAT Echtzeit eingebunden wird. C++ geht auch - allerdings bist du limitiert auf DLLs die im Echtzeitkontext laufen, also mit der C++ funktion geschriebene DLLs.

Bausteine/Möglichkeiten um FFTs u.ä. zu rechnen gibt es auch verschiedene. Im Echtzeitkontext als PLC Bibliothek z.B. mit TF3510.
Egal wo du findig wirst, ich würde auf jeden Fall schauen ob das man die Messwerte "nativ" in das System bringt und somit irgendwelche Gateways (CAN) außen vor zu lassen.
Bei Beckhoff wäre das also EtherCAT. Im Portfolio haben die diverse Messklemmen >9kHz (ELM-Klemmen) können und das auch mit einer für mich ausgewogenen Verhältnis von Genauigkeit und Preis/Kanal).

Welche anderen Mütter noch schöne Töchter haben kann ich dir leider nicht sagen.

Guga

super, Vielen Dank! ... mir persönlich hätte Beckhoff bis jetzt am besten gefallen.. - vor allem vom Systemaufbau / Offenheit her.. werde mich hier noch einmal genauer umschauen .. - die haben ja auch super Videos/Tutorials auf der Homepage.

könntest du auf die schnelle eine passende Hardware/PLC sagen, auf der man die ersten Tests einmal umsetzen könnte?

der direkte Weg ist bei unserer Anwendung leider nur bedingt / schwer möglich.. / die CAN Schnittstelle wollen wir momentan auf alle Fälle weiter benutzen...

wo siehst du persönlich den Nachteil?

der Flaschenhals in unsere Anwendung ist leider zu Beginn eine Bluetooth Übertragung der Messdaten - diese werden dann anschließend über CAN an den Messrechner gesendet ..

LG

 

[STEP7_NEWBEE]

Prinzipiell sollte sich das auch auf B&R Hardware einfach lösen lassen.

Die Entwicklungsumgebung ("Automation Studio") unterstützt C/C++ von Haus aus nativ und als Echtzeit-Tasks, auch Targets für Matlab/Simulink gibts. Die Hardware gibts auch in allen Leistungsklassen, Reaktionszeiten < 1 ms sollten da problemlos machbar sein.
Das Standard-Busssystem heißt "Ethernet Powerlink" und ist taktsynchron konzipiert, Profinet, Profibus, diverse CAN-Derivate, Ethernet/IP, Moduus/TCP gibts als Master, EtherCAT als Slave.

Interessant, danke! ... B&R könnte für uns vl auch eine interessante Option sein

LG

 

[ROSCH1804]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und es gibt neuerdings auch das Produkt Xentara, das wie ein modernes IT System, JSON konfiguriert objektorientiert, mit Security und mindestens die Echtzeitfähigkeit klassischer SPS Systeme aufweist. Ich würde die Messdatenerfassung auch über EtherCAT als Bus realisieren, 9kHz sind da kein Problem. Allerdings geht nicht im Detail daraus hervor, wie die Messdaten erfasst werden. EtherCAT bietet aber viele Möglichkeiten. Für die Datenauswertung müsste entweder ein FPGA Board über eine der offenen Schnittstellen angebunden werden oder man nutzt eine GPU zur Berechnung über die Schnittstelle ONNX. Die geforderten Reaktionszeiten von < 2ms sollten kein Thema sein, ist halt abhängig wo der Trigger generiert wird.
Die Koordination der unterschiedlichen Abläufe lassen sich leicht über ein Timingmodell sehr flexibel handeln. Zum Daten speichern kann InfluxDB verwendet werden. Hier ist der Zyklus aber auf 1kHz beschränkt. Man kann aber Daten puffern oder auf mehrere Kanäle aufteilen. Vielleicht reicht das ja. Ansonsten sollte man sich wieder ein eigenes Interface schreiben, das den Anforderungen entspricht.

 

[maxder2te]

Und es gibt neuerdings auch das Produkt Xentara, das wie ein modernes IT System, JSON konfiguriert objektorientiert, mit Security und mindestens die Echtzeitfähigkeit klassischer SPS Systeme aufweist. Darüber hinaus unterstützen die auch ONNX, Datenbanken und MQTT. Das erreichen Sie durch ein Timing Modell, in der unterschiedliche Pipelines definiert werden können, die entweder Event basiert oder zyklisch aufgerufen werden.

Das sind alles Buzzphrases die in keinster Weise auf die ursprüngliche Aufgabenstellung eingehen.

 

[ROSCH1804]

Das sind alles Buzzphrases die in keinster Weise auf die ursprüngliche Aufgabenstellung eingehen.

Ich kann es auch genauer beschreiben. Ich wollte nur nicht zu sehr ins Detail gehen. Wen es interessiert kann ja nachschauen. Aber nachdem ich neu in dem Kanal bin, kann ich gerne tiefer gehen.

 

[maxder2te]

Zuviel Werbung?
-> Hier kostenlos registrieren

Naja: da hat vor 3 Jahren jemand eine recht konkrete Anfrage gestellt der Sinn des Forums ist, Lösungen zu finden oder Hilfestellungen zu bringen.

Ich kann mir schwer vorstellen, dass du diesen Alt-Beitrag zufällig beim Surfen gefunden hast. Du möchtest ein Produkt an den Mann bringen, dafür ist der Thread "Werbung und Produktneuheuten" da. Und dort bitte keine Buzz-Phrases sondern handfeste Fakten und leg auch klar was das für einen Nutzen bringt. Wir SPS-Menschen sind nur schwer von was neuem zu Überzeugen - Echtzeit, MQTT und Datenbanken sind doch ein alter Hut.

 

[ROSCH1804]

Natürlich habe ich den Beitrag zufällig gefunden, weil ein anderer Kunde auch eine Lösung für Labview sucht. Und nachdem es ein Altbeitrag war und ich die alternativen Lösungen schon kannte, habe ich dieses Thema noch dazugestellt, weil es gut passen würde. Ich konnte verstehen, dass mein erster Beitrag etwas zu oberflächlich war. Aber man muss neue Kanalmitglieder nicht gleich wieder vertreiben, nur weil einem etwas nicht passt. Im übrigen muss ich Ihnen recht geben. Aus einem SPS Kern ein MQTT zu aktivieren ist ein alter Hut. Das ist aber hier etwas anderes...