Hello !
I'm pleased to announce the release of my first plugin for DSF.
ExecOnMcode is a SBC plugin for DuetSoftwareFramework and based on dsf-python to run commands on user-defined M-Codes.
This plugin is based on the original idea from wilriker's execonmcode.
Feel free to give some feedback, post the issues you may face and ask for improvements to this thread.
The Python bindings for DSF dsf-python v3.4.5 has been released.
This release brings the bindings up-to-date with the current 3.4.5 version of DSF.
A proper Python implementation of the ObjectModel has been added as well.
As there are some changes made on the modules architecture to better match the DSF API one, existing scripts or plugins may need to change their module imports to use that version.
@Lem I just releaseed a new version of dsf-python which raises an dsf.connections.exceptions.IPCSocketBrokenException exception when the IPC socket is closed.
Please try and report back if you run in other problems.
The Python bindings for DSF dsf-python v3.5.1rc1 has been released.
Please note this is a pre-release version so you may need to add --pre argument to pip to install or upgrade to this version.
Another option is to specify the version number :
To install : sudo pip3 install --pre dsf-python
To upgrade : sudo pip3 install --upgrade --pre dsf-python
More information about this release on the GitHub repository.
Please report any problem you may run into on that section of the forum while tagging me.
@tinchus I made a script for the STM port of RRF which is available here : https://github.com/TeamGloomy/rrf_stm32_sbc/blob/master/armbian/userpatches/overlay/rrf_upgrade.sh
Instructions to use are described here : https://teamgloomy.github.io/armbian_upgrade.html#upgrading-dsf
If you want to downgrade to 3.4.1, run it as rrf_upgrade 3.4.1
So basically :
wget "https://github.com/TeamGloomy/rrf_stm32_sbc/blob/master/armbian/userpatches/overlay/rrf_upgrade.sh"
chmod a+x rrf_upgrade.sh
./rrf_upgrade 3.4.1
@aleohl I released a new version which fixes that issues so dsf-python still works with Python 3.7
Please let me know if you run it others problems.
Looking at this I found out some issues with the OM in dsf-python that need to be fixed.
I should be able to fix it in the following days and may reply back here with a more detailed example.
@DDD Actually, you can use pConn.perform_simple_code("set global.var_name=value")
I wrote this guide using a OrangePi4B as example : https://teamgloomy.github.io/dsf_on_armbian.html
The OrangePi4B use the same SoC as the Rockpi 4B : RK3399 so I believe you can just use the same configuration.
@chrishamm @oozeBot Yes but I'm abroad for now so I couldn't look at this before the end of the week
@davidjryan By looking at the traceback, it seems you have an older version of dsf-python installed for the pi user (in /home/pi/.local/lib/python3.11/site-packages/dsf/) so python uses this one instead of the system-wide one installed in /usr/local/lib/python3.11/dist-packages.
Try running pip3 uninstall dsf-python without sudo to remove it.
Also, please note that an APT package has been released to install dsf-python on Debian Bookworm.
This can be installed using sudo apt install python3-dsf-python
However, there is no change since the 3.5.1rc1 version that you have currently installed using pip3 --break-system-packages so you should be fine.
ExecOnMcode v0.6 has been released.
This version now supports DWC 3.5
@Ant1 @chrishamm @stuartofmt I think the issue here is that the version of dsf-python is flagged as beta (rc) and pip3 install dsf-python>=version installs the last stable version.
To make it to work, you either need to use equal : pip3 install dsf-python==version or to add the --pre argument : pip3 install --pre dsf-python>=version although, I'm not sure this is recommended as it may install unwanted beta versions.
@Lem said in Object model subscription - sometimes fails:
The problem with get_object_model() has been resolved, but I'm still stuck with connect(). Can you add an exception in this function as well?
Given the traceback above, the socket is waiting to receive data so I guess a timeout is what is needed. Although the socket is currently in blocking mode so setting a timeout won't work.
Are you able to reproduce this problem ?
If so, please post a snippet I can use to try a fix.
I do confirm the permission on the socket file being incorrect as there is no write permission for the group :
$ ls -al /run/dsf/custom/getIt-GET.sock
srwxr-xr-x+ 1 loic dsf 0 May 12 13:46 /run/dsf/custom/getIt-GET.sock
I think this is related to the Bookworm image.
However, granting the write permission for dsf group makes the request to return HTTP 200 code and I confirm I doesn't get the "so happy you asked for it!" response neither.
This response is being sent to DSF as we can see it in the dsf-python debug lines : send: {"StatusCode": 200, "Response": "so happy you asked for it!", "ResponseType": "StatusCode"}
It is probably one for @chrishamm to look at.
@achrn Is your user running the script in the dsf group ?
@achrn said in pip won't install dsf-python-3.5.1rc1:
@Falcounet I'm entirely happy to have dsf-python system-wide, but I think pip is saying it won't install dsf-python and saying I should use apt, but I don't think there's an apt package for dsf-python -
apt-cache search dsf-pythondoesn't find any likely contenders.
Yes because we don't maintain a deb package for dsf-python to be installed with APT. pip does it just fine.
You are right about pip refusing to installing it system-wide though, it needs an override to work.
But as said earlier, you can still install it using pip for any user (so without sudo) or in a virtual environnement.
If I put dsf-python into a virtual environment I don't think that the DSF running on the system will find it or use it - it's not in that virtual environment. Will the DSF plugins system find and use a dsf-python in a virtual environment?
Yes it will work. The virtual environnement is for python only. It will still connect to DSF using the IPC API.
For dsf plugins to work, you need to have dsf-python installed for dsf user.
Having done some digging, it seems pip has been deliberately disabled:
https://www.raspberrypi.com/documentation/computers/os.html#about-python-virtual-environments says "In previous versions of the operating system, it was possible to install libraries directly, system-wide, using the package installer for Python, commonly known as pip. ... In newer versions of Raspberry Pi OS, and other operating systems, this is disallowed. ... from Bookworm onwards, packages installed via pip must be installed into a Python virtual environment using venv. A virtual environment is a container where you can safely install third-party modules so they won’t interfere with, or break, your system Python." which suggests that install instructions using pip aren't going to work on newest DuetPi (which is Bookworm) or any future version.
So having been through a time where setup.py was deprecated and pip was advocated, pip is apparently now not usable, forcing users back to setup.py (unless you're happy to have your python running only is an isolated sandbox). I think. (I despised python even before this...) That or dsf-python is going to need an apt package in the Duet3D repository.
pip is disabled to install system-wide packages. I don't think it is disabled for a normal user.
@achrn I believe it's ok to install dsf-python system-wide.
If you don't want to, another option might be to install it for the user which will run your scripts or in a virtual environment.
The Python bindings for DSF dsf-python v3.5.1rc1 has been released.
Please note this is a pre-release version so you may need to add --pre argument to pip to install or upgrade to this version.
Another option is to specify the version number :
To install : sudo pip3 install --pre dsf-python
To upgrade : sudo pip3 install --upgrade --pre dsf-python
More information about this release on the GitHub repository.
Please report any problem you may run into on that section of the forum while tagging me.