I started working on this - and experimented with the coupler; Interestingly when I put the DC42 stall detect code BUT changed the C-coupler stepper settings to - microstepping: 8, Interpolation - Off - it worked fine
My settings (and it works) Code: config.g M350 C8 I0 ; Configure microstepping for tool lock mechanism M915 C S5 F0 H200 R4700 ; Coupler Code: homec.g ; homec.g ; called to home the C axis (coupler) G91 M400 ;M913 C60 ; XY MOTORS TO 60% CURRENT ;G1 H2 C30 F5000 ;M400 M913 C60 ; XY MOTORS TO 60% CURRENT G1 H2 C-1000 F10000 G92 C-125 G90 M913 C100 ; XY MOTORS TO 100% CURRENT G1 C0 F10000 ;Open Coupler M98 P"/macros/Coupler - Unlock"
Now, i'm setting up the rPI - and because the duet2 RR3 fw works - will be moving all of my setup to duet3 Looking to optimize the setup for - quality (slow speed printing) - silence (slow speed printing + stealthChop2) After that it will be time to look for efficient but quiet fans
How are you using the Pi? I've got Octopis driving both of my Prusa Mk3s. DuetWebControl is great, but it has one big disadvantage: I can't talk to it when the printer is powered off... My general flow is often to upload to the Octopi (always on) from downstairs from my mac, then wander upstairs, turn on the printer, and do all the control from the web.
You can if you provide 5V power to the Duet through the connector provided, or through the USB connector.
I tried this like many other "random" settings. But It didnt work on my side. Now I started reading this at page 9/10: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2660_datasheet.pdf But I still dont have a clue where to start. Maybe our mechanical load within the Coupler is much different. Even when I set this S-Value (-64..64) to the outer limits I dont see a change.
I thought it might but it does seem to work fine so I've left it as David configured for the time being. I should probably switch to stall detection at some point but I'm still using the crash homing - It seems to be quicker with David's setup compared with the original E3D configuration. I've not tried it myself but I think there's a jumper to change when you're using an external 5V source via the connector? Maybe the C axis motor is simply too small to take advantage of stall detection - Maybe any inconsistency of the position of the C axis gears or alignment of the bearings makes enough binding to trip stall guard. Looking over the documentation, I do wonder if it could instead be used on the extruder. @dc42: StallGuard2, once calibrated, is able to output the load angle of the stepper motor. For a Hemera with its 1.8 degree stepper motor, the load angle can result in a displacement of as much as 0.352mm of filament in either direction. If the load angle is known by the Duet controller, perhaps the position can be offset to correct the load angle? Field oriented control is better of course and I still think that the TMC4671 could be a good option for that, but in the meantime perhaps it could improve extrusion for existing setups.
Thanks for that! When in doubt, RTFM: https://duet3d.dozuki.com/Wiki/Power_Wiring It looks like it takes power from an ATX connecter, and as mentioned later, there is a jumper at all. I'll see if I have a spare ATX cable around to scavenge. The next interesting step would be to add another relay (between the power switch and the main PSU), controlling it with PS_ON and M80/M81. Paul
In case anybody's using the middle of the bed as the origin, I've adjusted the Z offset script. (Attached) I'm using the centre of the bed as the origin for the setup and measurement, but for the main print I'm using a secondary coordinate system: Code: G10 L2 P2 X-150 Y-100 ; Setup the second coordinate system - I also have this defined in my config.g G54 ; Use the main (Centre origin) coordinate system G55 ; Use the second (Offset) coordinate system Also here's an easier way of calculating the new Z offset without having to mess around with the negative signs: Code: {New Z Offset} = {Old Z Offset} - (1 - {Probe Height}) E.g: Code: G10 P0 X-9 Y39 Z-5 ; Old ; -4.931 = -5 - (1 - 1.069) G10 P0 X-9 Y39 Z-4.931 ; New As an aside I've noticed then when homing the Y axis, if the X carriage is over to either side, the belt across the gantry resonates and the motor does not stall. I think my next thing to print are some proper endstop switch mounts.
I saw such a behaviour too but was not able to investigate it any further. I had this when I dropped the currents to 1,8A instead of 2A, then I did reset the settings change to 2A. But I think/hope that 1,8A are not too low. Thanks for the idea, I will have a close look at this and maybe drive X to the center to home Y in future. Then I see if the problem still persists using lower stepper currents.
Looking at the config.g code, can someone explain to me when using R915...the RRF documentation indicates the R value should be 0,1,2 or 3 and defines the action taken when a stall is detected.... yet in config we have R4700? What does that mean?
I looked that up once: Firmware RRF2: https://github.com/dc42/RepRapFirmw...69dc830654460d08/src/GCodes/GCodes2.cpp#L4322 -> https://github.com/dc42/RepRapFirmw...63b16b69dc830654460d08/src/Platform.cpp#L4699 So we have the same behaviour on R0 as on any other number than 1,2,3 I see the same in Firmwere RRF3 https://github.com/dc42/RepRapFirmw...a78fa91b27755de3e125d2/src/Platform.cpp#L4014 Greetings
Here is an updated set of TC files for RRF 3.01beta, with corrections to prime.g and stop.g. X0 Y0 is at the centre of the bed.
@dc42 you did set the current for the coupler to 500mA. Greg set it to 400mA only. https://github.com/e3donline/RepRap...1a874f5e7f9f74ddc88866fae49a/sys/config.g#L49 Does this work stable (and within temperature specs)? Did you as well see lost C-steps when coupling at 400mA? I think I once saw that @Greg Holloway posted some datasheet of the couplers stepper. [delete] But I was unable to find it again.[/delete] Background: I experienced that without grease the coupling will not work at 400mA. With grease it is normally ok, but sometimes I still get a slight loss of steps when coupling or uncoupling one of my tools. I risk dropping tools because of this. So for now I always raise the current within the "Lock" and "Unlock" macro and drop the current again at the end of the macros. I guess could go to 600mA for this one second. But 400 to 500mA are +20% already. Edit: There it is! https://e3d-online.dozuki.com/c/ToolChanger_and_Motion_System_Datasheets -> https://e3d-online.dozuki.com/Document/rHGYlVFPjvVugPyy/Toolchanger-ToolHead-Stepper-M.pdf -> 400mA default rms current
Thank you, that helped alot! I put it to 600mA (only at lock and unlock time). The normal current, when it is not moving, will stay at 400mA. Locking and unlocking at 400mA sometimes failed again at another comparison test. Using 600mA seems to be perfect stable until I write something other here.
There is now Duet3D github repository for machine configuration files at https://github.com/Duet3D/RRF-machine-config-files, so I have put my RRF 3.01 TC configuration files files there. Other contributions to that repository are welcomed.
@dc42 && https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Variable_declaration Is the declaration of simple numeric constants or variables still on the roadmap? However this would be very helpfull but as working hack I can get alot of 'variables' from the printers https://duet3d.dozuki.com/Wiki/Object_Model_of_RepRapFirmware Object model. (My goal is to have a more parametric set of instructions. In case I now decide to implement a Y-endstop this will shift so many coordinates that I will forget at least one.)
Yes it's on the roadmap, along with parameters to macros in M98 calls. But neither will be implemented in release 3.01.
