@chrishamm

I understand the refresh - that was a secondary thing. I'm not too fussed, now that I know its not a bug / issue.
Cosmetically - I think it would benefit from consistent language.

V1.0.1

Exposure control is notoriously hit-and-miss. I changed the handling of exposure control to log the values at startup so that the user has a known point from which to research.
Essentially there are two options (used together). The first switches the camera to manual control and the second sets the exposure. All this, provided the camera supports exposure control. Just what the required values are is undefined.

Some cameras switch to manual when sent the value 0.25. Some require the value 1 to be sent, others ??

Exposure values are sometimes required to be between 0.0 and 1.0, sometimes negative numbers, sometime some other value (ms equivalent ?). It mainly depends on how the manufacturer set up the camera, the drivers used and even the OS.

In any case - if you need to adjust the exposure, there is going to be some trial and error.

For example, on one of my cameras, manual mode is set with 1 and usable exposure ranges are roughly in the range 75 to 200.

Good luck 🙄 The internet if full of opinions ...

@MintyTrebor

Hi,

I have been using it for some time.

It is the greatest thing since sliced bread!

I'm very glad you have been keeping it up-to-date as new versions of Duet firmware come out.

Do you have a "tip jar"?

Frederick

@droftarts
@chrishamm

OWA TAGU SIAM

My apologies - rebuild at each release level (even minor ones) ... 😊 😊 😊

All is well in the world of plugin installs.

@chrishamm
Understood, as it relates to DWC. I may just use "sbcDsfVersion": "3" for the DSF only plugins.

@stuartofmt Thanks. I ran into the venv elsewhere so that makes sense. I will move to 3.6.

OK, I may have inadvertently resolved it.

I found how to remove the desktop and boot to terminal using raspi-config. I wanted to understand the RAM cost. I have an RPi4b with 2GB RAM.

FYI:
in terminal mode after boot I have 1.5 GB free.
In desktop gui with DWC running at 1280x900 I have 960 KB free.

Anyway, after switching back to GUI mode everything boots as expected and DWC starts. So I suspect my config was whacked somehow (I touched nothing!) and running the rasp-config corrected the situation.

Sorry for all the bother.

@Notepad Thank you very much, unfortunately I only have the option to install the plugin...perhaps the other options are no longer available in version 3.5.4?

@chrishamm Okay thanks for all the pointers ! I switched all my machines to 3.5.3 and made the changes with the connections that you suggested, and it solves most of my problems.

For the problem that I mentionned due to the machine being shifter along the Z axis after executing a macro from the plugin, I found something that might have caused the issue:

When intercepting a command inside the plugin, I was always starting by sending G90 and M83 to the machine to make sure that whatever mode it is in, I can always perform moves and extrusions in absolute and relative mode, respectively. I suspect that those two commands might have caused the machine to shift position along Z due to synchronization issues because I removed them and the issue never happened again...

Updated to V1.3.3 for DWC 3.5.3

@MintyTrebor
I'm very sorry! It was my fault...
The graph was not showing the same value as the numeric panel!
Whats the difference between requestedValue and actualValue? Is the actualValue the "real" PWM inside the min and max settings?

EDIT: Now i need a RRF3.5.3 version...
It's funny... first, one layout was not working because the missing retraction parameters in OM (RRF5.3.2). Now, with 3.5.3 the plugin itself is not working anymore..🙃

@madeinta1wan Can you figure out what files are taking up the most space? If you have an old DuetPi version installed, make sure rsyslog isn't installed (sudo apt purge rsyslog), because that used to log a lot of stuff without ever purging the log files, which gradually filled up the SD card.

@chrishamm

I took the liberty of adding some additional checks / logging to build-plugin.js. Warns if the plugin src/index.js file is missing. Hopefully helpful:

build-plugin.js

ExecOnMcode v0.6 has been released.
This version now supports DWC 3.5

@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.

@chrishamm Thanks a lot, that was the problem ! I was looking at an old documentation page that didn't show that this permission was possible... Thank you !