Topics created by achrn

@SPAX thanks for your report.

TBH although it appears that there is a bug in this area, we might not fix it for the following reasons:

Input shaping has been completely reimplemented 3.6 than in 3.5 and works much better. We have no reports of a similar bug in 3.6. It's likely that tracking this bug down would require substantial effort, which ultimately would be wasted because the 3.6 code is completely different. Delta printers typically have little or no need for input shaping because their resonant frequencies tend to be higher.

Of course, if anyone else tracks this down and supplies a fix that we can validate, we will gladly include it in a future 3.5.x release.

If you are brave enough then I suggest you try RRF 3.6.0-alpha.5 on your machine. Or you can wait for 3.6.0-beta.1 which I estimate is 2 weeks away.

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

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.

This (above) does work with dsf-python 3.5.1rc1 (as announced in https://forum.duet3d.com/post/338777).

However, I've got a slightly refined set of installation instructions for the pre-requisites:

To install dsf-python it's not necessary to download the source etc. you can just sudo pip3 install --break-system-packages --pre dsf-python (and this is better). It will moan about how you should be using a virtual environment instead, but should work. I haven't done any testing with virtual environments. (pip is deprecated, but setup.py is even more deprecated.)

For hx711py it's not set up to use pip, but if you use sudo python3 setup.py install --record files.txt it will at least write the files it installs into files.txt, which will help if you want to uninstall it in future.

Otherwise, same instructions as above.

@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

I've tried converting the custom_http_endpoint.py example into a plugin and that goes 'partially started' too.

I've disabled apparmor in /opt/dsf/conf/plugins.json, just so it can't interfere - my goal would be to put it back on when I've figured out what's going on.

I've set up a 'test_plugin' that comprises only the custom_http_endpoint.py in folder dsf, and a plugin.json:

{ "id": "TestPlugin", "name": "Test Plugin", "author": "achrn", "version": "1.0.1", "license": "MIT", "dwcVersion": "3", "sbcDsfVersion": "3", "sbcRequired": true, "sbcExecutable": "custom_http_endpoint.py", "sbcExecutableArguments": null, "sbcOutputRedirected": false, "sbcPermissions": ["fileSystemAccess","launchProcesses","registerHttpEndpoints"] }

If I install that plugin it seems to go in OK, in that it appears as an external plugin in the web page, but if I start it, it goes to status 'partially started', and if I then try to access the endpoint (using wget) I get a zero length response. If I try and access the endpoint when the plugin is stopped (ie not even partially started) I get a 500 internal server error.

/run/dsf/custom/getIt-GET.sock does exist, dsf:dsf and permissions srwxrwxr-x

So I'm still flummoxed.

@achrn apologies for not reporting back here - I fixed the issue a week or so ago.

@blt3dp said in Smart Effector with Toolboard - no programming?:

@achrn

I’d love an effector that supported can without having to lash on a tool board, doesn’t seem that it’s gonna happen though.

Me too, but I decided to bite the bullet and do my own smart effector - toolboard combination. I am intending a 'My Duet controlled machine' post soon (but I have to take youngest daughter back to university this weekend). If the weather's as bad as it's forecast to be on Monday maybe then...

In summary, I've got a laser-cut aluminium plate to push the rods out to 80mm spacing and that gives me space to put on an Orbiter 2 extruder and a toolboard. I did do a bit of smart effector surgery (removed some connectors and soldered wires direct), but that might not be necessary with some slight changes. I lose about 15mm of Z, but nothing in X & Y. I've improved my cooling. Very happy with it so far.

My big secret is to tin the wires first. After stripping the wires, apply some flux so the solder will stick easily and tin the wires. I like flux pens like these: https://www.amazon.com/Soldering-Electronics-Tabbing-Welding-Maintenance/dp/B0953NGKXR. TInning without flux is a big pain. And the pens are great for working on PC boards if you do that.

Once both side have been tinned, the two sides will stick quickly. And use heat shrink tubing.

Not quite related, but if you expect the wires to be flexed at all during use, I highly recommend silicone insulated wires. The insulation is flexible and usually the strands of the wire are very fine so the whole thing will be flexible. https://www.amazon.com/BNTECHGO-Silicone-Flexible-Stranded-Tinned/dp/B09X45RZCQ It's not super cheap, but after debugging two cases of thermistor wires broken inside a cable chain I decided to take the plunge and I'll never use the cheapo stranded stuff again.

Lastly, a good soldering iron is a good investment. I have one like this that I like: https://www.amazon.com/dp/B07Z3KCVCL

PS - and get a little tub of tip-tinner to refresh the tip of your soldering iron when it becomes hard to melt the solder on it. https://www.amazon.com/Thermaltronics-FBA_TMT-TC-2-Lead-Tinner-Container/dp/B00NS4J6BY

@chrishamm Thanks - I've just spotted that back in the announcement thread. No problem.