Fail on re-attach

[berkinet]

I have an issue, possibly related to my previous post with an error when a phidget tries to re-attach after a detach. In the onAttach handler first I set dataInterval and then changeTrigger and it is on the setDataInterval() call where the error occurs. Both settings work fine when the program is initialized. But, fail in the case of a detach event followed by a re-attach event:

Code: Select all

Detach Event:

	-> Channel Class: PhidgetVoltageRatioInput
	-> Serial Number: 528388
	-> Hub Port: 0
	-> Channel:  0

Attach Event:
	-> Channel Class: PhidgetVoltageRatioInput
	-> Serial Number: 528388
	-> Hub Port: 0
	-> Channel:  0
	-> Setting Data Interval to 2000

Error in Attach Event:
Desc: Timed Out
Traceback (most recent call last):
  File "mailscale.py", line 33, in onAttachHandler
    ph.setDataInterval(ph.dataInterval)
  File "/Library/Python/2.7/site-packages/Phidget22/Devices/VoltageRatioInput.py", line 175, in setDataInterval
    raise PhidgetException(result)
PhidgetException

The server displays

Code: Select all

ERR [phidget22net][2019-03-06T20:32:37 servers.c+599 checkKeepAlive()]: phid22device://192.168.5.138:53777: keepalive [4000000 usec] timeout [731251800570 usec < 731251800943 usec]
ERR [phidget22net][2019-03-06T20:32:37 servers.c+752 runClientConnection()]: 'CasaMilagro-Portail-444' failed for client phid22device://192.168.5.138:53777
	server.c+615 handleDeviceClient() : (Timed Out) failed to handle client request

Ideas? (BTW, These are connected to an SBC3 running Phidget22 - Version 1.0.0 - Built Jan 29 2019 11:16:26, and I have tried restarting.)

[berkinet]

FWIW... here is the onAttach handler code

Code: Select all

def onAttachHandler(self):
    ph = self
    try:
        if __debug__: 
            print("Attach Event:")

        # Get device information and display it.
        channelClassName = ph.getChannelClassName()
        serialNumber = ph.getDeviceSerialNumber()
        channel = ph.getChannel()
        hubPort = ph.getHubPort()
        if __debug__:
            print("\t-> Channel Class: " + channelClassName + "\n\t-> Serial Number: " + str(serialNumber) +
              "\n\t-> Hub Port: " + str(hubPort) + "\n\t-> Channel:  " + str(channel))
               
        if __debug__: print("\t-> Setting Data Interval to %s" % ph.dataInterval)
        ph.setDataInterval(ph.dataInterval)
        if __debug__: print("\t-> Setting Voltage Ratio ChangeTrigger to %.7f" % ph.changeTrigger)
        ph.setVoltageRatioChangeTrigger(ph.changeTrigger)
        
    except PhidgetException as e:
        print("\nError in Attach Event:")
        DisplayError(e)
        traceback.print_exc()
        return
    except RuntimeError as e:
        sys.stderr.write("Runtime Error: \n\t" + e)
        traceback.print_exc()
        return

[berkinet]

I have additional information. I upgraded to the latest Phidget22 code on Hub and client and I added logging to the client and captured this at the time of the errors above. With the new code the error has changed slightly and now appears as:

Code: Select all

	-> Setting Voltage Ratio ChangeTrigger to 0.0000002
Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 314, in 'calling callback function'
  File "/Library/Python/2.7/site-packages/Phidget22/Devices/VoltageRatioInput.py", line 73, in _localVoltageRatioChangeEvent
    self._VoltageRatioChange(self, voltageRatio)
  File "mailscale.py", line 95, in onVoltageRatioChangeHandler
    input = self.linkedOutput.getVoltageRatio()
  File "/Library/Python/2.7/site-packages/Phidget22/Devices/VoltageRatioInput.py", line 307, in getVoltageRatio
    raise PhidgetException(result)
Phidget22.PhidgetException.PhidgetException

When that error is thrown, the client log shows:

Code: Select all

WARN [phidget22net][2019-03-10T03:31:26]:18 packets lost: 4943 vs 4925
ERR [phidget22net][2019-03-10T03:31:27]:netconn://192.168.5.33:5661: keepalive [8000000 usec] timeout [490312547904 usec < 490312547905 usec]
ERR [phidget22net][2019-03-10T03:31:27]:clientHandleMessage() for 192.168.5.33:5661 failed:MOSN_KEEPALIVE
	
INFO [phidget22net][2019-03-10T03:31:27]:'192.168.5.33:5661': client thread closing: not by request
INFO [phidget22netctl][2019-03-10T03:31:27]:network control entry Mail-Server not connected (failures=0)
INFO [phidget22net][2019-03-10T03:31:27]:Starting client connection to '192.168.5.33:5661'
INFO [phidget22net][2019-03-10T03:31:27]:server handshake 'phid22device' 2.1
INFO [phidget22net][2019-03-10T03:31:27]:connected to server 'CasaMilagro-Portail'
INFO [phidget22netctl][2019-03-10T03:31:27]:network control entry Mail-Server connected to 192.168.5.33:5661
INFO [phidget22net][2019-03-10T03:31:27]:server netconn://192.168.5.33:5661 starting DATAGRAM as requested

and the server (SBC3) log shows:

Code: Select all

ERR [phidget22net][2019-03-10T03:31:27 servers.c+599 checkKeepAlive()]: phid22device://192.168.5.138:51603: keepalive [4000000 usec] timeout [282555873954 usec < 282555874275 usec]
ERR [phidget22net][2019-03-10T03:31:27 servers.c+599 checkKeepAlive()]: phid22device://192.168.5.138:53973: keepalive [4000000 usec] timeout [282555874771 usec < 282555875901 usec]
ERR [phidget22net][2019-03-10T03:31:27 servers.c+752 runClientConnection()]: 'CasaMilagro-Portail-102' failed for client phid22device://192.168.5.138:51603
	server.c+615 handleDeviceClient() : (Timed Out) failed to handle client request
ERR [phidget22net][2019-03-10T03:31:27 servers.c+752 runClientConnection()]: 'CasaMilagro-Portail-104' failed for client phid22device://192.168.5.138:53973
	server.c+615 handleDeviceClient() : (Keep Alive) failed to handle client request
[0xb5e054d0]subiop complete 0xb5e05920
server.c+586 handleDeviceClient() : (Keep Alive) handleNetworkRequest() failed
servers.c+688 handleNetworkRequest() : (Keep Alive) failed to read request
network.c+585 readRequestHeader() : (Keep Alive) failed to read request header

Note I am also having another odd issue in which the Hub continually detaches and re-attaches at night! This issue seems to coincide with sunset and sunrise. I have posted it to the SBC3 hardware forum. I do not think these two issues are related. However, the constant detach/attach cycling is aggravating the problem noted in this thread. Also note, these errors only happen on maybe 1 out of 3 or 4 detach/attach cycles

[berkinet]

This problem is still occurring.

BUMP!