Posts made by cdoe

@gloomyandy thanks for the update. Appreciate tracking this one down

@gloomyandy @T3P3Tony Thanks for ideas and suggestions. Now it makes sense - i'll rework daemon.g to only change colour if needed rather than just blindly doing so

@T3P3Tony I did and pauses went away, so i strongly suspect it's M150 and movement buffer interaction
Just in case, here's how leds are configured (wired on sht36 toolboard):

M950 E0 C"124.rgbled" T1

After updating my daemon.g to

while true
  ;#################### Electronics Bay Fan ###########################
  if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
    M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
    M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
  else
    M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
    M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

  ; Toolhead led based on temp
  ; unfortunately seems like this will pause move
  ; heater 0 - bed
  ; heater 1 - hotend
  if heat.heaters[1].current > global.hotSenseTemp
    M150 E0 R222 U95 B188 P96 S1 F0
  elif heat.heaters[1].current > global.warmSenseTemp
    M150 E0 R222 U201 B95 P96 S1 F0
  else
    M150 E0 R96 U223 B223 P96 S1 F0
  G4 S5 ; wait 5 seconds before looping

I'm still observing a slight pause (now every ~5 seconds).
Looking through Changelog M150 and its interaction with movement are mentioned couple of times. In particular "M150 commands are now queued to sync them with movement commands" (feature in 3.2) - and there were couple of fixes later on around that functionality is it possible that this is causing a pause?
Is there a way to check if movement buffer / queue is empty or not when that M150 in my daemon.g is executed?

@T3P3Tony Thanks for the tip.Will try this out.
I think this can be marked as solved (not sure how to do that).

@infiniteloop thank you - the issue is with daemon.g
in particular with calling macros which change led colour
Here's indicator_warm content:

; Set led on stealthburner to warm colour
M150 E0 R222 U201 B95 P96 S1 F0

@infiniteloop
I do:

;#################### Electronics Bay Fan ###########################
if move.axes[0].homed || move.axes[1].homed || move.axes[2].homed         ; check whether X, Y or Z drivers are active
  M106 P2 S0.85 H-1                                                       ; fan 2 runs at 80%
  M106 P3 S0.85 H-1                                                       ; fan 3 runs at 80%
else
  M106 P2 S0                                                              ; if not, turn off the electronics bay fan 2
  M106 P3 S0                                                              ; if not, turn off the electronics bay fan 3

; heater 0 - bed
; heater 1 - hotend
if heat.heaters[1].current > global.hotSenseTemp
  M98 P"/macros/led/indicator_hot"
elif heat.heaters[1].current > global.warmSenseTemp
  M98 P"/macros/led/indicator_warm"
else
  M98 P"/macros/led/indicator_cold"

@resam I don't - setup is running in standalone mode. But that gave me an idea. I think next step would be to check if there's an issue with toolboard - maybe some sort of issue with canbus throughput?
Reslicing with cura didn't help though - still having this periodic pauses

@Phaedrux Thanks for helping me figure this out..
There's no commonality i can figure out, tbh. It's also visible (in form of blobs) in vase mode as well - which from what i understand shouldn't have any pauses or layer changes at all?
Issue occurs even when heightmap/bed compensation is disabled.

I'm trying to "port" my profile to cura to see if this is a slicer issue.

Hi guys,
I'm running RRF v3.5.4 on Voron 2.4 300 mm with duet 5 mini and SHTv3 toolboard. Xol toolhead with orbiter v2 extruder. Prusa Slicer is used to slice models.
I've noticed that printing staggers every 12 seconds or so - first thought was this was to let layer cool, but that was also visible on printing infill on large-ish prints as well.
SD card was changed and that had no effect (both old and new were able to produce 40mb/s reads and 10mb/s writes.
I've tried bumping up acceleration but that seems to have no effect as well. My bed compensation is tapered (over 6mm), however, pauses were also visible on layers higher than 6mm, suggesting that this is probably (don't take my word on it) not related to low acceleration for Z axis.
Attached are M122/M122 B124 outputs and my config along with gcode file.
Where/what can I look at next?
config.g.txt
M122B124.txt
M122.txt
v13_top_panel.gcode

I've set orbiter filament sensor v2 set up recently.
It has 2 outputs (FS for sensing if filament is present) and FTU (outputs if filament is tangled or filament unload button is pressed).
The set up is slightly more elaborate than just a sensor since both outputs have 2 functions and logic is not straightforward as well. FS output works as expected as in changing state when filament is present or runs out, FTU output only changes state if filament is already present.

I'm running FlySHT36v3 Max toolboard with 124 being board CAN address and connected FS to io1.in to FTU to io2.in inputs (taking 5v and ground from same 5 pin connector) and had to use triggers for things to work.
This is a section in config.g

; Filament Sensor
M950 J1 C"^124.io1.in"                       ; define logical input for filament auto load
M581 P1 T3 S1 R0                             ; define trigger for filament auto load triggers trigger3.g
M581 P1 T2 S0 R0                             ; define trigger for filament sensing triggers trigger2.g
M950 J2 C"^124.io2.in"                       ; define logical input for filament unload
M581 P2 T4 S1 R0                             ; define trigger for filament auto unload triggers trigger4.g

trigger2.g:

; trigger2.g
if state.status == "processing"
    M300 S2000 P100                                     ; play beep sound
    M291 P"Ran out of filament while printing" S0 T3    ; display message
    M25
elif state.status == "pausing" || state.status == "paused"
    M291 P"Retriggered filament sensor during pause" ; display message
else
    M300 S2000 P100                     ; play beep sound
    M291 P"Ran out of filament" S0 T3   ; display message

trigger3.g:

; trigger3.g
M98 P"0:/macros/filament-load"

trigger4.g:

; trigger4.g
if state.status = "processing"
    M300 S2000 P100                                                     ; play beep sound
    M291 P"Filament is stuck or filament unload button pressed" S0 T3   ; display message
    M25
else
    M98 P"0:/macros/filament-unload"

filament-load and filament-unload macros will need to be created and populated for this to work but that should be more or less straightforward and more printer-specific than general set up
Hope that helps

Thanks again, updating from duet board worked. Digitizer doesn't work though but that's a separate issue

Thanks I'll try that. Didn't realise it can be done while paneldue has no firmware at all...

I've been able to flash 3.4.1 with bossac. GUI version is windows/macos version only which i don't have, so it seems that my paneldue is now just a bunch of useless hardware

bossac says “flash command failed”

Hi,
I've tried re-flashing 3.5.0 rc 8 firmware over usb and followed process described in documentation.
PanelDue had 3.4.1 firmware previously. However, it was in storage and was stuck in calibration prompt - i.e. a dot on top of the screen was visible and there was a prompt to touch it, but that was not progressing as if touch was not detected.
Here are some outputs from bossac:

$ ./bossac --port=/dev/ttyACM0 -i
Atmel SMART device 0x289b09e0 found
Device       : ATSAM4S4
Chip ID      : 289b09e0
Version      : v1.13 RC2 Feb 20 2013 13:25:17
Address      : 4194304
Pages        : 512
Page Size    : 512 bytes
Total Size   : 256KB
Planes       : 1
Lock Regions : 16
Locked       : none
Security     : false
Boot Flash   : false

output when flashing with 3.5.0:

./bossac --port=/dev/ttyACM0 -e -w -v -b ~/Downloads/PanelDueFirmware-3.5.0-rc8-7.0i.bin 
Atmel SMART device 0x289b09e0 found
Erase flash
done in 0.001 seconds

Write 176720 bytes to flash (346 pages)
[                              ] 0% (0/346 pages)
Flash command failed

Similar output when trying with version 3.4.1:

./bossac --port=/dev/ttyACM0 -e -w -v -b ~/Downloads/PanelDueFirmware-3.4.1/PanelDueFirmware-3.4.1-7.0i.bin
Atmel SMART device 0x289b09e0 found
Erase flash
done in 0.001 seconds

Write 170916 bytes to flash (334 pages)
[                              ] 0% (0/334 pages)
Flash command failed

Are there any troubleshooting steps I could try to figure out why flashing no longer works and if hardware is in working condition?
There are no torn wires or connector strips on visual inspection

Only got my hands to it now. Sadly 140R resistor burned out so badly that there are no traces left to put replacement component. LEDs are fine though. Has anyone tried using silver tracing pen to re-draw traces? Will it work properly with moving part like effector?

Thank you.

Is there something similar to replacement parts for duet3d but for smart effector?
I'll need to replace LEDs (D1, D9 and D7) as I was switching from 24v to 12v and then back and forgot to remove 12v jumper for LEDs so they were working w/o extra resistor for some time.

When +12V is connected to centre pin of V_FAN voltage selection block - does it bypass mosfets? Also do I need to connect negative from buck converter to negative of duet wifi? Looks like negative from buck converter output is common on both sides so it's common with negative on PSU as well.