Topics created by achrn

@chrishamm Thanks! That was it.

Changed the imports and the send.response() and now it works.

With hindsight I then find this change (and some others) had been made at https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/custom_http_endpoint.py in early December last year, but I had missed that.

@achrn It should be available via the package feeds as well now.

Just to say (for the record): resolved by Duet3D, I'm very happy with the solution, thanks.
Now both my printers have functional magnetic filament sensors.

@achrn thanks for pointing this out. I have corrected it.

@achrn I can confirm that I have also ZVDDD configured on a 3.5.4 delta, and also have some clunks issues.

Will update this afternoon to 3.6 RC and test

@achrn sorry I thought you were referring to my quote.

Updated for 3.6 (tested on 3.6.0rc1): PyDaemon.zip.txt (as usual you will need to take the .txt off the end of this file - I'm circumventing the forum restrictions).

The only change is to renumber it to a 3.6 version and set the requisites to 3.6.

Installation

The 3.6.0RC1 package repository does not have 3.6.0 DSF (at time of writing), and the 3.5.1 DSF one does not work with 3.6.0, so you need to add DSF manually. The 3.6.0 RC1 version is on pypi: https://pypi.org/project/dsf-python/3.6.0rc1/ so sudo pip3 install --break-system-packages dsf-python==3.6.0rc1 should install it.

python3-dsf-python (3.6.0~rc1-1) is in the repository now so can just sudo apt install python3-dsf-python (or apt upgrade) it.

Otherwise it's install in the usual manner for plugins - drop the zip onto the 'Install Plugin' button in Plugins in DWC and click the Start button (after checking the code is not going to do you harm). Refer to the first post in this thread for discussion of what goes in your daemon.py file.

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 said in pip won't install dsf-python-3.5.1rc1:

I'm not sure how to install as dsf, given that the account is nologin. There is no password for dsf. sudo su dsf gives me This account is currently not available. Should I just set dsf to allow login and then login as that user and do the pip3 command? I'm a little nervous that doing that might upset something else that uses the dsf use

@Falcounet it would be good if we could document this given how the new version is being a pain.

@achrn have you considered releasing this as a plugin via plugins.duet3d.com

@o_lampe my test was at Z10, as was that done by @achrn. It's not the shape at the top we are concerned with here, it’s that it goes beyond M665 B parameter. The cone at the top is limited by the endstop switches, so I’m pretty sure the firmware takes account of that, though I didn’t test that. It’s why you always have to move down in Z after homing, before moving in X and Y. okay, rereading @achrn’s post, it’s trying to go outside the cone at the top too. I’ll update the issue on GitHub.

Ian

@achrn Your first approach is fine. Instead of a simple code you can send a regular DSF G-code as well. SetObjectModel is reserved for the DuetPiManagementPlugin and for non-SPI mode (which I haven't tested in a while), so don't use that.

@achrn I ended up doing the output, and clicking all the links, and found a few more that weren't linking correctly: M3, M5, M17, M18, M292, M404, M558.2, M569.4, M586.4 and M606. All fixed now. Thanks for the reminder!

Ian

@chrishamm said in 3.5.1 forgets whether filament is loaded with M999:

Edit: I've got a bug fix ready. I suggest you change something that modifies the move key at the end of your config.g (as I did with M906 E...) to work-around this problem for now.

Excellent thanks. I changed the 'real' M906 E1000 near the top of the config to a lower value (actually 500) and put my desired M906 E1000 as the last statement in config.g and it now doesn't forget about the filament, either for a M999 or for a full power down and power up again.

@achrn Thanks, I've updated that. Looks like it's been a loooong time since that section was looked at; at a quick glance there's other fields, and other uses of fields, that aren't listed there.

Ian