Posts made by robotsneversleep

I suspect I'm misusing macros, but I have a NeoPixel ring, and after discovering meta commands and daemon.g I may have gotten carried away
Also I'm trying my hardest to avoid using an SBC if I can.

Fundamentally, I'm trying to keep my NeoPixel control routine to under 500mS to prevent taking control away from the firmware for too long.
Here's a trial I've been running:

daemon.g:

while global.runDaemon
    M98 P"statusled/main.g"
    G4 P500

statusled/main.g

var time_b = state.upTime + (state.msUpTime / 1000)

while iterations < 1
    M98 P"statusled/effects/fade.g" D"I" C{global.STATUSLED_RED}
    M98 P"statusled/effects/fade.g" D"O" C{global.STATUSLED_RED}

var time_a = state.upTime + (state.msUpTime / 1000)
var time_d = var.time_a - var.time_b

if var.time_d > 0.5
    var str = "Warning: StatusLED took " ^ var.time_d ^ "s (> 0.5s) to run. Check SD read speed!"
    M118 P0 S{var.str} L1

fade.g:

var e = global.STATUSLED_STRIP_ID
var s = global.STATUSLED_NUM_LEDS
var d = global.STATUSLED_MAX_BRIGHTNESS / global.STATUSLED_FADE_DURATION
var b = param.D == "O" ? global.STATUSLED_MAX_BRIGHTNESS : 0x0

if param.D == "O"
    set var.d = -var.d

while iterations < global.STATUSLED_FADE_DURATION
    set var.b = var.b + var.d
    M150 E{var.e} P{floor(var.b)} S{var.s} R{param.C[0]} U{param.C[1]} B{param.C[2]} W{param.C[3]} F0
    G4 P1

fade.g just adjusts the brightness of the LED's every mS to fade in or out a given colour.
Depending on what I set STATUSLED_FADE_DURATION to, I can easily exceed 500mS, so it's configured at the moment to be very low e.g. 50mS.
This whole routine (all code above) takes around 0.43s to execute.

However, when doing some refactoring, I swapped out the M150 command in fade.g for a macro call called solid.g like so:
solid.g is just an M150 wrapper which updates all LED's to a single colour negating the need to pass the S param to M150.

M98 P"statusled/effects/solid.g" B{floor(var.b)} C{param.C}

This takes 1.19s. I was surprised until I realised the firmware is probably reading this file from SD and executing it on every loop iteration.
I'm using a SanDisk Ultra Class 10 A1 SD card with an advertised read speed of 98MB/s. The speed test gave me:

M122 P104 S1
Testing SD card write speed...
SD write speed for 1.0MByte file was 4.98MBytes/sec
Testing SD card read speed...
SD read speed for 1.0MByte file was 1.81MBytes/sec

From reading the Duet documentation, those speeds are actually pretty good, so I have some questions:

1. What limits the Duet in terms of SD card transfer speeds? Hardware?
2. Is the read buffer fixed at 512B (i.e. in hardware) or can it be increased in the firmware?
3. Is caching of macro's, either after reading from SD, or after parsing a possibility?
4. Apart from calling as few macros as possible, doing fancy fade effects etc, is there anything I can do to improve execution speed?
5. Should I really be using an SBC for this, and just passing the M150's to the firmware?

As I said at the beginning, I'm aware I'm using macro's in ways in which they were probably not intended, but there's so much potential...
Thanks for your time

@semi55 IIRC using job.file.numLayers doesn't work because the layer height is determined based on the first layer only, which is problematic if the first layer is different from the rest of your model, or you're using adaptive layer height.

To answer your other questions... daemon.g is typically checked for every 10s by the firmware for existence and if it exists, it's executed.
I decided an update of the LED's every 10s is not fast enough, so put a while loop in it which is executed every 1s. The dwell (G4 S1) is there to hand control back to the firmware. You do have to be careful not to let the macro take too long to execute or it will affect printing.

state.status is updated automatically by the firmware.

@airscapes This is what I have for my BLTouch on Duet 3 Mini 5+

M950 S0 C"io1.out"
M558 P9 C"^io1.in" H2 F240 T6000
G31 P500 X0 Y25 Z2.43

Is it possible you need to enable the pullup on io3.in?
EDIT: I assume you have the appropriate deployprobe.g and retractprobe.g macros:

;
; deployprobe.g
; called to deploy a physical Z probe
;

M280 P0 S10 ; deploy BLTouch

;
; retractprobe.g
; called to retract a physical Z probe
;

M280 P0 S90 ; retract BLTouch

It's certainly possible, and fairly straight forward to do with macros and daemon.g. This code is straight from my own printer. It incrementally lights each LED in green based on file position.

in config.g:

if !exists(global.runDaemon)
    global runDaemon = true ; enable/disable on power-on-reset.

in daemon.g:

while global.runDaemon
    if state.status == "processing"
        M98 P"statusled.g"
    G4 S1

in statusled.g:

var strip_number = 0
var num_leds = 12
var brightness = 255

var chunk_size = job.file.size / var.num_leds
var led = 0
var chunk = var.chunk_size

while var.led < var.num_leds
    var f = var.led < (var.num_leds - 1) ? 1 : 0

    if job.filePosition >= var.chunk
        M150 E{var.strip_number} P{var.brightness} F{var.f} R U255 B0 W0 S1
    else
        M150 E{var.strip_number} P{var.brightness} F{var.f} R0 U0 B0 W0 S1

    set var.chunk = var.chunk + var.chunk_size
    set var.led = var.led + 1

It's not perfect; for example for a small model, the first 20% of the file might be comments from the slicer noting the slicer settings, in which case, the LED's will show the print as 20% complete on starting; but perhaps that can be fixed through g-code post-processing.

I've found if I put an array into the object model globals that it cannot be visualised in the object model plugin in DWC. To reproduce:

global ORANGE = {255, 32, 0, 0} ; RGBW

Then try to look at the contents of that array in the DWC object model plugin. The key and arrow are there, but the value can't be expanded.
I'm using RRF 3.5.1, DWC 3.5.1. Tested on Edge (Chromium) and Firefox.

@droftarts oh, nice! For some reason I had it in my mind that RRF would either attempt to push the W component to the LED's, or give an error. I wonder if it was happening on a firmware version before 3.5.1.
The macros I wrote make heavy use of arrays anyway, so won't be supported on anything before 3.5.1. Thanks for checking that.

I've been working on some macro's to display printer state (e.g. temperature, % completion) on a 12-LED RGBW NeoPixel ring.
It's something I plan to release in the future to the wider community, so I'll need to support both RGB and RGBW strips.
This means that, for each M150 command, I must query whether or not the W channel is supported, or the output will be wrong:

if ledStrips[global.STATUSLED_ID].type == "NeoPixel_RGBW"
   M150 <...> R255 U255 B255 W255
else
   M150 <...> R255 U255 B255 ; W component not supported

This can be quite tedious. Is it possible to have the firmware ignore the W component if RGBW is not supported? Thanks a lot

In David's blog for the IR Probe (and possibly elsewhere), I read the IR probe should work fairly well on the dark grey variant of BuildTak.

I recently picked up an IR probe, and its accuracy is impressive. The deviation from mean on a repeatability test was < 0.005mm.
However, from my testing, it seems the precision of this probe is so high that it's easily influenced by the texture of the BuildTak:

heightmap-buildtak.csv

As you can see the points are all overe the place. The BuildTak is almost flawless (with exception of an ever-so-slightly shinier spot where the nozzle made contact at X145 Y145. The bed is relatively flat when probed with a BLTouch.

These are my probe settings, and the firmware at most only probed twice to get the mean within 0.03mm so I know it's accurate.

M558 P8 C"^io6.in" H1.0 F600:300 T12000 A4
G31 P50 X0 Y23 Z0.76

I should probably mention I'm using a clone, as I managed to short two of the official ones and at 30+ clams each I'm getting depressed
I noticed the official one is missing C3 and has a 10uF electrolytic cap instead of 22uF, but I've not looked in any more detail.

Is what I'm seeing here expected, and is there anything I can do to improve it? FWIW, I'm using a Duet 3 Mini 5+ running RRF 3.5.1.

Hi @cdillow, how well is using the Scanning Z probe as the only probe working out for you? I'm considering doing the same, but as you pointed out, there doesn't seem to be much guidance on exactly how to go about doing this properly.

Have you found that your Z probe trigger height is consistent, or does it change with temperature, in which case you need T compensation?
If you have done some temperature compensation, how did you do it?

Just thinking out loud here, but my hope is that I only need to find Z=0 once (or Z=0 for each bed surface I use) and the M558.1 calibration will do the rest.