@jhalewood

I managed to fix this
It was an apparmor problem preventing the running of python scripts
Setting apparmor to complain mode allowed the python script to run and the plugin works fine
Though after a reboot it goes back to "partially started" - the script isn't running. Manually clicking stop and then start on the plugin allows it to run again
(see also https://forum.duet3d.com/topic/26504/apparmor-prevents-plugins-with-python-scripts-running)

Hello,

2 issues, both of which may be addressed with 3.4 beta's, I'm unsure
Both issues related to installed and running a plugin with a python script; specifically filament load weighing (https://forum.duet3d.com/topic/25419/another-weighing-filament-holder)
This is in relation to duet3 w/ SBC

1. apparmor prevents python scripts from running
   apparmor is installed, and runs properly, but I have to set it to complain mode (sudo aa-complain /etc/apparmor.d/*) for it to run the python script (on plugins page, goes from 'partially
   started' to 'started')
   The only thing that appears in syslog is "Dec 23 08:34:34 duet3 kernel: [ 417.399578] audit: type=1400 audit(1640219674.657:13): apparmor="DENIED" operation="exec"
   profile="/opt/dsf/plugins/FilamentLoadCell/**" name="/usr/bin/python3.7" pid=1537 comm="filament_load_c" requested_mask="x" denied_mask="x" fsuid=996 ouid=0"

2. restarting the pi also prevents the plugin loading properly, it restarts as 'partially started'. Stopping the plugin and clicking start again fixes this. There is no error in syslog. (same as this
   https://forum.duet3d.com/topic/25834/dwc-dsf-plugins-remain-partially-started-after-restart)

Cheers,
J

@chrishamm Chris you are a fricken legend!

@droftarts Thank you so much Ian. Really appreciate that detailed input!

You are correct about the crash, occasionally it can get so bad that even with increasing M671 S parameter, it'll crash.

I wasn't sure about including the M906 and M350 commands, I only included because the gcode dictionary says

M584 must come earlier in config.g than any M350 and M906 commands.

But it makes sense they're not needed as already declared originally in order.

Thanks again Ian!

Hi,

From looking around, I don't believe it's possible for a user to control a single Z motor when you have multiple independent motors (i.e. in this setup https://docs.duet3d.com/User_manual/Connecting_hardware/Z_probe_auto_levelling).

Though obviously the firmware can control the motors independently after a G32 command (after it completes, it will adjust each motor a different amount) - so maybe there is a way already?

Every now and then, due to user error, physical manipulation etc the Z motors can become massively misaligned - more than "true bed levelling" can fix.

I was wondering if the following macro was a viable solution, or would cause problems?

I.e.: remap Z axis to a single motor, I've included M906 and M350 because the dictionary says these must come after M584 (is this necessary? my config.g has already loaded these on initial boot, and the values aren't changing), move the single motor, then reset the config back to what it was.

M584 Z3
M906 Z1500
M350 Z32

G91
G1 F600 Z1

M584 Z3:4:5
M906 Z1500
M350 Z32

I would have 6 of these macros, singling out each motor and having an up and down for each. I would use them to grossly level the bed, then use G32 to finish fine tuning.

I just want to make sure changing the motor assignment on the fly won't cause problems/damage the board? Or, if there is a better solution?

Thanks

Hi,

I have duet 3 6HC, and I've just noticed the shield_gnd pin.

I can't find any documentation on this (on the hardware document page - you can see the holes on picture, but it's not listed under the pins), or elsewhere on duet3d.

I presume this is for the usual purpose of reducing interference (or as a gbd point from shields in wires?)

I was wondering what the recommended connection is for this?

I have a AC-DC power supply; do I connect it to GND on the DC output side? Do I connect it Earth on the AC input side? Something else?

Thanks

As per title, firstrun.sh doesn't seem to execute on duetpi (I've been using latest image 2024 04 19 duetpi - full not lite, and I've tried 32 and 64 bit versions)

It will get edited to change the directories as appropriate (from /boot to /boot/firmware), but nothing included in the files seems to execute, and the file does not self delete.

Is this intended behaviour or is something going wrong?

I've attempted to add test echo's to a test file just see if anything in it gets run, and those aren't produced either.

@chrishamm would it be possible to add to the next duetpi build something that disables the udev automount in favour of just using duetpi exclusive version?

I've been trying to find a (ideally simple) way to disable udev automount from the boot partition, i.e. using firstrun.sh or cmdline.txt, I've been unable to (which doesn't mean it doesn't exist, I'm no expert). But since this seems to be a duetpi conflict, perhaps a change in the build is warranted?

Though I understand this is not a big problem, considering I seem to be the first person to report it... Just a suggestion.

@chrishamm I ran rm /etc/udev/rules.d/99-usb-automount.rules and that seems to have done the trick! Thanks @chrishamm

you mentioned I could "disable that feature" or edit the udev rule (rm ..)

how would i disable that feature? and which method would you recommend?

Is it possible to do this on the boot partition prior to first boot?

also tried setting fsck.mode=skip, nil effect

@chrishamm i forgot to mention i tried disabling apparmor, didn't help

but i have reflashed the ssd and edited cmdline to remove apparmor, quiet, and splash, and re-did first boot, reboot, enter to pass energency mode, and exported journal

this file contains the entire 25000 lines of journalctl

have a look at line 608

all_logs.txt

I've been running duet for years off an SD card on my raspberry pi connected to my 6HC

For fun i thought I'd try running from an SSD (in an enclosure to usb)

I cannot get duetpi to work (image 2024 04 19 full 32bit) - this is a fresh flash with NIL changes (not even adding wpa supplicant/sh)
it seems to pause substantially with message "systemd-rfkill.service" while the blue duetpi logo is displayed

then it goes into emergency mode with: (i have to type this from a photo, so not exact, but you get the gist)

nm1: controller never released inhibit bit (we can ignore this - this is because no SD card in slot)
You are in emergency mode. After logging in type jounalctl -xb to view system logs, systemctl reboot to reboot, systemctl default or exit to boot into default mode

cannot open access to console, the root account is locked.
see sulog man page for more details

press enter to continue

pressing enter it'll say

reloading system manager configuration
starting default.target

it'll then boot to desktop
duet doesn't work properly, the web page loads, but it cant connect to the board, and in journalctl logs there's errors for duet starting

the desktop works, and I can SSH in, but it'll enter emergency mode as above on every reboot

Please note that if I use raspberry pi os (in rpi imager) it boots fine, there's no pause on systemd-rfkill.service, it boots quickly and without issue (though also of course without duet)

Googling the problems some people have suggested is a problem with UAS (my ssd adapter is jmicron), however adding quicks to cmdline.txt doesn't fix it (and rasp pi OS boots fine without this change)

Another suggestion was that fsck was timing out as the drive is large, i edited fstab to disable fsck on my boot drive, no difference (and rasp pi OS boots fine, fsck doesn't time out)

I've tried raspberrypi imager, balena, and 2 usb enclosures, and using a USB 2 port instead of USB 3, nothing helps

output of journalctl : https://pastebin.com/UDZtvrzC

any ideas?

EDIT: i updated bootloader to run from USB of course