Yep that fixed it my bad for forgetting to update the web interface

Just like to say thanks to dc42 (I think Dave) and the other firmware developers for all they're hard work.

I've recently managed to get my Anycubic Kossel Delta to work with the new duet board. It took a little while to figure out but I've got a lot more confidence in the bed leveling now than the original Marlin board.

I plan on writing up some docs on my blog at some point with a more step by step guides to try and simplify the setup process, and list some of the things / quirks I've noticed.

Thanks very much this is much appreciated.
I've got several cnc's lined up this will be useful for, including ones at our hackspace.

I think there was some suggestion it might show up in 3.5, but I'm not seeing in the latest changelog of the 3.5.0 beta

I'm kinda hoping it shows up in one of the future 3.5 versions

Yep that fixed it my bad for forgetting to update the web interface

Ok I think I was taking for granted that Duet2CombinedFirmware.bin also contained the web interface part.

I'm noticing my web interface is on 3.2.2

I can confirm that the Heightmap file was deleted then regenerated via G29 btw. But I'll try upping the web interface first.

@phaedrux https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.2rc1

Hi,
I recently updated to version 3.4.2RC1 (I think from 3.2) on a Duet Wifi2
I was going to go for 3.4.1 stable but I was a little worried about the mention of config.g disapearing in the change logs

It looks like the web viewer has problems viewing the heightmap.csv file

Contents of the file are:

0:/sys/anycubic_delta/heightmap.csv

RepRapFirmware height map file v2 generated at 2022-07-31 22:27, min error -0.626, max error 0.220, mean -0.190, deviation 0.234
axis0,axis1,min0,max0,min1,max1,radius,spacing0,spacing1,num0,num1
X,Y,-100.00,100.10,-100.00,100.10,110.00,20.00,20.00,11,11
      0,      0,      0, -0.598, -0.613, -0.585, -0.502, -0.383,      0,      0,      0
      0,      0, -0.626, -0.573, -0.608, -0.547, -0.464, -0.396, -0.415,      0,      0
      0, -0.554, -0.585, -0.532, -0.556, -0.486, -0.412, -0.375, -0.394, -0.346,      0
 -0.455, -0.452, -0.444, -0.396, -0.370, -0.372, -0.357, -0.322, -0.309, -0.315, -0.278
 -0.295, -0.347, -0.350, -0.306, -0.284, -0.329, -0.253, -0.271, -0.264, -0.234, -0.270
 -0.198, -0.125, -0.155, -0.189, -0.162, -0.127, -0.135, -0.189, -0.225, -0.238, -0.197
 -0.064, -0.113, -0.122, -0.107, -0.047, -0.045, -0.119, -0.138, -0.102, -0.118, -0.123
  0.075,  0.011,  0.058,  0.033,  0.047,  0.026, -0.043, -0.070, -0.025, -0.074, -0.041
      0,  0.152,  0.118,  0.065,  0.099,  0.051,  0.063,  0.011,  0.023,  0.044,      0
      0,      0,  0.158,  0.122,  0.112,  0.144,  0.100,  0.101,  0.114,      0,      0
      0,      0,      0,  0.220,  0.177,  0.201,  0.166,  0.165,      0,      0,      0

I tried deleting the file then re-running G29 but it still seems to be the same.
Maybe it's related to me using a delta, or perhaps because I'm using M505 P"anycubic_delta" I'm not sure

The Statistics seems to show up ok though

Statistics
Number of points: 97
Probing radius: 110 mm
Probe area: 380.1 cm²
Maximum deviations: -0.626 / 0.220 mm
Mean error: -0.190 mm
RMS error: 0.234 mm

So I'm wondering if it could be a glitch in the web viewer part

I understand what you're saying but I don't think it's a loose wire.
The reason being I'd been using my printer all day running calibration prints, then towards the end of the day it suddenly started happening with the motors repeatedly, even after a power cycle.

I noticed just leaving it over night then trying to do a homing cycle (delta printer) worked fine again.
The motors are fairly small nema 17's set to a current of 1A

I did notice the MCU temperature was up to around 40 something degrees on the web UI when it was failing at the time (maybe 42 or 45)
(for info I had calibrated the MCU temperature long before hand, since I remember the docs mentioning that's needed to get an accurate reading)

I think it's my own fault for having the control board too close to the heated bed to be honest.

I noticed after a while use my 3d printer I was getting the error
"motor phase A may be disconnected reported by driver(s) 0 1 2"
Then I'd end up with a large grumbing noise coming from the steppers as it was trying to home

If I then left it for a while then came back to it, everything would be fine.

I then stumbled across this thread
https://forum.duet3d.com/topic/10233/motor-phase-a-may-be-disconnected-reported-by-driver-s-0-1-2

I think I may have figured out the cause, I think it may be due to overheating on the duet board some place
ether the stepper drivers or main mcu, since I don't yet have active cooling over the board
and it's close to the heated bed.
I figured I'd just post this here in case anyone else was running into the same problem

One thing to add
I've been hunting around for a small cheap CAN-FD breakout board that can be used with an existing microcontroller (since most of my existing controller boards don't have CAN-FD built in, since it's a bit new)

I discovered this which might be of interest to others for playing around with
https://e-radionica.com/en/can-breakout-eng.html
SPI to CAN-FD I think using the MCP2518FD and a transceiver.

Hi,
I'm currently looking at moving over to the Duet 3 for my CNC
One of the things that's caught my eye is the use of CAN-FD
This seems like a much cheaper / easier method for motion control instead of Ethercat for example, which has licencing implications.

Based on what I can see of the protocol - https://github.com/Duet3D/CANlib/blob/master/doc/Duet 3 CAN protocol.odt
I think at present it doesn't take cable propagation time into account
in that I don't think it measures the time taken to send a message to a client board / back again (like ethercat does)
I think instead it just sends a clock sync signal down the line to resync the attached board every now and again.
I'd guess this wouldn't make that much of a difference with short cable runs anyway, but I was just curious to know if this is true.

I've noticed with the Duet3 you can use an Rpi 3 / 4 etc for the wifi frontend.
One of the things I'm considering at the moment is making my own CAN boards to attach to the Duet, such as one that allows connectivity to a VFD's RS485 port
for sending spindle speed or setting / reading VFD paramters.
Or other heads / boards such as the output from a Blu-Ray Recorder laser etc

Is it or will it be possible to create custom G-Code messages (or sub messages) to send custom CAN protocol message via the use of the Rpi at some point?
There was some mention about user defined messages here I think https://forum.duet3d.com/topic/18855/can-development-possibilities/5?_=1615664485490

Is it also possible to override default G-Codes at the Rpi level for things like setting spindle speed etc? (for example runs a python script which signals the duet to send a CAN-FD message)

Many Thanks