M564 H0 is your friend. Just put it somewhere in your config.g

this should be possible by using the layer change gcode functionality provided by, e.g. slic3r. Just add your stepper, define it as an additional, non extruder axis (UVWABC) and move the axis in your layer change code.

If your slicer does not support this you may be able to insert the move commands by searching for the comments inserted by your slicer (e.g. ";layer 3") and adding the move commands there.

In the docs, the section about M917 states

Some motor drivers (e.g. TMC2660)

but the TMC2660 does not support the standstill motor current reduction as evident here:

https://github.com/dc42/RepRapFirmware/blob/v2-dev/src/Movement/StepperDrivers/TMC2660.cpp#L896

This should be changed to avoid confusion.

edit: Also the docstring at the top of the TMC22xx files read TMC2660.cpp and ExternalDrivers.h respectively

@Phaedrux my idea was to keep the orignal functionality of S3 if no timeout is specified, and allow to the dialogue to time out on its own if a non-zero timeout is passed via the gcode. That way we could avoid having an extra type.

@dc42 I was not aware of these complications. If this is too tricky to implement you can safely ignore this request of course.

I tried out the message boxes today for the first time. On my printer, I use a long gantry leveling procedure that only needs to run for the first print of the day (as motors don't get deactivated in my config).

I used the M291 S3 message box to ask the user whether they want to execute the gantry leveling or not. If the user presses ok, the leveling is executed, if he presses cancel, the print is resumed without the leveling.

I would like to add a timeout and a default action to this message box. I.e. if the user does not press ok or cancel after 10 seconds, the firmware will act as if the user pressed "ok" and execute the gantry leveling. This will avoid times where I forget about the message box which would leave the printer idle for long periods of time.

Would this be possible to add?

Thanks in advance!

FH

I had hoped the drivers would reset to some default state that was usable, but your reply confirmed that this is most likely not the case. Thanks for your reply!

@dc42 you as a seasoned firmware dev for TMC2660, can they only be used after they have been configured (to some degree) ? I (think) I have proper signals on ENN, STEP and DIR but the drivers are not moving at all.

this should be possible by using the layer change gcode functionality provided by, e.g. slic3r. Just add your stepper, define it as an additional, non extruder axis (UVWABC) and move the axis in your layer change code.

If your slicer does not support this you may be able to insert the move commands by searching for the comments inserted by your slicer (e.g. ";layer 3") and adding the move commands there.

Hello everyone,
I am starting a small coding project using my duet wifi and intended to connect a J-Link to the JTAG port of the duet wifi to do some debugging.

I'm using a Duet 2 Wifi v1.02

Looking through the schematic I found that the pullups for the JTAG lines are not populated on the production boards, and also that one of the JTAG pins is reassigned to do VSSA sensing.

My PCB and schematic knowledge is limited, do I need to make any changes to the board to be able to use a JTAG probe with it? I imagine I'll need those pullup resistors, but I'm also worried about the VSSA sensing bit (as I understand VSSA will be near ground level) and don't want to fry anything.

If you can spare the time, I'd appreciate some guidance.

Bests,

aMpeX

edit: After doing some more digging I found that TCK(VSSA sensing pin) is also fine with a pull-down so my current state of knowledge is that I'll have to add the two pull-ups for TMS (R52)and TDI (R36) and MUST NOT ADD the pullup for TCK (R49) if I want to ensure stable JTAG operation, correct? Also, I imagine the SG_TST signal will interfere with TDO if I try to do stallguard stuff whilst JTAG debugging.

M564 H0 is your friend. Just put it somewhere in your config.g

true, but wouldn't that also require a separate M584 call everytime I want to jog a different axis?

right now I'm using a workflow like

M584 ... (set up all four pairs with overlapping drive assignments)
G0 FRONT_PAIR 
G0 RIGHT_PAIR 
G0 REAR_PAIR
M584 ... (restore drive mapping for normal operation)
<normal operation>

If I understand correctly, your suggestion would require to change this to:

M584 ... (set up mapping for FRONT_PAIR movement)
G0 FRONT_PAIR
M584 ... (set up mapping for RIGHT_PAIR movement)
G0 RIGHT_PAIR
M584 ... (set up mapping for REAR_PAIR movement)
G0 REAR_PAIR
M584 ... (restore drive mapping for normal operation)
<normal operation>

@dc42 thanks for the swift response. Some input regarding the second bullet of your second list point:

As I mentioned, I use a quad-z setup on my printer to lift my gantry. When powering off the printer, the gantry drops by inequal amounts (due to unbalanced weights and print head position during power down) which is why I have been using drive remapping to temporarily create a (FRONT_PAIR, LEFT_PAIR, REAR_PAIR, RIGHT_PAIR) driver mapping to bring the gantry into sufficient alignment before performing precise leveling using G32.

According to your description, this will not be possible anymore after you make those changes, since one driver can then only be mapped to one axis (my example requires one driver to be assigned to two axis simultaneously). I am not sure if this is the way to go as there may be some upcoming machines that make use of the fact that two axis can share a driver.