jdecoux wrote:You can call:

Code: Select all

Phidget.resetLibrary()

Is there a Phidget 22 equivalent?

Phidget Library 1.0.0.20190228 resolves this issue - CPU is now at 5% for 3 x 1012s - Thanks Patrick.
This also fixes kernel error "Internal error: Oops: 5 [#1] SMP ARM" that occurred on high load.

Have reinstalled Raspbian Stretch Lite and the Phidget libraries from scratch, and am still seeing this issue.
Have tried with two separate Pi2 Model B's.
Anyone else running a Raspberry?

Thanks for the suggestion. Here is working code (without error-handling): klass = ch_readonly.getChannelClassName() python_klass_name = klass.split('Phidget')[1] ch_new = getattr(importlib.import_module('Phidget22.Devices.' + python_klass_name), python_klass_name)() # Set handlers, and remember to c...

I am seeing high CPU utilization of 34% in steady state. Hardware: Raspberry Pi 3 Phidgets: 3 x 1012 Phidget library: 22-1.0.0.2019012 Rasbian firwmare: Linux 4.14.97-v7+ #1197 Test Code: attached (renamed to txt extension to allow upload). While CPU goes down to 20% if not storing the attached chan...

Per the API docs, channels returned by Manager OnAttach handlers are read-only objects, and the developer should create new instances of the correct type. My question is, is there a way to dynamically create the correct type? Cannot use ch.__class__ as it is always an instance of class Phidget. Is i...

Root cause was not calling channel.close() during process termination. This caused intermittent exceptions the next time the process was started. Can this be better handled by the Phidget Python library itself, by registering to atexit ? See https://stackoverflow.com/questions/3850261/doing-somethin...

With an 1012 i/o board, in the channel attach event, calling the channel getState sometime returns exception 51 EPHIDGET_UNKNOWNVAL. It is not consistent - sometimes it happens, sometimes not. Stack trace: File "/home/pi/Envs/djhome/lib/python3.6/site-packages/Phidget22/Devices/DigitalInput.py&...

Thanks so much!

getChannelClass succeeds even if channel is detached.
But getChannelClassName fails if channel is detached.
Is this by design?

(yes, I can use just ChannelClass, but the code and logs are more readable using ChannelClassName)