Topics created by blt3dp

@droftarts

I actually ended up reimaging the original sd card and doing the same manual recreation of the config files and it's been fine so far. I think more permissions or something when doing the image/sftp backup/restore originally.

Could this have been the feedrate too low? Not sure where I got F300 from, but I bumped it to 1200 and it seems to be working.

Looks like it only happens when I reload the page.

@blt3dp said in RRF 3.5 beta 4 not respecting axis limits:

I guess my point would be, say a company wanted to use Duets in their delta printers sold commercially to end users, yet wanted to prevent any scenario like I described above, shouldn’t that be possible?

Normal moves beyond the bed radius (M665 B parameter) will be prevented unless you use M564. G30 probing moves outside the bed radius are permitted because they are sometimes needed for delta calibration.

@dc42

It's fixed, turned out it was my cabling. I must have tweaked it somehow when I installed the filament runout sensor. Crimped a whole new set for the 8 pin and is all good now.

Assuming the bed heater is heater zero, If you change the M116 line to be:

if heat.heaters[0].current < 60 M116

it will only do the M116 if the current temperature is less than 60.

Note that the M116 needs to be indented by some spaces (I use four), and the next line must not be indented - RRF uses indents to delimit loops, conditional blocks etc.

I'd actually be inclined to make it

if heat.heaters[0].current < heat.heaters[0].standby M116

then it will do the M116 if the current temperature is less than whatever the heater is set to (as standby), so if you change the '60' value in future it will not need changing in multiple places in the file.

@deckingman I reread it with a clearer mind. Now I understand the tool and heater are separate. M568 A parameter can activate the heater on a tool to whichever state, but not select it for printing. I added the proper T0 P0 to start gcode and T-1 P0 to the end. Everything is working as I'd like, thanks.

@blt3dp said in Voron-0 Display to Duet Mini 5+:

@wayneosdias @jay_s_uk, I think we might be talking about different BTT screens. The one I'm using successfully, after tweaking the menu files to my liking is this one.

https://biqu.equipment/products/bigtreetech-mini12864-v1-0-lcd-screen-rgb-backlight-mini-display-supports-marlin-diy-for-skr-3d-printer-part

It's basically a standard non touch screen, 12864 display using a ST7567 controller

@R4ffers, thanks, looks like I'll be doing the upgrade to a v0.2, I'll probably tweak something to fit afterwards.

I was just commenting that the TFTs they do aren't well supported.

Their 12864s are fine

Just coming back around to this, I've found it's the fans spec'd for the v0, which are gdstime 3010. They're known to die after being exposed to the heat from the chamber % hotend.

https://github.com/VoronDesign/Voron-0/issues/121

I've swapped them out the the Winsinn fans suggested and they seem to be fine now.

bmgoncu created this issue in VoronDesign/Voron-0 open 30mm blower fans sensitive to the hotend heat and stops working #121

@blt3dp

Well, LOL. I ended up cutting the leadscrew off of the "bad" motor and attached it to the other motor I had tested with. It's completely silent now.

@blt3dp yes that one is suitable. They are also widely available on eBay. The one we use is a compatible connector made by Wurth Electronics.

@blt3dp said in Duet 3 6HC 0.6 Mac Address?:

I think because I’m using a nano router to bridge the Duet 3 to wireless that it’s possible the nano router is doing some form of masking/wrapping the packets.

mac addresses is a layer 2 thing, while ip addresses is a layer 3 thing - if your wireless bridge is operating on layer 2 layer 3 you will not see the actual duet 3 mac address. so given available information that is the most likely explanation.

easiest way to verify is a direct connection to the duet.

@blt3dp That's a good price. They have really come down a lot.

@blt3dp said in Duet 3 w/Raspberry Pi - Failed to delete, JSON Parse Error:

I'm guessing I can't do that wile a job is running?

I was curious so I uploaded 2.0.7 during a print and it worked fine.

@droftarts said in Hemera settings for Reprap Firmware?:

@Eran898 said in Hemera settings for Reprap Firmware?:

M587 S"aaaa" P"bbbbbbbb" ; Configure access point. You can delete this line once connected

You should delete this line from your config.g, as it gets written to the Wifi module each time config.g is run. Not ideal for flash memory! See: https://duet3d.dozuki.com/Wiki/Gcode#Section_M587_Add_WiFi_host_network_to_remembered_list_or_list_remembered_networks

Important! Do not use M587 within config.g. As well as being a security hazard, writing the access point parameters to WiFi chip every time you start the Duet may eventually wear out the flash memory. Also, the wifi module does not get enabled until the end of running config.g. It is better to use a macro to send M587 (source: https://forum.duet3d.com/post/42798)

Ian

Thanks for the info didn't knew that!.
So no one using the hemera on direct? haha.
Please if someone using it would be great just to see what numbers you are using

@chrishamm said in PrusaSlicer cannot upload to DWC 2.04/RRF 3:

I see no reason to send a PR to PrusaSlicer before that part is complete.

@chrishamm, while you interacting with Prusa, can you also ask to increase the PrusaSlicer's timeout for Duet's uploads? Last time I checked it was 10 secs which cause the upload to fail on large prints. A minute or two should be fine.

(my upload speed from DWC is ~200KB/s. Using RRF 2)

@Veti said in Duet 3 Heated Bed Faulting:

you can not. that is just a warning.

I thought that might be the case, no worries.

@deckingman good for you!