Posts made by garlicbread

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

I think with edm (referenced in the link) you'd only need to slow or reverse the feedrate of the current g-code line instead of jumping back to previous lines in the g-code.

So for example there would be a g-code to move downwards as a certain speed. The edm machine provides feedback to the duet board ether in the form of i2c or an analogue voltage to say your going too fast slow down, or you need to backup a bit then start going forward again within the current line of g-code.

I put a bit of detail here

• https://forum.duet3d.com/topic/9561/edm-reverse-feed-rate

Hi
I was wondering if there might be any plans in the future for EDM
I think this question has been asked before on the forums

Typically you have a spark jumping from an electrode to the work piece to erode it.
The device that generates the spark is able to detect if the electrode is too close based on the current flow / voltage drop
In some cases a reverse of the feed rate / speed is needed to back the electrode off if it's too close.

There's been a video recently from Applied Science that goes into a bit more detail

• https://www.youtube.com/watch?v=rpHYBz7ToII

It turns out the only controllers at the moment that support reverse feedrate are the dynomotion boards
Due to they're ability to be programmed to allow for live reverse feedrate / speed during operation via feedback, not just a slow / stop of the feedrate

• https://dynomotion.com/
• https://baxedm.com/
• https://baxedm.com/wp-content/uploads/2019/01/BX17-Manual-Rev03.pdf

I think the feedback is provided to the motion control via an analogue voltage from 0 - 2V (in the case of the BX17)
which is then amplified to 0 - 10V using 5x gain on the controller
This leads to

• Region 1: Voltage > 9.5V No Arc
• Region 2: 2.0V < Voltage < 9.5V Arcing is taking place
• Region 3: Voltage < 2.0V Short circuit

I don't plan on using the BX17 myself but I am thinking of building my own EDM spark generator at some point.
It'd be interesting to see if there could be a feature added in at some point to live adjust the feedrate based on perhaps I2C or an analogue input

@dc42 That's okay for the latest version of the firmware, but if you've got an older version of the firmware installed, doesn't the web interface need to match?

There doesn't seem to be any tags on the T3P3 one

aha I just realised it's in DuetWebControl-1.21.1.zip

Just to add to this there's also this as a starting point
https://github.com/T3P3/Duet/tree/master/Duet2/SD Card Contents

Although Im guessing it's probably best to make sure the www directory and the sys/DuetWiFiServer.bin file matches that of the firmware version reported with M115

so for example for the www directory

for 2.02
https://github.com/dc42/RepRapFirmware/tree/2.02/SD-image/www

for 1.21
https://github.com/dc42/RepRapFirmware/tree/1.21/SD-image/www

for the wifi bin, that can be sourced from the releases page
https://github.com/dc42/RepRapFirmware/releases

It sounds like using 2.4A / 85% of the rated current for the motor is best anyways so I'll be using that.

okay thanks, in that case I'll run them at 2.4

Hi,
I'm going to be setting up a couple of Ox CNC's with new Duet wifi boards (1.04)
I was wondering about the max current limiting on the stepper drivers.

The stepper drivers in question are basically 2.8A per Phase Nema 23's
https://ooznest.co.uk/product/nema23-stepper-motors/

From the looks of things the max you can go within config.g is 2.4A
But the stepper driver ic's support 2.8A

• Is it the case that you can do 2.8A if you add active cooling (fan's / heatsinks) to the stepper IC's?
• Also is there some special flag you need to switch over to allow for 2.8A (i.e. a recompile of the firmware)

Hi,
I recently updated the firmware from 2.01 to 2.02
on a Duet wifi 1.04 board

• Firmware: 2.02(RTOS) (2018-12-24b1)
• WiFi Server Version: 1.21
• Web Interface Version: 1.22.6

I noticed that my hotend fan wasn't running
it turns out there may be a bug when using the C option to name a fan with the M106 command

It used to be like this in the config

M106 P0 S0 I0 F31 H-1 B1 CPartFan1                             ; Used to cool the part
M106 P2 S0 I0 F31 H1 L1 T60 CHotendFan1                          ; Used to cool the hotend

However I noticed when running this at the console I'd get spurious errors like this
Error: M106: Logical pin H0 is not available to use for fan 2
It was almost as if the name of the fan couldn't exceed 7 characters for fan 2, or 1 character for fan 0

Removing the Fan naming fixed the problem

M106 P0 S0 I0 F31 H-1 B1                             ; Used to cool the part
M106 P2 S0 I0 F31 H1 L1 T60                          ; Used to cool the hotend

Sorry for raising this on github originally btw (I should have read the Readme).

thanks for the info

I've noticed the latest firmware now has 12864 display support
with custom menu's which is cool

• https://forum.duet3d.com/topic/8014/12864-display-sd-print-subfolder-screen-update
• https://duet3d.dozuki.com/Wiki/Duet_2_Maestro_12864_display_menu_system

I have a Duet2 Wifi 1.04 and I've got one of those cheap Smart Controller 12864 displays from amazon
But I'm assuming you can't just connect one of those displays directly to the board though
since level shifting between 5V / 3.3V may be required

or am I wong and you can just wire it directly in place?
are there any details on the wiring layout, and does the duet have 5v tolerant inputs?