Control server needs to be restarted on emergency shut down

chrishamm

@kuon Yes, it is, see my previous comment. config.g is only executed when RRF starts but not when DCS is restarted, so you should put M550/M551 in dsf-config.g instead. The machine password is stored by DCS and not RRF, so it is cleared upon restart if it is only in config.g

kuon

@chrishamm said in Control server needs to be restarted on emergency shut down:

@kuon Yes, it is, see my previous comment. config.g is only executed when RRF starts but not when DCS is restarted, so you should put M550/M551 in dsf-config.g instead. The machine password is stored by DCS and not RRF, so it is cleared upon restart if it is only in config.g

dsf-config.g must be activated in some way? Because I just tried and it has no effect. I added the M551 and M550 in it. (which I removed from config.g) The name in the UI defaults to the hostname of the PI instead of the M550 value I set.

Also, is it normal that the UI prompt for password on each reload and that it does not set a persistent session?

jay_s_uk

@kuon is this a fresh install or have you been upgrading the SBC side for a while?

kuon

@jay_s_uk I have been upgrading for a long time, maybe that's what is causing the issue. I can try a fresh install.

jay_s_uk

@kuon i would try a fresh install because the duetpimanagement plugin wasn't around until RRF3.3

chrishamm

@kuon no, dsf-config.g is automatically called by DCS and does not require the management plugin. Neither do M550 or M551. In order to apply it, ESTOP or a service restart is needed.

kuon

@chrishamm I did restart the service with systemctl and it does not apply dsf-config.g. To test it, I have no M550 in config.g and M550 P"Hello" in dsf-config.g. If I restart the service or emergency stop and then reload the page, the hostname is still used on the top left, and running M550 returns the hostname as well. (instead of Hello)

chrishamm

@kuon I have no good explanation why dsf-config.g isn't executed on your system, perhaps a permission thing? Make sure it is present in your sys directory (also available as /opt/dsf/sd/sys on Linux) and that it is readable by the dsf user/group.

When I restart DCS, I can see

Nov 22 18:41:55 Ender3Pro systemd[1]: Stopped Duet Control Server.
Nov 22 18:41:55 Ender3Pro systemd[1]: duetcontrolserver.service: Consumed 6.445s CPU time.
Nov 22 18:41:55 Ender3Pro systemd[1]: Starting Duet Control Server...
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: Duet Control Server v3.4.4
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: Written by Christian Hammacher for Duet3D
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: Licensed under the terms of the GNU Public License Version 3
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: [info] Settings loaded
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: [warn] Support for third-party root plugins is enabled
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: [info] Environment initialized
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: [info] Connection to Duet established
Nov 22 18:41:56 Ender3Pro DuetControlServer[1360]: [info] IPC socket created at /run/dsf/dcs.sock
Nov 22 18:41:56 Ender3Pro systemd[1]: Started Duet Control Server.
Nov 22 18:41:59 Ender3Pro DuetControlServer[1360]: [info] Starting macro file dsf-config.g on channel SBC
Nov 22 18:42:00 Ender3Pro DuetControlServer[1360]: [info] Finished macro file dsf-config.g

which proves it is executed correctly.

Also note that in SBC mode M550 may be used without the DuetPiManagementPlugin only to decorate the hostname, e.g. to change the caption from "ender3pro" to "Ender 3 Pro" (i.e. to change casing and to add spaces). For system-related changes on Linux, the DuetPiManagementPlugin is mandatory.

Since I cannot reproduce any of your problems here, it may actually be a good idea to backup your config, obtain our latest DuetPi or DuetPi Lite image again, and then see if the problems persist once your SBC is up and running again.

kuon

@chrishamm I did some more testing, and I think I "might" have something.

I realized that prusa slicer is using GET /rr_connect but this call returns 404, I have a feeling this is not normal.

I tried with

curl  'http://3d.e42.ch/rr_connect?password=1234' -v

and sure enough I get a 404.

Prusa seems to ignore the error and proceed to the rest of the requests (/machine/status ...), which works if no password is set, but doesn't if it is set.

chrishamm

@kuon It is normal. DSF v3.5 will get an emulation layer for rr_ calls but DSF v3.4 only supports the REST HTTP API, see https://github.com/Duet3D/DuetSoftwareFramework/wiki/REST-API-(v3.4.4-or-newer)

kuon

@kuon apt says I have the latest 3.4.4 version, but maybe the install got corrupted some way.

kuon

@chrishamm Ok, I guess I'll reinstall my board, but I have one last question that didn't get answered. If a password is set, when reloading the browser, the password should NOT be prompted again right? (like a remember password thing)

chrishamm

@kuon Yes, it should be prompted. The password is stored per browser session and when you open a new tab or window, you create a different new session. It should not be prompted after E-STOP, though.

kuon

@chrishamm Ok, so I think I got the full understanding of the thing now:

I expected the password to NOT be prompted again forever (or 30 days) (like remember password) with a cookie of some sort. This expectation was wrong, and I took the constant prompting on reload as a bug while it was the intended behavior.
The password was only set on initial start and emergency shutdown, because it was set in config.g and not dsf-config.g. This explains why I had to restart the service to "fix" this.
Prusa slicer just does not support authenticating with 3.4.4.

The only actual bug is that dsf-config.g is not executed. For this I checked the logs and I don't see mention of it, also the permissions are OK.

For the actual issue, I guess I'll just not use the password feature of the rep rap and I'll use other mean to prevent accidental access (like creating a VLAN for the printer and the control computer).

chrishamm

@kuon I just checked, the reason why dsf-config.g isn't executed is probably because you didn't set up the plugin services (potentially with AppArmor) as described in the upgrade notes. It is already integrated in the latest image but just in case you want to have another look, here the upgrade notes again: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x#version-330

Maybe @bot can help again with password support in SuperSlicer/PrusaSlicer (see here, here, and here)

kuon

@chrishamm Yes that was it. I did follow the update instructions, but I didn't notice there was TWO services, duetpluginservice AND duetpluginservice-root. I enabled the later and now it works.

I am sorry for this "long" thread.

Thanks, your support was great. I built many machines with duet and I'm very happy with it.