Hallo!
Ich verwende eine CEBO LC in einem Schaltschrank zusammen mit einem Revolution Pi (basiert auf RPi Compute Module 3) und steuere diese über die Python-API an. Kontinuierliche Messung mit 2000 Hz auf zwei Analogkanälen, abgerufen in Blöcken von 100 Frames.
Leider treten immer wieder während der Messung Probleme auf, für die ich keine sinnvolle Erklärung finde. Am häufigsten und scheinbar willkürlich findet sich solch eine Meldung:
Manchmal ist beim nächsten Aufruf von
Manchmal folgt dem Fehler noch eine Flut von Meldungen bzgl. Pufferüberlauf. Das ist allerdings zu erwarten, wenn das Abrufen der Daten länger nicht geklappt hat:
Zur gleichen Zeit (aber nur einmalig) fand sich im Kernel-Log die folgende Meldung:
Insbesondere nachdem solch ein
Display All
Das alles klingt mir nach gelegentlichen Übertragungsproblemen am USB. Verkabelung ist jedoch sehr gewöhnlich: 0,5 m USB-Kabel gut geschirmt inkl. Ferrit, im Schaltschrank drumherum ist sonst nichts aktiv, was ggf. EMV-Störungen aussendet. Die Probleme treten bei mehreren Systemen an unterschiedlichen Standorten auf. Der Rechner ist wie gesagt eine industrielle Implementierung des Raspberry Pi Compute Module 3 (RevPi Connect) mit realtime-Kernel. Ich sehe keinen Grund, warum dieser auf dem USB Probleme bereiten sollte.
Wie kann ich so einen Fehler weiter diagnostizieren? Geben die Fehlermeldungen für die Cesys-Leute Aufschluss über eine mögliche Fehlerursache? Insbesondere bei der Meldung
Über jegliche Hilfestellung wäre ich sehr dankbar. Wir haben bereits in drei CEBO LC investiert und müssten notfalls (und ungern) den Hersteller wechseln, wenn kein robuster Betrieb erreicht werden kann.
Vielen Dank im Voraus!
André
Ich verwende eine CEBO LC in einem Schaltschrank zusammen mit einem Revolution Pi (basiert auf RPi Compute Module 3) und steuere diese über die Python-API an. Kontinuierliche Messung mit 2000 Hz auf zwei Analogkanälen, abgerufen in Blöcken von 100 Frames.
Leider treten immer wieder während der Messung Probleme auf, für die ich keine sinnvolle Erklärung finde. Am häufigsten und scheinbar willkürlich findet sich solch eine Meldung:
Source Code
- Traceback (most recent call last):
- File "/home/pi/src/bsp/bsp_ts/measure-cpu/pump_logic/adc_cebo.py", line 74, in acquire
- frames = device.readBlocking(self.BLOCK_SIZE)
- File "/home/pi/src/teststand-venv/lib/python3.5/site-packages/CeboMsrApiPython.py", line 1018, in readBlocking
- _ReadBlocking(self._handle, vvalues, values, frameCount)
- File "/home/pi/src/teststand-venv/lib/python3.5/site-packages/CeboMsrApiPython.py", line 95, in _checkError
- }.get(errorClass, NotImplementedError("(internal) Unhandled error: " + error))
- OSError: Failed to read data from device (using bulk transfer).: LIBUSB_ERROR_TIMEOUT
Manchmal ist beim nächsten Aufruf von
readBlocking()
wieder alles okay, manchmal dauert es ein paar Minuten und manchmal geht danach gar nichts mehr. Der Datenabruf erfolgt in einem separaten Thread, der nichts anderes tut, als startContinuousDataAcquisition()
und danach in einer Schleife readBlocking()
.Manchmal folgt dem Fehler noch eine Flut von Meldungen bzgl. Pufferüberlauf. Das ist allerdings zu erwarten, wenn das Abrufen der Daten länger nicht geklappt hat:
Source Code
- Traceback (most recent call last):
- File "/var/lib/revpipyload/bsp_ts/measure-cpu/pump_logic/adc_cebo.py", line 74, in acquire
- frames = device.readBlocking(self.BLOCK_SIZE)
- File "/usr/local/lib/python3.5/dist-packages/CeboMsrApiPython.py", line 1018, in readBlocking
- _ReadBlocking(self._handle, vvalues, values, frameCount)
- File "/usr/local/lib/python3.5/dist-packages/CeboMsrApiPython.py", line 95, in _checkError
- }.get(errorClass, NotImplementedError("(internal) Unhandled error: " + error))
- OSError: Buffer overflow.
Zur gleichen Zeit (aber nur einmalig) fand sich im Kernel-Log die folgende Meldung:
Insbesondere nachdem solch ein
LIBUSB_ERROR_TIMEOUT
-Fehler auftrat, allerdings auch mal ohne erkennbare Ursache, kann die Karte dann erst gar nicht geöffnet werden und behauptet eine falsche Firmware-Version zu haben. Stimmt natürlich nicht, es wurde nichts am Setup verändert währenddessen.Source Code
- Traceback (most recent call last):
- File "/home/pi/src/bsp/bsp_ts/measure-cpu/pump_logic/runner.py", line 35, in start
- self.adc.start()
- File "/home/pi/src/bsp/bsp_ts/measure-cpu/pump_logic/adc_cebo.py", line 44, in start
- self.init_device()
- File "/home/pi/src/bsp/bsp_ts/measure-cpu/pump_logic/adc_cebo.py", line 30, in init_device
- device.open()
- File "/home/pi/src/teststand-venv/lib/python3.5/site-packages/CeboMsrApiPython.py", line 832, in open
- _Open(_toString23(self._ident), byref(handleb))
- File "/home/pi/src/teststand-venv/lib/python3.5/site-packages/CeboMsrApiPython.py", line 95, in _checkError
- }.get(errorClass, NotImplementedError("(internal) Unhandled error: " + error))
- OSError: The firmware of this device is not supported.
Das alles klingt mir nach gelegentlichen Übertragungsproblemen am USB. Verkabelung ist jedoch sehr gewöhnlich: 0,5 m USB-Kabel gut geschirmt inkl. Ferrit, im Schaltschrank drumherum ist sonst nichts aktiv, was ggf. EMV-Störungen aussendet. Die Probleme treten bei mehreren Systemen an unterschiedlichen Standorten auf. Der Rechner ist wie gesagt eine industrielle Implementierung des Raspberry Pi Compute Module 3 (RevPi Connect) mit realtime-Kernel. Ich sehe keinen Grund, warum dieser auf dem USB Probleme bereiten sollte.
Wie kann ich so einen Fehler weiter diagnostizieren? Geben die Fehlermeldungen für die Cesys-Leute Aufschluss über eine mögliche Fehlerursache? Insbesondere bei der Meldung
The firmware of this device is not supported.
muss ja etwas im Treiber schief laufen.Über jegliche Hilfestellung wäre ich sehr dankbar. Wir haben bereits in drei CEBO LC investiert und müssten notfalls (und ungern) den Hersteller wechseln, wenn kein robuster Betrieb erreicht werden kann.
Vielen Dank im Voraus!
André