Guten morgen zusammen, ich arbeite in einem Forschungsinstitut einer Hochschule, wir haben verschiedene Maschinen (unter anderem eine Dieselpumpe, ein Bohrgerät, eine Wasseraufbereitungsanlage) die mit unterschiedlichen Steuerungen ausgestattet sind und in Container-Bauweise gebaut sind (für den Transport). Teilweise stehen hier auch einzelne Messgeräte wie z.B. Durchflussmessgeräte. Wir möchten bei unseren Versuchen gerne die Messdaten möglichst aller Maschinen aufzeichnen und später auswerten. Dazu suche ich Tipps, wie man das umsetzen kann. Es gäbe die Möglichkeit, hier einfach eine Firma zu beauftragen, die uns irgend ein System liefert, gäbe es unbegrenzte Mittel, wie immer :) Es geht um Fördergelder und damit möchte ich verantwortungsvoll umgehen. Ich würde gerne jede Maschine mit einem "Modul" ausstatten, welches an die Steuerung angeschlossen wird und die Daten der Maschine z.B. über Ethernet an einen Server oder Master oder ähnliches überträgt. Es gibt die Möglichkeit, entweder an den Bus der Maschinen zu gehen oder die Werte sogar analog einzulesen, bei einigen Sensoren muss das sogar analog erfolgen. Die Abtastrate muss nicht sonderlich hoch sein (vielleicht 10 Hz maximal), "echtzeitfähig" sollte das ganze jedoch schon sein, sprich, die Daten sollten alle vor den nächsten Daten am Master sein. Es kann durchaus auch ein Paket mit einem ganzen Vektor an Messwerten sein, der zum Beispiel nur alle 10 Sekunden übermittelt wird. Der Programmieraufwand ist egal. Meinetwegen kann man auch alles in C oder Python programmieren, sollte es notwendig werden. Wir nutzen hier MATLAB, daher sollten die Daten zum Schluss irgendwie in einem Format vorliegen, welches Matlab lesen kann (.mat idealerweise, auf gar keinen Fall nur Excel). Ich habe den Tipp bekommen, dass man so etwas mit Beckhoff-Steuerungen umsetzen kann, dort würde ich mich dann auch mal melden. Gibt es dazu eine Meinung? Es spricht auch nichts dagegen, jede Maschine mit einem Raspberry Pi auszustatten und diesen mit Analog-In oder CAN-Modulen zu versehen. Ich kann das nur nicht abschätzen, ob das überhaupt funktioniert. Mit halbwegs sicherer Spannungsversorgung und den Zusatzmodulen, Gehäuse etc. schätze ich hier den Preis auf etwa 150-200€ pro Maschine. Daher meine Fragen: - Gibt es fertige Systeme, die man für so ein Vorhaben einsetzen kann? Ein solches System sollte von uns programmierbar sein (egal mit welchem Aufwand) und möglichst kein Vermögen kosten. Wenn ich 1500€ für jedes Modul an jedem Sensor bezahlen muss und am Ende bei 20.000 € lande, ist das zu teuer. - Welche Protokolle nutzt man am besten, um die Daten von den einzelnen verteilten Modulen zu übertragen und zu sammeln? Ich wäre für jede Antwort sehr dankbar. Beste Grüße
Hallo, so wie du das beshrieben hast, wirst du wohl für jede einzelne Maschine ein Modul bauen/programmieren müssen. Da deine Anforderung bezüglich der Abtastung nicht wirklich hoch sind, kannst du so ziemlich jeden Controller nehmen. Klar, hier bietet sich natürlich der Raspberry an, da er schon einige Schnittstellen liefert. Als übergeordnete Schnittstelle würde ich Ethernet nehmen. Baue dir dann ein Frame zusammen, wie du das möchtest. Es sollte halt für jede Maschine gleich aufgebaut sein. Das sollte alles mit einem vertretbaren Aufwand machbar sein. Vor allem für ein Forschungsinstitut.
Verantwortungsvoller Umgang mit Fördermitteln ist natürlich löblich ;-) Allerdings solltest du nicht vergessen, dass auch die Gehälter aus diesen Mitteln gezahlt werden. Unter Umständen ist es effizienter, mehr in Hard- und Software zu investieren, die danach auch von anderen und für andere Projekte noch sinnvoll eingesetzt werden kann. Im Forschungsumfeld bietet sich z.B. LabVIEW an, evtl. sogar mit NI Hardware. Aber auch fast alle anderen Hersteller von Datenerfassungshardware unterstützen LabVIEW. Zur Übertragung bietet sich ein Feldbus an. EtherCAT, CAN, Modbus etc.
1) Finger weg von NI und LabView. Das ist der letzte Mist und unglaublich teuer. Besonders die Hardware. 2) Frag mal, wie viele der Maschinen weniger als 20k€ gekostet haben. Das riecht mir nach den üblichen sinnlosen bsc/Master Arbeiten, die von vornherein zum scheitern verurteilt sind. Und weil das bis auf den Studenten schon alle vorher wissenoch, gibt dafür auch kein Budget. Auch eine Form von Verantwortungsvollem Umgang mit Fördergeldern. 3) Wenn du es trotzdem schnell und billig machen willst bzw. Musst, nimm einen AVR mit Rs485 und geeigneten IO bzw ADC Chips je Maschine. Am Ende Sammelst du dann alles mit einem Raspi ein.
Hi, ich nutze privat fürs Hobby einen Labjack U12 mit gekaufter Software von Abacom-Online. Für meine Aufgaben reicht er vollkommen aus. Es hat analoge und digitale Eingänge bzw. auch digitale Ausgänge. Es gibt bessere Varianten die auch schneller sind und auch u.a. einen LAN-Anschluss haben. Siehe dich mal auf der Seite von Meilhaus um. Vielleicht ist das etwas für Dich. Ich habe das Teil bei Reichelt gekauft.
:
Bearbeitet durch User
Hallo Viktor, es wäre gut, wenn du ein bisschen mehr Details zu den anzuschließenden Geräten liefern würdest. Für Steuerungen gilt leider der Spruch "das Gute an Standards ist, dass es so viele davon gibt." Wenn die Ressource "fähiger Student" unbegrenzt zur Verfügung steht, kannst du für jede Steuerung einen Umsetzer auf z.B. Modbus TCP entwickeln lassen. Einen Doktoranden kannst du dann daran setzen, den so entstehenden Flohzirkus zu dressieren, d.h. ein übergreifendes Onzept zu entwickeln. Als Hardware für die Modbus TCP-Wandler ist ein RPi sicher nicht das Verkehrteste. Das lässt sich notfalls auch in paar Jahren recht fix auf ein anderes System portieren. Die wichtigste Frage ist eigentlich "wie stelle ich sicher, dass es in 10 Jahren immer noch funktioniert und repariert werden kann?". Max
Viktor Hartung schrieb: > Daher meine Fragen: > - Gibt es fertige Systeme, die man für so ein Vorhaben einsetzen kann? Ohne genaue Anforderungen was wirklich zu messen ist, kann man das nicht beantworten. Die Anforderungen solltest du oder ein dir zur Verfügung stehender HiWi in Ruhe erarbeiten. Z.B. Maschine für Maschine, was für Größen sind zu messen, wie kommt man ran, welche Messwertaufnehmer, zulässige Messabweichungen, mechanische Einschränkungen, Trigger, Umgebung (Luftfeuchtigkeit, Druck, Ex, Staub, EMV, etc.), zu überbrückende Entfernungen, geht (nur) Kable, muss/darf es (teilweise) Funk sein, Genauigkeit der Zeitsynchronisation, Datenmengen, Zuverlässigkeit, Langzeit-Ersatzteilversorgung usw. usw. > "echtzeitfähig" sollte das ganze jedoch schon sein, > - Welche Protokolle nutzt man am besten, um die Daten von den einzelnen > verteilten Modulen zu übertragen und zu sammeln? Das hängt davon ab welche Messwertaufnehmer man bekommt, welche A/D-Wandler (in welcher Form) geeignet sind, wie gut die Zeitsynchronisation sein muss (z.B. brauchst du IEEE 1588 Precision Time, wie in LXI Klasse B oder besser? Für alle Messgeräte? Für einige?), wie weit Daten übertragen werden müssen, usw. usw. Das Ganze ist ein iterativer Prozess. Was könnte funktionieren? Was brauche ich dafür? Was kann ich bekommen? Wo kann ich kombinieren/optimieren/sparen? Brauche ich das wirklich? Was könnte ... NI als Hersteller wurde schon genannt. Dort kannst du dir in deren Produktpalette ansehen wie man was heutzutage so macht. Man muss ja nicht unbedingt NI kaufen. Ich habe schon Leute gesehen, die sich erst ein $$$ NI-System zusammengestellt haben um zum Schluss alles durch ein für DAQ Systeme Low-End Rigol M302 zu ersetzen. Weil sie nach einigem Nachdenken kein besonders genaues Timing brauchten, dem A/D-Wandler im Rigol (Multimetermodul) ausreichend vertrauten und alle Messfühler sowieso dicht beieinander waren.
Schau dir doch mal Tinkerforge an. Nach deiner und deren Beschreibung, solltet ihr zusammen passen. http://www.tinkerforge.com/de https://de.wikipedia.org/wiki/Tinkerforge
Der Einwand von "butsu" ist absolut richtig, auch (die eigene) Arbeitszeit kostet Geld bzw. ist nur begrenzt vorhanden. Irgendwann will man ja auch mal Ergebnisse sehen, auch der Fördermittelgeber. Ich habe damals als Doktorand per PCI Multi-I/O-Karten eine eigentlich für dSpace gedachte Umrichter-Anbindung auf Matlab xPC Target umgebogen. Das hat am Ende zwar funktioniert, hat mich aber unendlich viel Zeit gekostet und war von der Performance her der dSpace Lösung deutlich unterlegen. Das alles nur um das Geld für die dSpace-Hardware zu sparen. Ich würde mir an deiner Stelle mal TwinCAT3 von Beckhoff ansehen. Da gibt es inzwischen eine direkte Matlab-Anbindung, und die Hardware ist deutlich günstiger und vielfältiger als bei Labview. Für Hochschulen gibt es sicher auch vergünstigte Lizenzen. Du kannst dann aus jedem Gerät einen EtherCAT-Knoten machen, die dann flexibel zu- und abgeschaltet werden können. Die Projektierung der I/Os ist immernoch aufwändig genug für eine Studien- oder Bachelor-Arbeit. Mit freundlichen Grüßen Thorsten Ostermann
Viktor Hartung schrieb: > ich arbeite in einem Forschungsinstitut einer Hochschule, wir haben > verschiedene Maschinen (unter anderem eine Dieselpumpe, ein Bohrgerät, > eine Wasseraufbereitungsanlage) die mit unterschiedlichen Steuerungen > ausgestattet sind und in Container-Bauweise gebaut sind (für den > Transport). Teilweise stehen hier auch einzelne Messgeräte wie z.B. > Durchflussmessgeräte. Wir möchten bei unseren Versuchen gerne die > Messdaten möglichst aller Maschinen aufzeichnen und später auswerten. Das hört sich nach einem Outdooreinsatz aus. Die meisten fertigen "Laborlösungen" sind oft nicht baustellentauglich. Das fängt bei mechanischen Belastungen an, geht über gering qualifiziertes Personal und hört bei einer unzuverlässigen Stromversorgung noch lange nicht auf. Viktor Hartung schrieb: > Ich würde gerne jede Maschine mit einem "Modul" ausstatten, welches an > die Steuerung angeschlossen wird und die Daten der Maschine z.B. über > Ethernet an einen Server oder Master oder ähnliches überträgt. Die Frage ist, ob die jeweiligen Steuerungen die Messdaten überhaupt rausrücken, oder ob man jeden Sensor nochmal selbst auswerten muss. Wenn die Steuerungen die Messdaten rausrücken, dann musst du dir für jede Maschine anschauen in welcher Form das geschieht. Danach suchst du ein Gerät (Gateway) / eine Geräteserie, dass möglichst alle Formate einlesen kann und schaust, wie du es auf ein einheitliches Format ausgibst. Ethernet o.ä. bietet sich natürlich an.
Moin, da ich teils auch mit begrenztem Budget den Internet Of Things-Hype bedienen muss, einige Anregungen: - Mit Linkit 7688 Duo kann man nette Sachen machen, analog RPI, aber mit Realtime und Analog-Option über den zweiten AVR-Prozessor. Allerdings brauchts für Ethernet ein kleines Basisboard. Das ist typischerweise eine Kundenanpassung. HW-Kosten um die 20-30 €, Produktion/Design nicht eingerechnet (dafür gibts billige Studenten :-) ). Das eingebaute WLAN nutze ich typischerweise nur für die Erstkonfiguration und schalte es nachher ab, das bringt im rauhen Betrieb mit >100 Teilnehmern teils wenig. - Für die Abfrage, Fernsteuerung usw. tut netpp, das lässt sich auch auf modbus oder CAN wrappen. CAN kann allerdings der 7688 Duo nicht. - Ein Master-Server macht die Prozesskontrolle mit pvbrowser, d.h. fragt alle Sensoren/Messwerte per netpp ab und zeigt sie in einer GUI an. Zu netpp: Ist quasi was wie modbus auf Speed oder GenICam/EDDL für embedded devices. Passt z.B. auch auf einen MSP430 wireless sensor. Im Prinzip ist es ein Abstraktions-Layer für Register, das Design geschieht in einer XML-Beschreibungssprache über div. GUI-Editoren, daraus wird C-Code gebacken. Ist für Linux opensource und für eine Latte an Plattformen portierbar. Ich habe früher mal mit Labview rumgemacht, und würde da folgende Überlegung machen: typischerweise sieht die Kundenbindung dieser Firmen so aus, dass man möglichst deren Equipment nutzt und die Software alle paar Jahre auch neu lizenziert. Insofern ist die Wartung eine teure Geschichte. Aber vom Marketing-Standpunkt aus sieht Labview natürlich geil aus: Man hat schnell mal was am laufen, was für Projektanwerbung nützlich sein kann. Bekommt man aber auch mit pvbrowser oder myopenlab (Java-Labview-Variante mit einigen Schwächen, aber benutzbar) hin. Fazit bei den Labview-Sachen ist leider oft der: Derjenige, der die Schaltung gezeichnet hat, ist irgendwann nicht mehr an der Uni, und keiner will das Ding mehr anfassen oder debuggen. Ergo ist die Wiederverwertbarkeit bei "grafischer Programmierung" für die Katz. Die Wiederverwertbarkeit war bisher IMHO per Python optimal. Das ist in 10 Jahren noch lesbar/wartbar/nutzbar und abwärtskompatibel und es gibt ein riesen Sammelsurium an Modulen (gnuplot, octave-Interfaces, Datenbanken...) Grüsse, - Strubi
Viktor Hartung schrieb: > Ich würde gerne jede Maschine mit einem "Modul" ausstatten, welches an > die Steuerung angeschlossen wird und die Daten der Maschine z.B. über > Ethernet an einen Server oder Master oder ähnliches überträgt. Darauf darfst du nicht hoffen. Und selbst wenn Steuerungen so ein Interface haben, dann hat jede ein anderes. Einen Ethernet-Anschluss hat heute wohl jede Steuerung, aber die Software zu hacken um Messwerte auszugeben, bei denen das nicht vorgesehen ist, ist keine akzeptable Lösung. Ich würde daher erst mal eine Aufstellung machen, welche Werte aufgezeichnet werden sollen, und dann zu jedem Wert klären wie man drankommt. Dann bekommt man eher eine Übersicht, was an Hardware benötigt wird. Im Detail kann das recht aufwendig werden, so ist z.B. bei einem Motor Drehzahl, Leistung oder Drehmoment nicht ohne weiteres zugänglich, wenn er von irgendeiner Steuerung angesteuert wird. Temperaturen sind da viel einfacher. Ob da wirklich mal was verwertbares rauskommt oder ob es sich bloss um sinnfreien Füllstoff für Semesterarbeiten oder ähnliches handelt, ist noch eine ganz andere Frage. Vielleicht ist es ja mit einem theoretischen Konzept getan, egal ob realisierbar oder nicht. Georg
Vielen Dank zuerst einmal in die Runde für die zahlreichen Tipps! Das hilft mir schon viel weiter. Die Entscheidung, wie das nun umgesetzt wird, ist noch in weiter Ferne, ich möchte mir im Vorraus ein paar Anregungen holen. Es ist ein Abwägen zwischen vielen Punkten, die hier auch erwähnt wurden. Den Punkt mit dem Programmieren muss ich noch ergänzen: Es sollte einfach gehalten werden, also nur das Wesentliche soll programmiert werden, aus den Gründen, die hier genannt wurden. Ob die Schnittstelle zwischen Steuerung/Sensoren und eventuellem Feldbus nun beispielsweise in C oder Python geschrieben wurde und damit universell anpassbar ist oder ob man sich Dinge einkauft, die solche Funktionen bereits können und "nur" konfiguriert werden müssen, müssen wir uns auch genauestens überlegen. Gründe dazu wurden von mehreren von euch ja genannt. ÄtschiBätschelor schrieb: > 2) Frag mal, wie viele der Maschinen weniger als 20k€ gekostet haben. > Das riecht mir nach den üblichen sinnlosen bsc/Master Arbeiten, die von > vornherein zum scheitern verurteilt sind. Und weil das bis auf den > Studenten schon alle vorher wissenoch, gibt dafür auch kein Budget. Auch > eine Form von Verantwortungsvollem Umgang mit Fördergeldern. Das kann ich so unkommentiert nicht stehen lassen, das wäre nicht fair. Die Maschinen sind bereits älter und wurden für andere, völlig unterschiedliche Projekte beschafft. Es war damals nicht absehbar, wie diese heute eingesetzt werden und für Dinge, von denen man noch nicht weiß, ob und wie man sie braucht, sind bei Ausschreibungen in der Regel keine Gelder vorgesehen. Wenn jeder Mitarbeiter Sonderwünsche anmeldet wird das völlig unübersichtlich. Jetzt geht es darum, diese in den kommenden Projekten weiterhin zu nutzen und auf die neuen Anforderungen anzupassen und Neuanschaffungen entsprechend auszurüsten, im konkreten geht es um meine Doktorarbeit und die eines Kollegen. Max G. schrieb: > Die wichtigste Frage ist eigentlich "wie stelle ich sicher, dass es in > 10 Jahren immer noch funktioniert und repariert werden kann?". Strubi schrieb: > Fazit bei den Labview-Sachen ist leider oft der: Derjenige, der die > Schaltung gezeichnet hat, ist irgendwann nicht mehr an der Uni, und > keiner will das Ding mehr anfassen oder debuggen. Ergo ist die > Wiederverwertbarkeit bei "grafischer Programmierung" für die Katz. > Die Wiederverwertbarkeit war bisher IMHO per Python optimal. Das ist ein sehr wichtiger Punkt, es nutzt nichts, wenn die allerbesten Programme geschrieben werden, die nachher keiner mehr versteht, die niemand erweitern kann und dann derjenige, der das geschrieben hat, nicht mehr da ist. Daher wäre mir eine Art "Standard" schon lieb, dann kann man sagen: "Hey, das ist ein verbreitetes xyz-System vom Hersteller blabla". Karl schrieb: > Das hört sich nach einem Outdooreinsatz aus. Die meisten fertigen > "Laborlösungen" sind oft nicht baustellentauglich. Das fängt bei > mechanischen Belastungen an, geht über gering qualifiziertes Personal > und hört bei einer unzuverlässigen Stromversorgung noch lange nicht auf. Völlig richtig, es geht hier um Outdoor-Einsatz. Es ist aber kein Problem, die bestehenden Schaltschränke zu erweitern. Ich kann bei einer dieselbetriebenen Pumpe, die auf einem LKW-Anhänger steht, keine Breadboard-Experimente machen. Karl schrieb: > Die Frage ist, ob die jeweiligen Steuerungen die Messdaten überhaupt > rausrücken, oder ob man jeden Sensor nochmal selbst auswerten muss. Wenn > die Steuerungen die Messdaten rausrücken, dann musst du dir für jede > Maschine anschauen in welcher Form das geschieht. Danach suchst du ein > Gerät (Gateway) / eine Geräteserie, dass möglichst alle Formate einlesen > kann und schaust, wie du es auf ein einheitliches Format ausgibst. > Ethernet o.ä. bietet sich natürlich an. Bisher hatten wir damit sehr gute Erfahrungen gemacht, die Hersteller unserer Maschinen sind da wirklich sehr kooperativ. Solche Änderungswünsche haben wir immer wieder. Wenn wir dort eine Schnittstelle brauchen, bekommen wir das auch. Man muss nur genau wissen, was man will ;)
Ich empfehle Dir entweder eine Beckhoff oder Siemens Steuerung dafür ein zu setzen. Die sind dafür bereits fertig ausgelegt um im industriellen Umfeld sicher zu laufen. Schnittstellen-Module gibt es dafür auch diverse, auch von Drittherstellern. Die Programmierumgebung ist bei beiden Standard, das Programm kann somit jeder SPS Programmierer warten. Die Komponenten sind problemlos tauschbar, wenn mal was kaputt geht. Als Maschinensteuerung(-steil) ein Raspi zu verwenden ist äußerst gewagt, ich kann von dieser Bastel-Lösung nur abraten.
Markus M. schrieb: > Als Maschinensteuerung(-steil) ein Raspi zu verwenden ist äußerst > gewagt, ich kann von dieser Bastel-Lösung nur abraten. Aus welchen Gründen denn?
Nur mal angenommen du gehst weg, bist krank, oder gar tot. Wer soll das dann noch warten können? So ein gebastel geht überhaupt nicht in Dinge die funktionieren müssen. Wenn wegen EMV Problemen oder falsch ausgelegtem Netzteil das Teil abraucht, wenn man die Maschine dringend braucht, dann wird das richtig teuer - und Du garantiert deinen Job los. Nehme nur und ausschließlich Teile die in der Industrie verwendet werden, dann kann nur noch deine Software schlecht sein, das Hardware-Risiko ist damit ausgeschlossen. Für zu Hause mag der Raspi ja ganz Nett sein, da bist du auch dein eigener Chef, aber nicht in der Firma, schon gar nicht wenn es Geräte für Notfälle sind.
:
Bearbeitet durch User
Markus M. schrieb: > Nur mal angenommen du gehst weg, bist krank, oder gar tot. Wer soll das > dann noch warten können? Jeder, der die Dokumentation gelesen hat und an dem Projekt beteiligt war. > So ein gebastel geht überhaupt nicht in Dinge die funktionieren müssen. > Wenn wegen EMV Problemen oder falsch ausgelegtem Netzteil das Teil > abraucht, wenn man die Maschine dringend braucht, dann wird das richtig > teuer - und Du garantiert deinen Job los. Komisch, abgerauchte Netzteile begegnen mir regelmäßig -- aber die sind vom Hersteller der Geräte mitgeliefert worden, so daß ich davon ausgehe, daß sie richtig dimenstioniert waren. Will sagen: Defekte können überall passieren, auch bei teuren, kommerziellen Industriegeräten, die explizit für den 24/7-Betrieb vorgesehen und konstruiert sind. > Nehme nur und ausschließlich Teile die in der Industrie verwendet > werden, dann kann nur noch deine Software schlecht sein, das > Hardware-Risiko ist damit ausgeschlossen. Ach, das wäre schön... leider zeigt die Erfahrung, daß das Hardware-Risiko niemals ausgeschlossen werden kann. Und je "Industrie" ein Gerät ist, umso schwieriger, teurer und zeitaufwändiger ist es oft, Ersatz zu bekommen. > Für zu Hause mag der Raspi ja ganz Nett sein, da bist du auch dein > eigener Chef, aber nicht in der Firma, schon gar nicht wenn es Geräte > für Notfälle sind. Das ist insofern ganz lustig, als mir alle naselang kommerzielle Hardware über den Weg läuft, die nicht tut, was sie soll. Gerade heute wieder: ein durchaus nicht ganz billiger KVM-Switch, gestern: ein SMS-Modem, das sich partout nicht softresetten lassen will. Alles hochwertige Industrieware, kein billiger China-Mist. ;-) Im Übrigen kann, nein: muß man Selbstgebautes nur vernünftig dokumentieren und Kollegen daran teilhaben lassen. Dann können die das Ganze auch dann weiterbetreiben, wenn ich weg, krank, oder tot bin. Dieses Vorgehen ist in verschiedenen Arbeitsbereichen (Systemadministration, Architektur, usw.) vollkommen normal, warum sollte das anderswo nicht auch gehen?
Viktor Hartung schrieb: > Ich kann bei einer dieselbetriebenen Pumpe, die auf einem > LKW-Anhänger steht, keine Breadboard-Experimente machen. Beckhoff. Da gibts auch Komponenten zertifiziert nach Germanischer Lloyd. Da macht das bisschen rütteln vom Diesel nichts. Im Extremfall gibt es da jetzt auch ganz neu so ein IoT-Koppler, da musst Du nichts mehr programmieren: Einfach in den Schaltschrank und Busklemmen für Sensoren dazu. Das ganze per Browser konfigurieren, Internetverbindung ran, und das Teil pumpt die Daten völlig autonom in die Cloud. Dann bequem im Büro die Daten ziehen/verarbeiten oder eben auch in der Cloud, wenn's dann sein muss. Egal wo die Maschinen stehen, einfach Internet dran, und gut ist. Allerdings kostet das Zeug auch mehr als ein Raspi. Ist halt eine Frage, was das für Maschinen sind, wieviel sie Wert sind, und ihre erwartete Restlebensdauer.
Ich bezweifle dass es da EINE Lösung gibt. Viele Geräte haben - schon für die Eigenfunktion - Messgeräte, rücken aber die Daten nicht raus. Natürlich würden sich die meisten Herstellen freuen Dir eine Erweiterung zu liefern, die Deine Wünsche erfüllt. Dazu musst Du aber genau wissen, was Du willst, damit die das auch implementieren können. Alternativ würden die auch freuen, wenn Du die internen Messgeräte anzapfst. Dann sind die Garantie und Wartung endlich vom Tisch. Da Du an verschiedenen Geräten messen willst und auch noch verschiedene Sachen messen willst, wird das Ganze ganz schnell zu einem Messgeräte- und Messdatengrab. Auch die nötige Logik ist nicht ganz ohne. Was nutzt z.B. die minutiöse Registrierung einer Temperatur ohne die zugehörige Menge? Dann geht es aber auch schon bald los mit der Problematik: Ist Null ein gültiger Wert oder ein gebrochener Draht oder hat so ein Dödel die Maschine abgeschaltet? Zig Werte wollen auch verteilt (übertragen) und empfangen werden. Eventuell ein Großauftrag (wg. Verkabelung) für den örtlichen Elektrobetrieb? Dann gibt es auch noch die Problematik der Genauigkeiten und Formate... Also wenn Du Dir bisher vor Langeweile die Fingernägel bis zu den Ellenbogen hin abgeknabbert hast: Hau rein! Ist interessant, vielseitig und reicht für ewig und drei Tage. Viel Spaß also. Wenn nicht: Lass Dir von den Initiatoren ein paar Vorgaben machen. Das nennt man dann schwarzer Peter spielen. Und man kann feststellen, ob das Ganze nicht nur eine Schnapsidee war. P.S. Hier stürzt man sich immer sehr schnell auf: "Am Besten nimmst Du Siemens, Berkhoff, B&R...". Das würde ich mir bis zuletzt aufheben. Da gibt es kein "besser".
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.