Topics created by resam

Thanks all for questioning my setup! I now managed to get it fixed / changed in the following way:

# define Z probe G31 X0 Y60 Z3.80 P25 # Y was -50 before # bed leveling with left+right lead screws G30 P0 X10 Y130 Z-99999 # Y was 20 G30 P1 X240 Y130 Z-99999 S2 # Y was 20 G28 Z # mesh leveling M557 X20:240 Y55:230 P9:9 # Y was -49:137

So I had to roughly add 3 x probe_offset to most positions compared to my previously (flawed) configs.

Now the visual heightmap in DWC looks reasonable.

@resam Thanks for reporting this and sorry for the trouble you had. Your curl call works as expected with a Duet 3 in SBC mode but something is off in RRF with a Duet 2 in SBC mode. I'm looking into it.

Edit: This is now fixed upstream.

@chrishamm Thanks! I installed the new package, and it updated fine - seems to work now!

@resam that looks to me like a hardware issue with the display. However, you could try downgrading to the older firmware version to see if the issue continues.

@resam It was a shorthand version to ignore double (or even triple) slashes which are also permitted by FatFs, see http://elm-chan.org/fsw/ff/doc/filename.html But I suppose having /?/? instead of /* would also work.

@dc42 Cura-DuetRRF Plugin to embed thumbnails just landed on the public Ultimaker Cura Marketplace - but due to this issue it is not yet compatible with 3.4-rc1.

So, with the next RC it should immediately work with the latest Cura plugin version v1.2.5.

@resam No, there is nothing to be concerned about - I saw this with an earlier beta but didn't see any side effects. I think duettools is installed before duetruntime is updated and an install script from duetpimanagementplugin attempts invoke a program from it which loads an outdated assembly. I'll check again if I can fix it by adding a new dependency from duettools to the correct duetruntime version.

@resam Please try 3.4-b7 and check if the problem persists - there have been significant timing changes since 3.3 in order to address this and a few other problems.

Thanks everyone!

@phaedrux would be great if you could update both docs pages with a simple cross-link and a sentence that explains that they are equal.

@resam i hope that i can figurit out how it's go.
i am not so goo d at programing 🙂

@resam ...I simply tried renaming js to dwc and it worked... apparently if uploaded to the controller through DWC, it throws js files into the js directory and CSS into the css directory. Not sure what it does if you use a more complicated structure for some reason...

@chrishamm At this point I probably should admit that I am not using the DuetPi image - but installed everything from the Duet apt repos into my existing Pi... but the systemd service files are the same - so their Before/After dependencies should be correct as you wrote them.

@resam Thanks for your feedback.

I'll change DWC to ignore the casing of the SBC permissions - DSF does not care about it either. For the meantime I've added a note to the plugin documentation.

When I designed the plugin wizard I found the full URL (especially when pointing to GitHub repos) way too long. That's why I decided to truncate it - it doesn't have a practical disadvantage either.

The plugin identifier check in DWC seems to permit spaces and dots which isn't right. I've fixed this as well so that particular error shouldn't show up in the next version at all. Nevertheless I'll investigate that rather useless exception message, I would've expected it report something like Illegal plugin identifier instead.

I can confirm this behaviour on all 3 of my boards (2 Gloomy, 1 Duet). Tested with all internal and external plugins disabled just to be sure.

It's repeatable by hitting refresh on the tab and immediately switching tabs and waiting a couple of seconds, then tabbing back to a grey screen. I should also note that if the page is even partially rendered before tabbing off, the issue does not manifest.

I can not replicate this on firefox - only chromium based browsers (running on windows).

Notionally it seems to be influenced by the blue "connecting" dialog - if you go back to the duet tab before it closes the "connecting" dialog, the problem does not seem to manifest - but this could just be a red herring.

@resam Whatever it was, you can also avoid high load when using pydsfapi 3.2.0 or later by making use of the filters parameter when instantiating Intercept_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.

@resam This is exactly the reason you need to perform a flush. See here for an example how custom codes may be implemented: https://github.com/Duet3D/DuetSoftwareFramework/blob/v3.3-dev/src/DuetPiManagementPlugin/Program.cs#L122

@resam I don't maintain the Python API client so I cannot really comment on the internals. Model subscribers in patch mode get either the full object model or the requested filtered model props after connecting so it should be safe to assume that props in the dict are already present. List items may change, though.

There is some more documentation about the IPC API in the README where some JSON objects are described, see here. In general DCS should not shut down because of an API error or invalid command. It's right that it should output an error and terminate the client connection when invalid data is supposed to be processed, but DCS should continue operating after that.

When a code is intercepted, a client must send back a definite action to DCS to avoid locking up the G-code stream. If a client disconnects while DCS is still waiting for an interception result, DCS should resume the code execution. I already wrote a few plugins (although obviously in C# and not Python) and I can confirm the API works well in general. But if you do find errors, feel free to submit bug reports on GitHub and I'll comment on them there.

@resam said in Object Cancellation M486:

I read somewhere that the Duet2 is memory-limited and therefore only 10 parts are remembered - I have 12 on my current build plate. Lucky me.

In RRF 3.2.x it's 20 parts on Duet 2, 32 parts on Duet 3. In fact on Duet 2 it can count up to 32 objects, but it can't provide their dimensions beyond the first 20, and it will only provide the names of up to 20 objects.

I've made a note to check M486 C. It should respond with "Object N cancelled" if successful. Currently it returns nothing if the command fails, but I'll change that in RRF 3.3 to report why it failed.

the easy would be to delete what you don't need and save as a new project.

https://www.google.com/search?q=kicad+pcb+to+footprint shows a couple of approaches for making a part of it, i didn't test any to verify which versions etc.