@Corexy said in Issues with print quality, wall surface rough.: blatantly blowing on the heat block, and you've got a silicone cover on it as well. Sure you could certainly have a better fan shroud, but I don't think it's a major cause of any problems. I'd stick with the 40x10 blowers myself, but I tend to use as little fan as possible in my prints. I generally go with 10-20% fan on materials like PLA/PETG, and with the exception of bridging never go over 60%. It would be nice to print some sort of U I notice from the pictures you are printing on a magnetic print surface. Is it possible that the surface is not holding down tightly, and the print is wobbling? This really, really looks like simple mechanical wobble somewhere. If the temperature regulation isn't very good, especially, the plate could be flexing vertically (popping up and down), resulting in very uneven spacing of the 'z' steps and the blobby layers.

Thanks for your help.

@oliof OK thanks. I will try today. have you seen the photo of my map? what do you think should not calibrate well? I saw worse maps with good results in the end 😭😭

@dc42 Ok .. good that we finally found the bug! Too bad it is not so easy to solve now ... Ok I will try to put everything back to the old SETUP and hope we can find a quick solution here ... thank you in advance

@jens55 said in G53 Head positioning on a dual head printer: I have a 2 nozzle cartesian printer that I am setting up for nozzle wiping. The two nozzles are offset from each other by 20 mm in the X direction. I need to move head #1 to X 528 to get it past the wiper and a that point head #2 is at x 548. If I tell the head to go to x 528 then the final position will depend on if nozzle #1 or nozzle #2 is active. The G53 command uses 'machine coordinates' that are not subject to tool offsets but I have no idea how I would use this. Would I simply tell the machine to go to x 528 as in g53 g0 x528 and it would go to the same spot no matter which head is currently active? This seems to be happening but I want to make sure there are no unintended consequences down the road (that seems to happen to me more often then not) Are there any implications down the line that could cause grief/tool crashes? Is there anything else I need to consider? Is there another way of achieving the end result that I have failed to consider? First, you need to decide on where your Head Reference Point (HRP) is. You can choose where to put the HRP. In your case the obvious places are at one of the nozzles, or midway between the two nozzles. On tool changers it may be more appropriate to use the location of the Z probe, because there may be large differences in the offsets of the different tools. Then you need to specify the offset of each nozzle from the HRP using G10, and the offset of the Z probe from the HRP using G30. The limits you specify in M208 are the limits of where the HRP may move to, and also the position of the HRP when the appropriate limit switch is triggered. When you specify a move using G1: If G53 is active (because it appears earlier in the line), you are specifying where you want to move the HRP to If no tool is active, you are specifying where you want to move the HRP to in the current workplace coordinate system; so the current workplace coordinate offsets get subtracted from the coordinates in the G1 command If a tool is active and G53 is not active, you are specifying where you want to move the tool to in the current workplace coordinate system; so the firmware subtracts the current workplace coordinate offsets and the tool offsets from the coordinates in the G1 command In system macro files (pause.g, tool change files, homing files and other files in /sys that are run automatically), behaviour is as above except that workplace coordinate offsets are always ignored. HTH David

should probably connect -Fan to one of the pins that can work with pulseIn() and in the setup() call pinMode(pin, INPUT_PULLUP) for that pin. should be okay to power the Arduino with 5v from the expansion header yeah, not much current needed at all, and the open drain output of the fan will not be damaged by the 5v pull up on the Arduino. (if you were to use a 3.3v arduino you could use a pin on the expansion header and save the fan output for something else)

Duets are not shipped "factory reset"; that would mean its blank, with no firmware due to the nature of the microcontroller used. So Duets have the firmware flashed and SD card populated with a default config on top of a reset state. IF you send M999 P"ERASE" or place a jumper over the erase pins on the board it will be the cloest you get to resetting it - but that also renders it useless until you perform Fallback procedure #3 you probably have to update DuetWebControl on the SD card as well. To reset the WiFi module send M552 S-1 M552 S0 M588 S"*" The only thing you achieve by resetting the board is solving any problems related to not following the instructions given here Section_Special_considerations_for_upgrading_between_particular_firmware_versions so I would perhaps suggesting an alternative approach as there is no going back after you erase the board, except the fallback procedure linked above.

@wieman01 said in Question: Recommendation for mechanical endstops: Hello, I am looking for mechanical endstops that are compatible (I have read the specs regarding current, etc.) with the Duet 2 Wifi. Has anyone got a recommendation by chance? Thank you / wieman01 Omron microswitches are good. Ideally they should be low-current ones with gold-plated contacts, but ordinary ones seem to work well.

Any ideas?

@gt40 said in Duet 3 DCS not starting and unresponsive Duet: December of last year. Thats a while ago, has it worked before now? Diag LED is dimly lit: Does this change momemtarily when you press the reset button on the board? If it was my board, I'd place a jumper on the erase pins for a few seconds to see if that made the board show up as a bossa programming port as described in the docs. But, on the off chance there is a problem with USB (be it cables/computer/duet) and the board actually has the firmware loaded that should be the very last step.

https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands and generally searching for conditional gcode on the forum.

If I am not mistaken, they are rated at 32 or 48V but each to their own. I would never use them for mains voltages unless they were brand name and were spec'd for that use. China imports do not qualify!

I have not experienced PLA hydrolysis (thank God!). I suspect it is because with two nozzles I am either actively printing or have dropped to a standby temperature (130 for PLA). I have only seen it (or something close to it) when I do a 'propane cleaning' of the nozzle.

It does not, see the olm-x_end_stop.gcode I attached to https://forum.duet3d.com/post/164699

https://www.luban3d.com/ It's not quite CAD. More like... post processor? Pre processor?

Please post your config.g. XY stuttering can be caused by using mesh compensation and having a too low Z jerk value which causes the XY to pause to allow time for the Z axis to change height since it's a coordinated move. Increasing the Z axis jerk to at least 60mm/min is usually enough to solve it. If that's not the case, please provide more details.

@Phaedrux Sorry long work days. I unplugged the BLTouch on both side and plugged it back in. Hard reset and now it is working. Sorry it took so long to get back to you guys.

@arhi said in Simplify3D send gcode directly to Duet 2 Maestro?: @dlc60 said in Simplify3D send gcode directly to Duet 2 Maestro?: Wait, scripting in the RRF? I didn't see that. check out for e.g. https://duet3d.dozuki.com/Wiki/Macros#Section_Tool_change There are normally three specified tool change macros (any of which can contain no commands if desired) that execute in this order: Actions to do with the old tool before it is released - macro name: tfreeN.g where N is the tool number; Actions to do with the new tool before it is selected - macro name: tpreN.g where N is the tool number; Actions to do with the new tool after it is selected - macro name: tpostN.g where N is the tool number. So you can have a macro to execute before tool is release, before is selected and after it is selected, same thing for every tool, called automatically, you just make files tfree0.g tfree1.g tfree2.g tpre0.g tpre1.g ... put stuff in ... and enjoy .. so when S3D sends T1 the RRF will execute tfreeX (where X is whatever was before T1) etc etc.. and in this macro files you can use dynamic g-code with loops and conditionals and... https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands That is really useful. I can put the g-code scripts that I use for dual filament prints into these macros and not need to bother with what slicer I am using. Awesome! The scripts that I wrote for S3D and dual filament deliver the goods. CURA scripting is terrible and the outcome seems totally random. I have to try now. Thanks, DLC

If you're actually worried about things getting too hot, simply run the fan any time the power is on- i.e. connect it to the power supply. If the noise concerns you, use a fan that is rated for higher voltage than your system (line or DC). I have a 127mm 208VAC fan blowing against the Duet board whenever the power is on. We have 117VAC line voltage here, so the fan turns slowly and quietly but moves more than enough air to keep things cool. 24VDC fans will usually start and run reliably, slowly, and quietly on 12VDC, or you can install a buck or boost converter with the fan to tweak the voltage to it a little as needed. Converters that can drive fans are very small and dirt-cheap.

@whopping-pochard That sounds right. nevermind.

There is no hard rule for SSID special character support on the router side. Some will let you use pretty much anything, but in general it's probably best to avoid special characters in the SSID. I'll add a note to the M587 command regarding that.

@genseric said in Duex5 not showing in diagnostics: WOW!! Not one single comment. Is this not being seen or has it been put in the 'too hard' basket? We try and reply to every post as quickly as possible. Please allow at least 24 hours for a reply and keep in mind that we're all spread across many time zones.