Hallo zusammen, ich bin auf der Suche nach einem USB-Oszilloskop. Dieses sollte folgende Kriterien erfüllen bis 25MHz min 4 Kanäle Aufzeichnung der Daten (nicht nur gesetzte Triggerpunkte) auf der Festplatte des PC via Software. Robust und wenn möglich klein :-) Habe jetzt schon bei mehreren Herstellern angefragt aber die können nur gewisse Triggerpunkte aufzeichnen was mir nicht weiter hilft. Vielleicht hat das gute alte Schwarmwissen ja eine Abhilfe :-)# Danke und LG
Ja. Aber die können nur triggerwerte speichern oder man muss selber was programmieren. So die Aussage des Vertriebs Deutschland. Aber danke
Was meinst du damit, dass sie nur Triggerwerte speichern können?
Du kannst da wohl laut Aussage gewisse Grenzwerte setzen. Wenn diese über oder unterschritten werden wird das gespeichert. Aber keine durchgängige Kurve. Das wäre aber bei uns von Nöten.
Was willst du den genau? Willst du kontinuierlich die Daten auf die Festplatte schreiben? Willst du bei einem Triggerereignis das Oszi starten und das, was danach vom Oszi aufgezeichnet wurde, auf die Festplatte speichern? In welchem Format? Was soll mit den Daten also danach geschehen?
Ich möchte über einen längeren Zeitraum signale Monitoren. Schaltzustände Gebersignale usw. Anhand des logbuches an unseren Maschinen kann man dann sehen wann die Maschine einen Fehler hatte. Dann würde ich gerne die aufgezeichneten Signale zu dem Zeitpunkt anschauen. Hoffe das hilft weiter.
du wirst wohl an irgendeiner stelle ums programmieren nicht herum kommen, irgendwann wirst du ja mit den daten mal irgendwas tun wollen ... Wenn du dir Aufwand sparen willst gibts die NI Messkarten mit klickibunti, billig wird das aber nicht.
Schaue mir das mal an aber ich denke billiger wie ein fluke welches wir derzeit im Einsatz haben allemal. Danke für die Antwort
Ok, verstanden. Egientlich brauchst du da eher nen Datenlogger, als ein Oszilloskop. Aber natürlich kann man auch ein Oszilloskop als Datenlogger verwenden. Das grundlegende Problem: Wenn du kontinuierlich die Daten schreiben willst, dann musst du sicherstellen, dass du die Daten nicht schneller erfasst, als sie dann auf die Festplatte geschrieben werden können. Sonst läuft dein Speicher des Oszis über. Wenn du also mit z.B. 100Ms/s aufzeichnest, dann musst du auch in "Echtzeit" die 100Ms/s auf die Festplatte schaufeln können. Mit welchen Abtastraten willst du denn Arbeiten? Du hast na nur 25MHz Bandbreite angegeben.
Die schnellsten Motoren laufen mit 3000rpm. Die Geber schicken je umdrehung 1000 Signale. Heisst also maximal 3000000 Signale pro Minute. Müsste also eine Stadträte von 100khz haben um auf der sicheren Seite zu sein.
Du steckst halt ein wenig in dem Dilemma, dass du zum einen recht schnelle Signale erfassen willst. Zum anderen aber auch sehr lange Aufzeichnungszeiten hast. Aber ich vermute, dass du da bei den Datenloggern eher fündig wirst. 1MS/s Abtastrate wären ausreichend. Und Datenlogger sind eher darauf "getrimmt" endlos mit zu loggen und die Daten auf die Festplatte zu schaufeln. Könnte mir vorstellen, dass da die mitgelieferte Software eine Lösung anbietet. Eher jedenfalls, als bei den Oszilloskopen. Hab grad mal bei Pico auf der HP geschaut: https://www.pico-technology-deutschland.de/PicoLog-Software-Download-kostenlos_1 Allerdings steht da: "Sammeln sie bis zu 1 Million Messwerte" Was bei 1MS/s gerade mal 1 Sekunde Aufzeichnungsdauer wäre. So wie ich es verstehe, willst du eigentlich zwei Sachen: 1. Eine Art Maschinenlogbuch führen Da stellt sich die Frage, ob dazu die Gebersignale aufgezeichnet werden müssen, oder ob es dazu ausreichend ist, langsamere Signale aufzuzeichnen 2. Im Fehlerfall eine datailliere, hochauflösende Information von der Maschine bekommen (z.B. Gebersignale) Vielleicht musst du beides kombinieren: Für das Logbuch zeichnest du wichtige Maschinenparameter langsam, aber kontinuierlich auf. Tritt ein Fehler auf, erzeugt die Maschine ein Triggersignal, welches einen weiteren Logger (oder Oszi) mit höherer Auflösung triggert. Mit einem großen Pretrigger (100%), könntest du dann einen gewissen Zeitraum hochauflösend abspeichern, der unmittelbar vor Erzeugung des Fehlersignals liegt.
Es klingt, als wäre ein 7EUR Logic Analyzer (saleae clone) möglicherweise schon ausreichend. Sustained data rate, wenn der Rechner schnell genug ist, 24 bzw. 48MS/s. Ist natürlich nur digital, nicht mit einem Analog Oszi zu vergleichen, aber je nachdem was du unter 'längere Zeit' verstehst, wäre das sonst sowieso ein Sportliches Unterfangen (>=4 Channel x >= 8bit x >= MS/s...). Wenn es nur um Drehgeber und andere Logiksignale geht, würde ich es damit versuchen. Die Software kommt auch mit erstaunlich langen Aufnahmen noch recht gut zurecht, wobei dem natürlich auch irgendwo Grenzen gesetzt sind!
:
Bearbeitet durch User
Ich versuche das jetzt mal an hand von Beispielen zu erklären. Wie schon gesagt unsere Motoren laufen max mit 3000 Umdrehungen aber werden über einen Frequenzumwandler in der Geschwindigkeit gesteuert. 300 bis 3000 Umdrehungen. Die Geber geben immer 1000 Signale (TTL) pro Umdrehung. Dadurch werden die einzelnen Maschinenteile übe eine sogenannte elektronische Welle synchronisiert. Sagen wir mal die Maschine geht um 23:57 in einen Notstop. Der Maschinenführer kann direkt den Fehler quittieren und weiter fahren weil der Fehler nicht mehr vorhanden ist. Dies passiert wenn der Geber ab und an einen "Wackelkontakt" hat und mal nicht 1000 Signale sondern nur 995 (ein Beispiel) abgibt. Jetzt könnte ich mir morgens die Aufgezeichneten Kurven ansehen und mir den Zeitraum um 23:57 anschauen. (die Uhrzeit des Fehlers entnehme ich dem LOG an der Maschine selber in de alle Fehler Protokolliert werden, aber nicht im Detail)Sind die Signale sauber, sind alle da, usw. Gleiches wäre dann auch für einzelne Schaltzustände die Voraussetzung für das Betreiben der Maschine sind, geschehen. Wie gesagt ich muss auch die Kurve sehen um eine qualitative Aussage zu treffen. Aufgrund der Unterschiedlichen Drehzahlen und auch der Unterschiedlichen Schlatzustände denke ich nicht das ich mit einem Trigger arbeiten kann. Naja ich gebe die Hoffnung nicht auf. :-)
Ich hab einfach nur aus Interesse noch ein bisschen auf der PICO Seite gestöbert. Da gibt es das PicoScope 4444 4 differenzielle Eingänge (was bei Messungen an Maschinen sicher kein Fehler ist) 265kS Speicher Und die SDK liefert einen Treiber, der eine Streaming-Funktion über USB3.0 unterstützt.. Also eigentlich genau das, was du suchst. Aaaaber: Man muss selbst programmieren :-(
pfusch-quick'n'dirty-lösung: usb-soundkarte die mit 192kHz aufnehmen kann plus passendes Aufnahmeprogramm. Ganz egal mit welcher Technik man das aufnimmt wird man bei langen Laufzeiten ein Problem mit auseinanderlaufenden Uhren/Takten haben, ein paar µs Versatz fängt man sich schnell ein...
Detlef G. schrieb: > Aufgrund der Unterschiedlichen Drehzahlen und auch der Unterschiedlichen > Schlatzustände denke ich nicht das ich mit einem Trigger arbeiten kann. Kannst du ermitteln, wie lange es im dümmsten Fall dauert, von Eintreten des Fehlers am Geber, bis zur Abschaltung der Maschine? Angenommen, es wären 100ms: Dann könntest du einen Triggersignal generieren, das deinen Logger/Oszi triggert. Mit einer Abtastrate von 1MS/s würdest du 100kS benötigen, um die 100ms VOR Auftreten des Triggers zu erfassen.
Geht es bei den Drehgebern um TTL Logiksignale, oder ist das eher irgendeine Industrieschnittstelle? Falls ersteres, bleibe ich bei meinem Vorschlag billiger 10eur logikanalyzer mit kontinuierlicher ununterbrochener Erfassung, wenn eine minimale manuelle Interaktion vertretbar ist. Je Gerät sind typischerweiseweise 8 bis 16 Kanäle möglich. Verkabel die, wo benötigt, und starte ein Logging mit gerade noch akzekptabler sampling rate, sagen wir 1MS/s bei 100kHz zählrate. Gabs nachts keinen Fehler, verwerfen die Messung am Morgen und starte direkt eine neue. Gab es einen Fehler um 4.03 Uhr nachts der behoben werden konnte, beende die das logging am nächsten Morgen an einer schönen Stelle, sagen wir 10.03, und sprint exakt 6h zurück (diese Grundfunktionen funktionieren hoffentlich bei so großen Dateien noch). Schau dir den Salat an. Speichere den interessanten Abschnitt und starte eine neue Messung. Ein explizites triggern auf zu lange/kurze/falsche pulse in so einer Maschinenumgebung wird vermutlich nicht besser funktionieren, zumal die billigen Analyzer keine echten trigger Stufen haben und meist auch nicht auf allen Kanälen gleichzeitig triggern können. Dies wird dir eine Idee geben, ob und wie aufschlussreich eine solche Erfassung in der Praxis überhaupt ist, und ist mit ein paar Handgriffen erledigt. Kostet nix.
Schlumpf schrieb: > Dann könntest du einen Triggersignal generieren, das deinen Logger/Oszi > triggert. Das ist eine exzellente Idee!
Hat man sich auch mal Gedanken um die Datenmengen gemacht, die dabei rum kommen? Bei 100 kSPS macht das 100.000 Werte pro Sekunde. Gehen wir mal von 8 bit aus pro Wert sind das 100.000 Bytes/s. Und das über ne Nacht, also so 8-10h, ja? Sind ja nur läpische 100.000 Bytes/s * 3600 s/h * 10 h, also lächerliche 3,35 GB Daten...für eine Nacht/Schicht...pro Wert, der überwacht werden soll...ist IMO ja nicht sehr sinnvoll. Und das war jetzt nur bei 100 kSPS gerechnet, für ein Oszi ist das eine sehr lächerliche Abtastrate. Die sind üblicher Weise ein-zwei Zehnerpotenzen höher.
:
Bearbeitet durch User
laufen die Motoren nur vorwärts? gebt der Encoder Mist aus, oder vermutest du, dass einzelne Impulse von a oder B fehlen? wenn beides erfüllt ist müsste das ein gutes oszi Triggern können. Bei einem vorwärts laufenden Motor gibt es zb die Bedingung A=0 und B Steigend oder A=1 und B fallend nicht. darauf könnte man auch Triggern. genauso kannst du auf den Notaus oder das unterschreiten der Drehzahl Triggern und dann die letzten 2 sec aufbewahren. mein Gerät der Wahl wäre ein saleae logic pro mit analogen und digitalen Signalen. sg
Detlef G. schrieb: > Ja. Aber die können nur triggerwerte speichern oder man muss selber was > programmieren. So die Aussage des Vertriebs Deutschland. Aber danke Da hättest Du besser auf der PicoTech Homepage den Support gefragt. Detlef G. schrieb: > Ich versuche das jetzt mal an hand von Beispielen zu erklären. na endlich. Aber das hört sich nicht nach Oszi an sondern nach einem Hochgeschwindigkeits-Datenlogger. (Firma DEWETRON macht so was: aber nicht ganz billig). M. K. schrieb: > Hat man sich auch mal Gedanken um die Datenmengen gemacht, die dabei rum > kommen? Bei 100 kSPS macht das 100.000 Werte pro Sekunde. Die muß mann dann auch noch durchsuchen (und das ohne Zeitstempel?) Womöglich noch mit auseinanderdriftenden Zeitbasen. Schlumpf schrieb: > Angenommen, es wären 100ms: > Dann könntest du einen Triggersignal generieren, das deinen Logger/Oszi > triggert. Eigentlich müßte ja wenn die Maschine stehenbleibt auch das Encoder-Signal langsamer werden oder? da braucht man nur auf ausbleibende Flanken zu triggern und die Daten dann automatisch mit Zeitstempel speichern. Schlumpf schrieb: > Da gibt es das PicoScope 4444 > 4 differenzielle Eingänge (was bei Messungen an Maschinen sicher kein > Fehler ist) > 265kS Speicher es sind 256 MS Speicher (also das tausendfache) wobei der Streaming mode bei der PC-Software auf 100 MS limitiert ist. (das reicht aber immer noch für 100 Sekunden bei 1us Abtastauflösung. Die Frage ist natürlich ob man durch das Messen den Prüfling so stark verändert daß andere Effekte auftreten. Ein differentielles Oszi oder Tastkopf hat da gewisse Vorteile. Ansonsten würde ich es mit einem PicoScope so lösen. - z.B. 1sek/div mit 10MS/s Abtastrate bei 90% Triggervorlauf - Trigger auf ausbleibende Pulse. - Alarm bei Puffer voll (segmentierte Puffer deaktivieren) und Speicherung mit "Beep" damit der Bediener weiß wann er wieder starten darf. - Die Dateien werden dann mit Zeitstempel abgelegt. - mit der Zoom-Funktion kann dann das Event vergrößert werden Gruß Anja
By the way: Es gibt auch noch eine 8-Kanal-Version mit 20 MHz Bandbreite PicoScope 4824. (allerdings nicht differentiell) Gruß Anja
Detlef G. schrieb: > Die Geber geben immer 1000 Signale (TTL) pro Umdrehung M. K. schrieb: > Bei 100 kSPS macht das 100.000 Werte pro Sekunde. Gehen wir mal > von 8 bit aus pro Wert sind das 100.000 Bytes/s. Es ist wohl an der Zeit, zu klären, ob es sich bei den aufzuzeichnenden Signalen um Digital- oder Analogsignale handelt.
Vermutlich EMV-Störungen auf einem ansonsten digitalen Signal. Die Frage ist halt ob das Oszi das gleiche "sieht" wie die Auswerteschaltung. Gruß Anja
Anja schrieb: > Vermutlich EMV-Störungen auf einem ansonsten digitalen Signal. "EMV-Störungen" ist ein Widerspruch in sich, jedenfalls wenn die Störungen so groß sind, dass sie stören. Ansonsten ist elektomagnetische Verträglichkeit beste Voraussetzung für friedliche Koexistens ;-) Wie sollen durch Störungen aus normalerweise 1000 Pulsen pro Umdrehung plötzlich 995 werden. Dafür müssten schon massive Störpegel das Signal unter die Schaltschwelle verschieben. Es bleibt spannend ...
Hi, ich verstehe nicht warum du absolut unwichtige Daten speichern willst. Du brauchst doch nur die Daten welche vor dem Triggerereignis "Notstop" anfallen. Dafür reicht ein normales Digitaloszi in Sigelmode. Der Trigger kommmt auf 95% Postmode (oder eben ganz rechts auf dem Bildschirm) und du hast alle Daten die du brauchst. So habe ich jedenfalls schon Aussetzer an HF Härteanlagen gefunden wo selbst der Herstellerservice graue Haare bekommen hat. Je mehr Kanäle das Ding hat um so besser. Die Speichertiefe sollte aber nicht zu gering ausfallen wenn du noch irgendwas vernünftiges zoomen möchtest. >Es gibt auch noch eine 8-Kanal-Version mit 20 MHz Bandbreite >PicoScope 4824. Wenn die MSpS, die Speichertiefe und die Eingänge passen kann man durchaus auch mit sowas arbeiten. Zu DDR Zeiten habe ich mit einem Vorsatzgerät zum analogen Oszi angefangen. Mit 4 Kanälen 100ksps und 256kB Speicher je Kanal ist das auch gegangen. Also ran an den Speck und viel Erfolg, Uwe
Bitte 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.