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.
Hi,
I recently played around with dynamically mapping around my 4-drive z axis to give me individual control over the steppers. I ran into two things:
The documentation for G92 states "A G92 without coordinates will reset all axes to zero." This is not true for the current stable release (1.21) as far as I can tell from the behavior and the source code on github.
When doing drive mapping, all sorts of funky things happened to me when remapping the 4 drives mapped to the z axis back and forth (i.e., I go back and forth between having 4 drivers assigned to Z and then having them assigned to U V W A). This behavior included some of the steppers trying to travel huge distances when I swapped to the UVWA configuration, made small adjustments, swapped back to quad-Z and then tried to perform a small movement. I suspect this was due to the fact that I did not properly "unmap" the Z axis drivers, which caused the drivers to be assigned to multiple axis and doing all kinds of weird stuff.
Here's a braindump of suggestions regarding point 2:
Allow to unmap a certain axis (a workaround to this is currently to map the axis to an unused driver, which may be infeasible for a setup that uses all drivers) by being able to pass a "-1" as the drive number. This axis then does not track any changes made to the drivers that were previously assigned to it.
Unmap all axis that are not mentioned in the M584 call (this adds some overhead because one has to mention i.e. the X and Y axis everytime even if the mapping doesn't change.
Reset all axis that have received new mappings to zero upon remapping, as well as the underlying movement housekeeping to avoid that a newly created drive mapping carries any previous state into the motion system.
Thanks for your consideration. If the issues I am seing are due to me not using the provided facilities correctly please forgive me.
FHM
DWC already has this via the 'print another' button, however it is only possible because DWC keeps track of the last printed file on its own.
This way, one can use a macro or (maybe down the road) a button in PanelDue to accomplish the same thing.
M32 R1
or
M32 R
reprints the last file. Only works if a file has been printed since poweron and throws an error otherwise. Or maybe put it in a separate Gcode altogether since the spec of M32 does not take parameters apparently (to avoid collisions with files that are named "R1" or "R").
just to be sure, binary concatenation has to be used right?
the matching windows command I found to do that is:
[[language]]
copy /b file1+file2+file3 targetfile
Thanks for sharing the bmp2c version! Am I correct in the assumption that we need the -b and -c parameters to generate the binary image and then simply concatenate the bitstreams of the nologo fw with that file?
I have stumbled across the same problem with my CoreXY machine. The operation is mostly quiet but there are certain speed where the whole printer emits loud noises.
The only way to fix it is either slowing down way below what the printer is capable of (which defeats the purpose of having a nice printer) or dial up the voltage all the way, which causes my steppers and drivers to almost burn up.
Is there anything that can be done from the software side?
I can provide video if necessary, the resonances occur mostly on moves where both motors have to contribute inequal amounts of speed.
@djdemond that's how I'm doing it now. I just wanted to confirm that I am not running into some other issue
@dc42 thanks for clearing that up. I hope others with the same question as mine will find this explanation as well.
Hi, I have recently switched from a pure probe setup to a combination of
I am using switch types P4 for the inductive Probe and P7 for the switch. My understanding was that by using
G31 T7 and
G31 T4
I could set offsets for each probe individually and then would merely have to switch between the two probing systems at appropriate times using M558,
however it seems that I need to pass the appropriate G31 calls everytime as well. The Z Probe article on the wiki does not include the latest
probe types and the doc for G31 mentions that "Separate G31 parameters may be defined for different probe types (i.e. 0+4 for switches, 1+2 for IR probes and 3 for alternative sensors)"
Does this mean when I call
G31 T4 ….
and then
G31 T7 ....
i am essentially overwriting the parameters even though the T parameter is different?
I'm not sure if the steppers can be configured beyond their rated amperage. I would suggest you invest in external stepper drivers instead. This is probably going to be cheaper than cooking up a watercooling solution for the TMCs, too.
does your router support VPN? if so thats your answer. Alternatively you can set up a nginx/apache server with password protection on a raspberry pi and set up routing through that.