DSF-API pydsfapi and CPU utilization on RPi during print
-
I'm running all the latest stable releases:
RRF 3.2.2, DSF 3.2.2, DSF-APIs/pydsfapi 3.1.3
on a Raspberry Pi 3B+.I'm running a simply Python app to intercept
M7000
and take a webcam photo during a layer change - so only once every few minutes:intercept_connection = pydsfapi.InterceptConnection(InterceptionMode.PRE) intercept_connection.connect() while True: cde = intercept_connection.receive_code() if cde.type == code.CodeType.MCode and cde.majorNumber == 7000: success = intercept_connection.flush(cde.channel) if not success: log_print("Flush failed") intercept_connection.cancel_code() continue take_camera_snapshot() intercept_connection.resolve_code() else: intercept_connection.ignore_code()
While printing, I observe that this python process is essentially pegging a whole CPU core: almost or even slightly more than 100% in htop.
The
/opt/dsf/bin/DuetControlServer
process is hovering around 10-15% of CPU (when looking at htop)My total system memory with an print job:
$ free -h total used free shared buff/cache available Mem: 924Mi 172Mi 548Mi 6.0Mi 203Mi 693Mi Swap: 0B 0B 0B
Is this a bottleneck that could affect print performance?
How does DSF/DCS behave if one of the IPC clients cannot keep up, @chrishamm?Am I using it wrong, @wilriker?
Would the Go-based API be more performant and should be preferred over Python?
-
Of course as luck will have it, I cannot reproduce it anymore.
So take my report from above as tainted - might have been a race condition or something else. ¯_(ツ)_/¯ -
@resam Whatever it was, you can also avoid high load when using
pydsfapi
3.2.0 or later by making use of thefilters
parameter when instantiatingIntercept_connection
. It takes a list of strings specifying those codes you are interested in. DSF will then only forward these codes to your client.I have modified your new code example to show how to use it.