@Ozzzzzzy Most of my printing is of gcode that I construct with my own custom code generating software. Hand-coded, if you like.

I used to use arcs extensively when my Duet-equipped Voron was my primary production printer, but I bought a Prusa MK4 and found to my horror that the firmware at that time did not properly support arcs! I changed all of my code to eliminate arcs. Finally, a long time after my prompting* Prusa added arc support to the firmware but my experiments suggested that arcs caused gave stuttering movements with blobs and zits and so I did not go back to arcs.

*I suspect that my questions and complaints did nothing to accelerate the incorporation of arcs into the firmware, as it was when PrusaSlicer integrated an ArcWelder-like feature that it was done.

@droftarts @Phaedrux , I think it was both the error with the quotatiion mark and also the I parameter I had in the 587. I'm jusy happy you guys help me solve it. Thanks again.

@fcwilt I think the firmware was just ignoring those lines and setting the default for each driver when the axes are setup with M584, but I’ll ask @dc42 why it didn’t trigger an error message.

I tend to call these mistakes ‘Gcode blindness’ and I’m quite prone to them, too!

Ian

@Phaedrux Thanks for that info. I thought I would have to flag posts and user.

@droftarts Thank you for the heads-up — you’re absolutely right.

I had only defined Tool 0 so far during initial setup and completely forgot to add Tool 1 with the XU mapping. Your reminder pointed me in exactly the right direction. I’ve now added the second tool definition using M563 P1 D1 H1 XU, and everything is working perfectly.

Really appreciate you taking the time to check and guide me — thanks again!

@JC42 It looks like Simplify3D is controlling the fans individually, using M106 S# P# commands, and seems to leave some of them on, at varying speeds. eg.

... ; process T1-PETG-Print_T2-PLA-Support M106 S255 P0 G4 P500 M106 S101 P0 M106 S255 P1 M106 S255 P2 G4 P500 M106 S101 P2 M106 S101 P3 M106 S255 P4 G4 P500 M106 S101 P4 T1 ...

Ideally, you want it to output M106 S# commands, without the P# parameter. Then only the fan associated with the active tool will be controlled, and you can turn the fan off in the tool change macro. I'm not familiar with Simplify3D on how to achieve this, though.

Ian

@Michael-P said in SBC connection issues:

connection to the Raspberry Pi via IP address

You should go into your router control panel and set the Pi to a reserved address so that it doesn't change.

@dc42 Will do, thanks.

Chris Cosentino
Cosentino Engineering

@dc42 Ok thanks - Yes my printer has separate Z adjustments for each print head - have raised enhancement request.

Referenced Multiple Motion System Mesh Adjustment and Z hopping in the same request - but could separate them out if that would be better.
https://github.com/Duet3D/RepRapFirmware/issues/1106

ukdavewood created this issue in Duet3D/RepRapFirmware open [FeatureRequest]: Multiple Motion System - Micro Z Adjustment and Z Hopping #1106

@phoenix

That's why we are here!

If we cannot help, we can mess things up in style. 🤠

Frederick

@dc42 Again, thanks! I can confirm that this fixes my probing issue.

@scooby The PanelDue only shows temperatures related to heaters, ie nozzles, beds and chambers. If your bed temperature sensor isn't used by a heater (ie usually the bed heater), it will show on the 'Extras' tab in DWC only. You can define a 'dummy' heater, that uses an unused output, and map the temperature sensor to that, and define it as a bed or chamber. See https://docs.duet3d.com/User_manual/Connecting_hardware/Heaters_bed#configuring-a-bed-heater

Ian

@dc42 That's an interesting idea. I do have io3 available on each board that I could put to some use.

@rkutun theres a CAN out connection on the 3HC. Use that.
CAN-FD is a bus so its just one continuous run

What do you want it to do that it isn't doing now? It looks like a passable start to tweak.

@f-riccardo check the directions in which the axes move. Looking at the front of the printer, +X movement should be to the right and +Y should be away from you.

If the axes are moving in the correct directions but prints come out mirrored, check your slicer settings, because some slicers have an option to mirror prints.

@luc M566 is not relevant here because RRF does not use jerk what starting a move from standstill, or when ending a move at standstill.

@jltx You can access logs using journalctl (e.g. journalctl -u duetcontrolserver -e) but I doubt anything else will show up there. Do you have any other applications running on your SBC? The message you got means something blocked the main process on the SBC from performing a data transfer.