unregelmässige Abstürze bei der Kommunikation über USB

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Nabend,

ich nutze Zuhause einen Mehrfachsteckdose welche über USB steuerbar ist.

Dafür wurde auch hier ein entsprechendes Linux-Python-Modul geschrieben welches ich auf einem raspberry pi nutze:

https://sourceforge.net/p/sispmctl/git/ ... s/sispm.py

Das habe ich als Vorlage genommen und dann für mich umgearbeitet.

Code: Alles auswählen

# dev=sispm.Sispm()             # Get first available device.
# dev.set_switch(1,False)       # Switch second outlet off.
# print dev.status(2)           # Print status of third outlet.

import json
import usb, struct, sys

VENDOR_ID = 0x04B4
PRODUCT_ID_SISPM = 0xFD11
PRODUCT_ID_MSISPM_OLD = 0xFD10
PRODUCT_ID_MSISPM_FLASH = 0xFD12
PRODUCT_ID_MSISPM_FLASH_NEW = 0xFD13


class SispmException(Exception):
    pass


class Sispm:
    def __init__(self, switch_id, ip, logging_daemon, queue, num=0):
        self.switch_id = switch_id
        self.ip = ip
        self._logging_daemon = logging_daemon
        self._queue = queue

        cnt = 0
        busses = usb.busses()
        for bus in busses:
            for device in bus.devices:
                if device.idVendor == VENDOR_ID \
                        and device.idProduct in [PRODUCT_ID_SISPM,
                                                 PRODUCT_ID_MSISPM_OLD, PRODUCT_ID_MSISPM_FLASH,
                                                 PRODUCT_ID_MSISPM_FLASH_NEW]:

                    if num == cnt:
                        self.device = device
                        self.deviceHandle = self.device.open()
                        return

                    else:
                        cnt += 1

        self._logging_daemon.info('SIS USB ....... initialisiert')
        raise SispmException("Sispm device not found.")

    def _usb_command(self, b1, b2, dir_in=False):
        """ Send a usb command. """
        if dir_in:
            req = 0x01
            reqtype = 0x21 | 0x80;
            buf = 2

        else:
            req = 0x09
            reqtype = 0x21  # USB_DIR_OUT+USB_TYPE_CLASS+USB_RECIP_INTERFACE
            buf = struct.pack("BB", b1, b2)

        try:
            buf = self.deviceHandle.controlMsg(reqtype, req, buf, (0x03 << 8) | b1, 0, 500)
        except AttributeError:
            self._logging_daemon.info('SIS USB ....... Error - neuer Versuch ...')
            buf = self.deviceHandle.controlMsg(reqtype, req, buf, (0x03 << 8) | b1, 0, 500)
            self._logging_daemon.info('SIS USB ....... Error - neuer Versuch Erfolgreich')

        if dir_in:
            return buf[1] != 0

    def _check_outlet(self, num):
        if num < 0 or num >= self.get_num_outlets():
            raise SispmException("Outlet %d doesn't exist on this device." % num)

    def set_switch(self, switch_to, arg_a, arg_b, arg_c, arg_d):
        self._check_outlet(int(arg_a)-1)
        self._usb_command(3 * int(arg_a), {False: 0x00, True: 0x03}[switch_to])
        self._logging_daemon.debug(
            'SIS USB ....... geschaltet Relais %s , SOLL = %s , IST = %s' % (arg_a, switch_to, self.status(arg_a)))
        tmp_json = json.dumps({
            "usage": "switch_changed_status",
            "ip": self.ip,
            "id": self.switch_id,
            "value": switch_to
        })
        for consumer in self._queue:
            consumer(tmp_json)
            self._logging_daemon.info(
                'SIS USB ....... Relais %s , send %s -> SocketServer Warteschlange ' % (arg_a, self.status(arg_a)))

    def status(self, number):
        self._check_outlet(int(number)-1)
        return self._usb_command(3 * int(number), 0x03, True)

    def set_buzzer_enabled(self, onoff):
        self._usb_command(1, {False: 0x00, True: 0x03}[onoff])

    def get_num_outlets(self):
        if self.device.idProduct in \
                [PRODUCT_ID_MSISPM_OLD, PRODUCT_ID_MSISPM_FLASH]:
            return 1

        elif self.device.idProduct in \
                [PRODUCT_ID_SISPM, PRODUCT_ID_MSISPM_FLASH_NEW]:
            return 4

        else:
            return None
Jetzt kommt es in unregelmässigen Abständen zu Abstürzen wenn ich eine Steckdose schalte oder wenn ich den Status einer Steckdose abfrage.

Code: Alles auswählen

Traceback (most recent call last):
  File "sh-client.py", line 246, in <module>
    asyncio.get_event_loop().run_until_complete(client_handler())
  File "/usr/local/lib/python3.4/asyncio/base_events.py", line 316, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.4/asyncio/futures.py", line 275, in result
    raise self._exception
  File "/usr/local/lib/python3.4/asyncio/tasks.py", line 238, in _step
    result = next(coro)
  File "sh-client.py", line 90, in client_handler
    message_handler(message_received)
  File "sh-client.py", line 112, in message_handler
    switches_info[message_id, "argD"])
  File "/sourcecode/lib_sispm.py", line 69, in set_switch
    self._usb_command(3 * int(arg_a), {False: 0x00, True: 0x03}[switch_to])
  File "/sourcecode/lib_sispm.py", line 58, in _usb_command
    buf = self.deviceHandle.controlMsg(reqtype, req, buf, (0x03 << 8) | b1, 0, 500)
  File "/usr/local/lib/python3.4/site-packages/usb/legacy.py", line 205, in controlMsg
    timeout = timeout)
  File "/usr/local/lib/python3.4/site-packages/usb/core.py", line 962, in ctrl_transfer
    self._ctx.managed_claim_interface(self, interface_number)
  File "/usr/local/lib/python3.4/site-packages/usb/core.py", line 146, in managed_claim_interface
    self.backend.claim_interface(self.handle, i)
  File "/usr/local/lib/python3.4/site-packages/usb/backend/libusb1.py", line 747, in claim_interface
    _check(self.lib.libusb_claim_interface(dev_handle.handle, intf))
  File "/usr/local/lib/python3.4/site-packages/usb/backend/libusb1.py", line 552, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
  File "/usr/local/lib/python3.4/site-packages/usb/backend/libusb1.py", line 541, in _strerror
    return _lib.libusb_strerror(errcode).decode('utf8')
  File "/usr/local/lib/python3.4/ctypes/__init__.py", line 364, in __getattr__
    func = self.__getitem__(name)
  File "/usr/local/lib/python3.4/ctypes/__init__.py", line 369, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: /lib/arm-linux-gnueabihf/libusb-1.0.so.0: undefined symbol: libusb_strerror
Task was destroyed but it is pending!
task: <Task pending coro=<sending_loop() running at sh-client.py:57> wait_for=<Future pending cb=[Task._wakeup()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<run() running at /usr/local/lib/python3.4/site-packages/websockets/protocol.py:395> wait_for=<Future pending cb=[Task._wakeup()]>>
2016-04-27 01:15:00 : websockets .... consumers.remove
Exception ignored in: <generator object sending_loop at 0xb6021b20>
Traceback (most recent call last):
  File "sh-client.py", line 63, in sending_loop
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1274, in info
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1409, in _log
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1419, in handle
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1481, in callHandlers
  File "/usr/local/lib/python3.4/logging/__init__.py", line 853, in handle
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1040, in emit
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1030, in _open
NameError: name 'open' is not defined
Der Fehler ist immer der gleiche.
Es ist egal ob ich eine Steckdose an- oder ausschalte, ob ich sie abfrage und es ist auch egal welche Steckdose es ist.
Manchmal passiert es nach 2-3 x Schaltvorgängen, manchmal erst nach 10-12 x Schaltvorgängen.

Zum Teil hilft es das Programm einfach neuzustarten, manchmal muss ich aber auch den gesamten raspberry pi neu starten.

Ich habe natürlich schon mal im Internet gesucht und es scheint ein Problem im python-usb-modul zu sein.

Das ganze ist sehr ärgerlich, weil so ist die Steckdose einfach viel zu unzuverlässig.
Deshalb wollte ich mal fragen ob hier jemand eine Idee hat?

Ich habe schon versucht den Fehler abzufangen und den Befehl dann direkt nochmal neu abzusetzen.
Das hat leider nicht funktioniert und deshalb brauche ich jetzt Hilfe .... :(
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Code: Alles auswählen

AttributeError: /lib/arm-linux-gnueabihf/libusb-1.0.so.0: undefined symbol: libusb_strerror
Das sieht aus, als wären libusb und das Pythonmodul nicht kompatibel zueinander, da Python versucht eine Funktion aufzurufen, die die Bibliothek gar nicht vorhält. Hier solltest Du schauen, dass Du die richtigen Versionen installiert hast.
Die fehlende Funktion scheint für die Fehlerausgabe gedacht zu sein - heisst, wenn Du obiges repariert hast, wird es einen anderen Fehler geben, den es dann vermutlich auch noch zu beheben gilt.
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Zusätzlich zu jerch:
Der Fehler wird offenbar beim Aufruf von `self.deviceHandle.controlMsg()` geworfen. Schonmal versucht, das Timeout (letzter Parameter) weiter zu erhöhen? Zum Beispiel von jetzt 500 auf 1000?

Andernfalls könnte natürlich auch etwas an den anderen Parametern falsch sein – das sieht man ja mangels aussagekräftiger Fehlermeldung leider nicht. Und Du schreibst ja selbst, dass Du das Skript größtenteils aus einer anderen Quelle übernommen hast. Weißt Du, was die einzelnen Parameter und deren Werte bedeuten?
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

So, dann mal vielen Dank für die schnellen Antworten.

Vielleicht sollte ich noch erwähnen das ich nicht wirklich gut programmieren kann und mich schon gar nicht mit der direkten Kommunikation zwischen python <-> Hardware auskenne.
Das sieht aus, als wären libusb und das Pythonmodul nicht kompatibel zueinander, da Python versucht eine Funktion aufzurufen, die die Bibliothek gar nicht vorhält. Hier solltest Du schauen, dass Du die richtigen Versionen installiert hast.
Okay, welche richtige Version meinst du?
Die vom python-Modul? Da gibt es nur die eine Version.
Oder meinst du von libusb? Nur, wie komme ich da an eine neue Version.
Mein raspian ist auf dem aktuellsten Stand und ich weiß jetzt ehrlich nicht wo und wie ich eine neuere Version von libusb installieren kann.
Eventuell meinst du auch das python-usb Modul? AUch hier wüsste ich nicht wo ich eine neuere Version herbekommen kann.
Die fehlende Funktion scheint für die Fehlerausgabe gedacht zu sein - heisst, wenn Du obiges repariert hast, wird es einen anderen Fehler geben, den es dann vermutlich auch noch zu beheben gilt.
Das seltsame ist, das es manchmal funktioniert und manchmal nicht.
Wenn doch eine fehlende Funktion der Grund ist, warum taucht der Fehler dann nicht bei jedem Schaltvorgang auf?
Ich kann z.Bsp. Steckdose 3 heute ohne Probleme anschalten, versuche ich aber genau das gleiche morgen noch einmal, dann taucht unter Umständen der Fehler auf.
Wenn ich dann, wie in dem von mir geänderten Quellcode, per Ausnahme-Reglung bei einem Fehler einfach den gleichen Befehl nochmal sende, dann geht das manchmal und manchmal nicht.

Und um den urspünglichen Sourcecode oder gar das libusb-Modul zu reparieren fehlt mir schlicht das Können.
Der Fehler wird offenbar beim Aufruf von `self.deviceHandle.controlMsg()` geworfen. Schonmal versucht, das Timeout (letzter Parameter) weiter zu erhöhen? Zum Beispiel von jetzt 500 auf 1000?
Nein, das habe ich noch nicht versucht.
Wo, also in welchem Modul müsste ich das den ändern?
Weil in meinem Code (lib_sispm.py) finde ich keine Timeout-Angabe.
Muss also "tiefer" im System sein und daran spiele ich in der Regel nicht rum.

Aber wenn du sagst das das was bringen könnte, dann will ich es gerne versuchen.
Also in welcher Datei müsste ich den timeout ändern?
Andernfalls könnte natürlich auch etwas an den anderen Parametern falsch sein – das sieht man ja mangels aussagekräftiger Fehlermeldung leider nicht.
Ich habe doch die komplette Fehlermeldung kopiert, wie kann ich euch hier mehr Infos geben?
Und Du schreibst ja selbst, dass Du das Skript größtenteils aus einer anderen Quelle übernommen hast. Weißt Du, was die einzelnen Parameter und deren Werte bedeuten?
Leider nein.
Vom Hersteller gab es nie Linux-Unterstützung und ich denke irgendwann hat sich das einer selbst geschrieben.
Das nutze ich zwar, wirklich verstehen tue ich es aber nicht.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Das ist ein pyusb-Bug: https://github.com/walac/pyusb/issues/57
Mit einer neueren Version von pyusb sollte es behoben sein. Hier ist der entsprechende Commit dazu: https://github.com/walac/pyusb/commit/c ... a3614e198b
Anscheinend fehlt den debianbasierten libusb-Varianten diese Fehlerfunktion.

Warum der Fehler nur manchmal auftaucht, liegt vermutlich am Fehlertypen selbst. Ich tippe mal darauf, dass das Gerät dann blockiert oder nicht am System angemeldet ist. Mit Ausgabe der Fehlermeldung sollte man da weiterkommen.
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Mit einer neueren Version von pyusb sollte es behoben sein. Hier ist der entsprechende Commit dazu: https://github.com/walac/pyusb/commit/c ... a3614e198b
Reicht es den aus wenn ich die im Commit genannte Datei "usb/backend/libusb1.py" per Texteditor auf meinem raspberry pi entsprechend ändere?
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Ich habe mal die libusb1.py auf meinem raspi mit den Änderungen im commit verglichen und musste leider feststellen das in meiner Version die Änderungen bereits enthalten sind.
Dieser commit ist wohl nicht die Lösung ... :(

Deswegen habe ich jetzt mal die komplette Datei ausgetauscht.
Meine Version gelöscht und stattdessen die Version von github auf den raspi kopiert.

Zusätzlich habe ich jetzt mal den Timeout-Wert auf 1000 erhöht, mal schauen ob irgend etwas davon was bringt.
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Kopieren der Datei hat nicht funktioniert, danach lief es gar nicht mehr.

Also habe ich per "pip uninstall pyusb" das USB-Modul erstmal komplett deinstalliert.
Danach habe ich mir von github die aktuelle Version gezogen und diese "manuell" installiert.

Jetzt mal testen wie es läuft ...
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

So, da war ich mir schon fast sicher das es mit der neuen Version Fehlerfrei klappt, dann kam nach ca. 20 Stunden und 12 x Schaltvorgängen der folgende, neue, Fehler:

Code: Alles auswählen

Traceback (most recent call last):
  File "sh-client.py", line 246, in <module>
    asyncio.get_event_loop().run_until_complete(client_handler())
  File "/usr/local/lib/python3.4/asyncio/base_events.py", line 316, in run_until_complete
    return future.result()
  File "/usr/local/lib/python3.4/asyncio/futures.py", line 275, in result
    raise self._exception
  File "/usr/local/lib/python3.4/asyncio/tasks.py", line 238, in _step
    result = next(coro)
  File "sh-client.py", line 90, in client_handler
    message_handler(message_received)
  File "sh-client.py", line 112, in message_handler
    switches_info[message_id, "argD"])
  File "/sourcecode/lib_sispm.py", line 86, in set_switch
    'SIS USB ....... Relais %s , send %s -> SocketServer Warteschlange ' % (arg_a, self.status(arg_a)))
  File "/sourcecode/lib_sispm.py", line 90, in status
    return self._usb_command(3 * int(number), 0x03, True)
  File "/sourcecode/lib_sispm.py", line 59, in _usb_command
    buf = self.deviceHandle.controlMsg(reqtype, req, buf, (0x03 << 8) | b1, 0, 1000)
  File "/usr/local/lib/python3.4/site-packages/usb/legacy.py", line 211, in controlMsg
    timeout = timeout)
  File "/usr/local/lib/python3.4/site-packages/usb/core.py", line 1043, in ctrl_transfer
    self.__get_timeout(timeout))
  File "/usr/local/lib/python3.4/site-packages/usb/backend/libusb1.py", line 883, in ctrl_transfer
    timeout))
  File "/usr/local/lib/python3.4/site-packages/usb/backend/libusb1.py", line 595, in _check
    raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 32] Pipe error
Task was destroyed but it is pending!
task: <Task pending coro=<sending_loop() running at sh-client.py:57> wait_for=<Future finished result='{"ip": "192....se, "id": 18}'>>
Task was destroyed but it is pending!
task: <Task pending coro=<run() running at /usr/local/lib/python3.4/site-packages/websockets/protocol.py:411> wait_for=<Future pending cb=[Task._wakeup()]>>
2016-04-28 20:00:00 : websockets .... consumers.remove
Exception ignored in: <generator object sending_loop at 0xb5f95d78>
Traceback (most recent call last):
  File "sh-client.py", line 63, in sending_loop
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1274, in info
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1409, in _log
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1419, in handle
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1481, in callHandlers
  File "/usr/local/lib/python3.4/logging/__init__.py", line 853, in handle
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1040, in emit
  File "/usr/local/lib/python3.4/logging/__init__.py", line 1030, in _open
NameError: name 'open' is not defined
Ist auf jeden Fall ein neuer Fehler, nur kann ich damit nicht viel anfangen.

Außerdem bin ich langsam am verzweifeln ...
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

der_Mausbiber hat geschrieben:Danach habe ich mir von github die aktuelle Version gezogen und diese "manuell" installiert.
`pip` kann auch direkt aus einem Git-Repo heraus installieren. Der Befehl wäre in deinem Fall:

Code: Alles auswählen

pip install git+git://github.com/walac/pyusb.git
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

der_Mausbiber hat geschrieben:Ist auf jeden Fall ein neuer Fehler, nur kann ich damit nicht viel anfangen.
Der wichtigste Teil an diesem ellenlagen Traceback ist wohl dieser hier:

Code: Alles auswählen

usb.core.USBError: [Errno 32] Pipe error
Da müsstest du halt mal recherchieren, warum dieser Fehler bei dir auftritt.
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@der_Mausbiber:
Probier mal mit dieser Bibliothek, ob der Fehler weiterhin besteht. Das Skript macht ein autodispose auf das Device, vllt. hilft das.
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Probier mal mit dieser Bibliothek, ob der Fehler weiterhin besteht. Das Skript macht ein autodispose auf das Device, vllt. hilft das.
Okay, dafür werde ich die Bibliothek die Tage erstmal anpassen und es dann testen.
Da müsstest du halt mal recherchieren, warum dieser Fehler bei dir auftritt.
Ich verstehe da immer so wenig von, werde es aber nochmal selbst versuchen.
Ich hatte gehofft es würde jemand spontan den Fehler erkennen und sagen "Da musst du das und das machen und dann klappts" ... :wink:
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@der_Mausbiber:

Laut libusb Doku geht der Fehler auf den Transferstatus LIBUSB_TRANSFER_STALL zurück, was für einen Control-Endpunkt heisst, dass das USB-Gerät das gesendete Kommando nicht versteht. Mögliche Ursachen, die mir dafür einfallen:
  • Das Kommando ist fehlerhaft. Da hilft es, mit einem Debugger mal zu schauen, ob die Werte während der Ausführung überhaupt ein fürs Gerät verständliches Kommando ergeben.
  • Das Gerät ist anderweitig blockiert. Hier könnte autodispose helfen. Greift denn eine andere Anwendung parallel darauf zu? Oder deine Anwendung mehrfach?
  • Evtl. stimmt die Endpunkt-Konfiguration nicht. Das kann passieren, wenn das Gerät zwischenzeitlich neu initialisiert wurde und Du quasi mit falschen Einstellungen darauf zugreifst. Auch hier hilft autodispose, sofern Deine Anwendung die Neuinitialisierung vorgenommen hat. Falls eine andere Anwendung das Device hält, wirds schwieriger.
  • Der USB-Treiber ist fehlerhaft. Erste Anlaufstelle ist `dmesg`, evtl. gibt es eine entsprechende Kernelausgabe.
  • Das Gerät resp. der USB-Controller ist kaputt und macht schlichtweg Unsinn. Vllt. mal das Gerät an einem anderen Rechner testen bzw. prüfen, ob andere Geräte an dem USB-Port auch Probleme machen.
Vllt. hilft Dir das bei der Fehlersuche weiter.
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Vielen Dank für eure Hilfe.

Ich werde die verschiedenen Informationen die Tage durchtesten.

Sicher ist, das die Qualität der Steckdosenleiste eher untere Schublade ist, das gleiche düfte für die verbaute Elektronik gelten.
Eben ein typisches China-Produkt, sehr günstig aber naja ;)

Anderweitig blockiert ist die Steckdose aber nicht.
Diese wird ausschließlich von meinem SKript angesteuert.

Was passieren kann, ist das ich zwei Steckdosen quasi "Zeitgleich" schalte.
Geht aber in den meisten Fällen auch.

Ich werde es zuerst mal mit der neuen sispm-Bibliothek versuchen und dann mal weitersehen ...
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@der_Mausbiber:
Ich habe das schwarze Modell mit 4+1 Steckdosen seit 2 Jahren in Betrieb. Probleme hatte ich noch nie damit. U.a. hängen Drucker und ein Backupspiegelsystem dran, angesteuert über ein Wandboard. Stromkostenersparnis des On-Demand-Systems ggü. dem alten 24h-System etwa 200€ pro Jahr ;)

Wenn Deine Anwendung parallele Zugriffe erlaubt - kann es sein, dass Du das Gerät dabei jedesmal neu initialisierst? Falls ja, liegt höchstwahrscheinlich hier der Hund begraben.
der_Mausbiber
User
Beiträge: 72
Registriert: Donnerstag 2. Oktober 2014, 09:51

Wenn Deine Anwendung parallele Zugriffe erlaubt - kann es sein, dass Du das Gerät dabei jedesmal neu initialisierst? Falls ja, liegt höchstwahrscheinlich hier der Hund begraben.
Naja, parallele Zugriffe sind es ja nicht wirklich.
Ich kann in der Zeitschaltuhr ja z.Bsp. um 9.00 Uhr Steckdose 1 und Steckdose 2 anschalten lassen.
Dann werden die Befehle aber trotzdem hintereinander ausgeführt, also nicht wirklich parallel.

Und nein, neu initialisiert wird es nur beim Programmstart.
Danach rufe ich nur noch die Funktionen zum schalten und auslesen auf.
Antworten