Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. How to detect if a QCanBusDevice has been physically disconnected?
Qt 6.12 LTS is out! See what's new in the release blog

How to detect if a QCanBusDevice has been physically disconnected?

Scheduled Pinned Locked Moved Unsolved General and Desktop
5 Posts 3 Posters 500 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • __mk___ Offline
    __mk___ Offline
    __mk__
    wrote last edited by
    #1

    I'm using QCanBusDevice to interface with a Peak Can-Usb adapter.

    How can I tell if the device has been removed, i.e. the usb adapter has been physically disconnected from my computer? I looked at all methods QCanBusDevice offers, but none of them tell me if the device is still physically connected.

    • QCanBusDevice::state() remains in the ConnectedState (this is probably the most counterintuitive)
    • QCanBusDevice::hasBusStatus() remains true
    • neither QCanBusDevice::error() nor QCanBusDevice::errorString() report an error
    • QCanBusDevice::errorOccured() is not emitted

    It seems like the QCanBusDevice doesnt notice at all that adapter is no longer there.
    The only thing that seems to change (and what I'm using right now) is the QCanBusDevice::deviceInfo(), which goes blank when you remove the adapter. Still, this seems rather hacky, so I'm wondering if I'm doing something unintended or if this feature is simply not implemented in QCanBusDevice (or PeakCanBackend to be specific)

    1 Reply Last reply
    0
    • aha_1980A Offline
      aha_1980A Offline
      aha_1980
      Lifetime Qt Champion
      wrote last edited by
      #2

      Hi @__mk__ ,

      there is indeed no dedicated API for that problem currently.

      What comes closest is QCanBusDevice::busStatus(), but that will currently (most likely) return CanBusStatus::Unknown as there is no special enum for that case.

      But I'll take your post as feature request and see if I can add something. I'm not completely sure if that fits into busStatus() or if a separated deviceStatus() would be better. I'm open for suggestions.

      Note: QCanBusDevice::hasBusStatus() just tells you if the device supports the function busStatus(), it is not the actual busStatus().

      Regards

      Qt has to stay free or it will die.

      1 Reply Last reply
      1
      • aha_1980A Offline
        aha_1980A Offline
        aha_1980
        Lifetime Qt Champion
        wrote last edited by
        #3

        I've added a task for that: https://qt-project.atlassian.net/browse/QTBUG-151640

        Qt has to stay free or it will die.

        __mk___ 1 Reply Last reply
        4
        • K Offline
          K Offline
          kavinreed
          Banned
          wrote last edited by
          #4
          This post is deleted!
          1 Reply Last reply
          0
          • aha_1980A aha_1980

            I've added a task for that: https://qt-project.atlassian.net/browse/QTBUG-151640

            __mk___ Offline
            __mk___ Offline
            __mk__
            wrote last edited by __mk__
            #5

            @aha_1980 Thanks for taking care of this!

            I think a method like deviceState() or deviceType() would be appropriate and offer more flexibility for the different CAN plugins. I wouldn't change QCanBusDevice::state() or busStatus(), they have a different meaning.

            I have noticed that the Peak USB devices actually fall back to a virtual CAN interface the moment you disconnect the usb device (the virtual interface is called "PCANLight_USB_16" in PCAN-View). This might explain why no errors are reported and the QCanBusDevice remains connected - the virtual interface is still working. This automatic fallback seems to be an intended feature of the peak driver.

            Ideally there'd be a DeviceType enum with values like Virtual and Physical to represent what kind of device it currently is. But this switching behaviour seems pretty specific to peak devices, so perhaps somebody has an idea for a more general approach.
            Ideally-ideally this change would also be emitted as a signal :)

            1 Reply Last reply
            0

            • Login

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • Users
            • Groups
            • Search
            • Get Qt
            • Unsolved