Posts made by ofliduet

@jay_s_uk This did indeed solve the problem. Well spotted!

I've just started to wire in my new Roto Toolboard. I connected the x-probe on the toolboard the same way I had it on the LC1 that it is replacing. But when I configure the input I get a timeout.

M574 X1 S1 P"21.io1.in"
CAN response timeout: board 21, req type 6060, RID 26

The board does respond to status requests and the lights are flashign in sync, although it seems slightly out of phase with the motherboard. The main and tool boards are wired to the same power supply. In fact the toolboard is wired to the same terminals the LC1 was using before, which was working fine.

The only other thing I have changed is the firmware on the motherboard. It was 3.2 with the LC1 and is now 3.5-rc3 with the RR.

Any ideas what might be causing the timeout? Status repsponse from the toolboard below

M122 B21
Diagnostics for board 21:
Duet TOOL1RR firmware version 3.5.0-rc.1+ (2023-11-17 12:25:22)
Bootloader ID: SAME5x bootloader version 2.9 (2023-10-06)
All averaging filters OK
Never used RAM 165332, free system stack 192 words
Tasks: Move(3,nWait,0.0%,182) HEAT(2,nWait,0.1%,102) CanAsync(5,nWait,0.0%,67) CanRecv(3,nWait,0.0%,80) CanClock(5,nWait,0.0%,70) ACCEL(3,nWait,0.0%,68) TMC(2,nWait,1.1%,60) MAIN(1,running,93.6%,306) IDLE(0,ready,0.0%,29) AIN(2,nWait,5.2%,231), total 100.0%
Last reset 00:31:20 ago, cause: software
Last software reset data not available
Driver 0: pos 0, 507.0 steps/mm, standstill, SG min 0, temp 35.3C, read errors 0, write errors 0, ifcnt 45, reads 46489, writes 0, timeouts 0, DMA errors 0, steps req 0 done 0
Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00
Peak sync jitter -2/11, peak Rx sync delay 185, resyncs 0/0, no timer interrupt scheduled
VIN voltage: min 24.2, current 24.2, max 24.2
MCU temperature: min 32.2C, current 32.6C, max 32.6C
Last sensors broadcast 0x00000002 found 1 9 ticks ago, 0 ordering errs, loop time 0
CAN messages queued 20238, send timeouts 0, received 9104, lost 0, errs 0, boc 0, free buffers 38, min 38, error reg 0
dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0
Accelerometer: LIS2DW, status: 00
Inductive sensor: raw value 268435455, frequency 25.00MHz, current setting 13, ok
I2C bus errors 0, naks 0, contentions 0, other errors 0

Is the STL / STEP for the probe holder availalbe that I see in the picture of the Revo toolboard?

@Piet Right. I'm not a big fan of leaving bed edges unsupported with only 3 mounting points. You might be able to tell my bed isn't that stiff. I therefore actually have 2 screws and 2 fixed points. The two screws are there so I can adjust twist in the bed. One might be theoretically enough, but two allows me to make opposing adjustments that don't move the probe point in the middle near the lead screw. Probing all 4 in the script gives me the output I need to even everything out.

All this gives us a workaround for your original question: Probe an additional dummy point in your manual test and you get the output you need for your one-off calibration.

I suspected as much. It might be worth keeping it around for backwards compatibility. Currently the error response breaks Octoprint.

On my printer (3 leads screws, 4 bed screws) the bed.g looks like this and performs an automatic level:

M561                    ; clear any bed transform

; If the printer hasn't been homed, home it
[more code ...]

; Probe the bed and do auto calibration
M558 H10 ; higher dive hight for yet to be levelled bed
G30 P0 X{move.axes[0].max/2}  Y{move.axes[1].max+sensors.probes[0].offsets[1]} Z-99999
G30 P1 X{move.axes[0].max-10} Y10                                              Z-99999
G30 P2 X10                    Y10                                              Z-99999 S-1

M558 H3 ; back to speed

while this is my "bed_level.g" macro for tuning the bed level screws:

; Check bed level

; Probe the bed
M558 H10
G30 P0 X{move.axes[0].max} Y{move.axes[1].min} ; probe near an adjusting screw 
G30 P1 X{move.axes[0].min} Y{move.axes[1].min}  
G30 P2 X{move.axes[0].min} Y{move.axes[1].max} 
G30 P3 X{move.axes[0].max} Y{move.axes[1].max}  S-1  ; probe near an adjusting screw and report adjustments needed
M558 H3

echo "Deviation:", move.calibration.initial.deviation ^ "mm"

As you can see the commands are the same really, so I must assume the difference is that one is called from a G32 command, vs the other is a standalone macro without any special meaning.

I'm getting this error response from a Duet 3 with SBC. Is this due to the SD "card" being a directory on the SBC, which doesn't need initialising? The gcode documentation or forums do not give any hint on why this code is not supported (any more).

Have you had a look at RepPanel?

@achrn Playing with it a bit more last night I can confirm that the sample code does run correctly when called directly. Where I have problems is when I call the exact some code while there are other things going on.
I'm trying to write an Octoprint plugin that provide a virtual printer in Octoprint, so that I can use TheSpaghettiDetective and the Canvas plugins for the Pallette device without having to go through the serial connection. So the code is called up on startup of the Octoprint server when it loads all plugins and the process is obviously busy at that time with multiple threads doing things at the same time. This seems to have an affect, hence my question on the tread safety of the API.

@achrn Don't think so. This is an initial model, coming in unsolicited directly after the connection has been made. The printer is standing still and I can see the complete model in the recv line. The problem might actually be on the dsf side, where it shouldn't send out a machine model unless specifically requested.

I use this code in my homez.g to run automatic tramming (three motor bed) and mesh levelling only if the machine has been off or been reset:

if move.calibration.numFactors = 0  ; no bed levelling run yet
	G32
	M98 P"homing/unsafe-homez.g"
	G29
else
	M98 P"homing/unsafe-homez.g"

with unsafe-homez.g containing

G1 X{move.axes[0].max/2} Y{move.axes[1].max/2} F15000    ; move to homing position 
M558 H10 ; careful when homing
G30      ; home precise with Z-probe
M558 H3  ; back to speed

Different question: Is it possible to use the API to access the socket from a different host? It looks so close to me but no catch.

I'm trying to use the api with a Duet3 board with firmware 3.1.1 (stable) and the initial connect for the subscription gives me the confirmation immediately followed by a complete machine model:

send: {"mode": "Subscribe", "version": 8, "SubscriptionMode": "Patch", "Filter": ""}
recv: {"success":true}{"boards":[{"bootloaderFileName":null,"canAddress":0,"firmwareDate":"2020-05-19b2","firmwareFileName":"Duet3Firmware_MB6HC.bin","firmwareName":"RepRapFirmware for Duet 3 MB6HC","firmwareVersion":"3.1.1"

causing a parser error

  File "/home/pi/src/OctoPrint/venv3/lib/python3.7/site-packages/pydsfapi/pydsfapi.py", line 446, in connect
    return super().connect(sim, socket_path)
  File "/home/pi/src/OctoPrint/venv3/lib/python3.7/site-packages/pydsfapi/pydsfapi.py", line 238, in connect
    response = self.receive_response()
  File "/home/pi/src/OctoPrint/venv3/lib/python3.7/site-packages/pydsfapi/pydsfapi.py", line 280, in receive_response
    return json.loads(json_string, object_hook=responses.decode_response)
  File "/usr/lib/python3.7/json/__init__.py", line 361, in loads
    return cls(**kw).decode(s)
  File "/usr/lib/python3.7/json/decoder.py", line 340, in decode
    raise JSONDecodeError("Extra data", s, end)

Is that a known problem?

I'm also wondering about whether the API is threadsafe. A complete worked example with a thread running in the background periodically updating a complete machine model with patches would be extremely helpful.

Update: There's a caveat. The model isn't always updated correctly when there's an empty entry in an array. The board will return an update like

{"heat":{"heaters":[{},{"current":23}]},"sensors"...

and the empty curly braces will wipe out the model for the first heater. When there is an updated including a new value for heater 0 it's back to normal.

Disclaimer: I'm as new to this as are you (total Python beginner).
That said, I think I have found what you are looking for.

update = subscribe_connection.get_machine_model_patch()
machine_model.__dict__.update(json.loads(update))

@bearer Excellent. It's a start. With that at least I can put it behind the haproxy Octoprint is using itself. Thanks!

This is a follow up to DWC + Octoprint on RPi + Duet3?. I want to achive the same thing. The reason are plugins that don't exist yet on DWC. The two that I'm looking for are

• TheSpaghettiDetective for AI monitoring of prints and
• Canvas / Palette 2 so that I can print multicolour with my Mosaic Palette 2S Pro.

I'm not here to discuss the pros and cons, those have been stated in the above thread. If someone wants to contact me to work on integrating those plugins into DWC, I'd be game.

That said, one of the problems encountered is the clash between Octoprint and DWC both wanting to open port 80. So my question is, how do I change the URL root for DWC from http://localhost/* to http://localhost:8080/dwc/* ?

@ofliduet Confirmed. Using the 5V supply from the Z Probe connector, the GL-8H sensor works. One axis homed, two to go.

Thinking about this some more, the sensors work fine on the original MKS Gen L board, which provides 5V to the VIN pin of the sensor. So 5V from e.g. the PanelDue connector should suffice, correct?

I am attempting to convert an Evnovo Sidewinder X1. The endstops used are Sunx GL-8H types, which according to Panasonic, the new owners of Sunx, are inductive sensors that require 12-24V supply voltage. Would these work on a Duet Maestro if I connect the VIN pin for the probe to the 24V supply? The input pin is documented to work up to 30V and should be able to handle it?