Hangprinter (v3/v4) + Duet2Wifi + Nema23
-
Dear Duet Community and Duet Developers
First of all, please let me thank you all for all your effort and support!
Right now I'm working on a hangprinter built which could be described as a version 4 HP but with Nema23 instead of ODrives.Background:
Because we are planing to implement a ceramics printing head we decided to go for Nema23 (without smart steppers) instead of Nema17 motors and we had to switch for a 24V support. Knowing of HPv4 and the utilization/possibilities of a Duet 2 board to use the Nema23 as well as Hangprinter support, we decided to use the Duet 2 Wifi.We tried out the hangptinter supportet main Duet RRF as well as Torbjørn's RRF fork with specified binary for hangprinter.
Both firmwares seem to be lacking some support for our setup, though:
Main RRF has newer overall firmware (3.15 at the moment instead of 2.15?) but rather basic considerations of hangprinter needs.
Torbjørn's RRF fork binary and corresponding config.g-file come with specific implementations from experience of earlier HP versions on things like line buildup compensation, spool-radius, spool-/motor-teeth, advantage with double lines, specific parameters in gcode etc. etc. etc.
But it is also primarily written with ODrives in mind.Since we used the on-board TMC2660 drivers (X, Y, Z, E1) and not external drivers or smart steppers, we managed to get the Nema23 working individually in both cases but we still have some questions, we would like to ask:
Does someone here happen to have a similar use case of running Nema motors on a Duet 2 board for a hangprinter built?
(1) What RRFirmware do you use and how have you adjusted your config.g file?
(2) What Firmware would you suggest for our setting (Duet 2 Wifi + Nema23)?
Simple question(s):
(3) How have you mapped your motors to the drivers? (XYZU like suggested by Duet or rather ABCD as in Torbjørn's config.g?)
(4) It confused me, whether it is a problem - e.g. for translation of linear (Cartesian) coordinates (from gcode) into non-linear (e.g. hangprinter, delta-printer) coordinates - having the same naming of motors and axes?Speaking of which:
(5) What routine do you use to generate gcode for your hangprinter (from .stl-file to gcode)?
(6) What slicer or software-combination do you use?Very excited about and very thankful for any reply!
Thanks a lot!
Cheers,
Peter
ps: We also posted an analogue request in the reprap-hangprinter forum :).
-
@peta said in Hangprinter (v3/v4) + Duet2Wifi + Nema23:
whether it is a problem - e.g. for translation of linear (Cartesian) coordinates (from gcode) into non-linear (e.g. hangprinter, delta-printer) coordinates - having the same naming of motors and axes?
The hangprinter is interesting, I wish you success implementing one. I had some discussion on reprap forum how to drive wires, it is an interesting theme.
I can only answer the question above, please check my information in https://forum.duet3d.com/topic/17222/duet3d-3-custom-delta-printer-inconsistant-motor-problems/14?_=1594453426871
To answer your question, the hangprinter, delta, polar, scara, robot ... kinematic all have this special relationship between stepper (ABC...) and worldcoordinates (XYZ), so the firmware need specific methods to calculate them. From ABC to XYZ is called kinematics, from XYZ to ABC is called inverse kinematics. If you want to know whether a firmware supports it good, simply look into their source and you'll see how good the code is. RRF3 hangprinter: https://github.com/Duet3D/RepRapFirmware/blob/v3.02-dev/src/Movement/Kinematics/HangprinterKinematics.cpp
The main calculation is made in Recalc(), the kinematics is made in MotorStepsToCartesian (which calls InverseTransform), the inverse kinematics is made in CartesianToMotorSteps. Looking at the code, it looks like very solid code*).
Looking at the comments, there are a point to improve (Hangprinter homing is not supported), but this is a minor problem imho, because if you created a concrete printer and ask here on the forum to implement it, someone will help adding this functionality.*) with solid code I mean, the algortithms are so clear and the code straight forward, that there is not much room for bugs.
To answer your (5), there is no special code, the gcode files contain the worldcoordinates. They will be converted to printer-specific kinematic by the firmware.
-
This post is deleted! -
Hi @JoergS5
Wow! Thanks a lot for your quick and insightful reply concerning the kinematics part and for providing the links - I really appreciate it! I'm going to make myself more familiar with the trigonometric relations between the world-coordinates (XYZ) and the individual motors (ABC + D a.k.a. U) in the firmware-files.
I already used the binary (Duet2CombinedFirmware.bin) the hangprinter lead-developer Torbjørn Ludvigsen provided with the branch (v2-dev_hangprinter, from April 2019):
https://gitlab.com/tobben/hangprinter/-/tree/version_4_dev/firmware/RepRapFirmware
It seems the branch you pointed to is more recent (last commit on 7. April 2020) – I will compile a binary for RRF3 based on the most recent files and have a go.I also found a 2-year old post on the hangprinter facebook-group page reporting good results with building a hangprinter v3 using a duet 2 board and sharing parts from the corresponding config.g-file.
https://www.facebook.com/groups/hangprinter/permalink/428191971024301
I got intrigued and wrote the post's author. – Would be curious to have a look into the whole config file.Regarding the "homing"-function I would share your opinion - at least at the moment it's not the top priority and I would be glad to be already at the point, where it would be the main one.
///
I could imagine among the Duet forum users should be people with experience in hangprinter builds and in applying Torbjørn's firmware???
It would be really interesting and helpful for the community and users like myself to read the corresponding config.g-files from successful use-cases -
@peta If you're using Duet hardware, you don't need to compile the firmware. You can simply use the binary and make all configuration through a configuration file, uploading to the SD card. The firmware loads the binary to the Duet. The most current one is found in
https://github.com/Duet3D/RepRapFirmware/releases
and an overview of RRF3 in
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview
There is an online configuration in https://configtool.reprapfirmware.org/Start, but this will help you only limited, because Hangprinter kinematics is not included. But to configure some basics like the steppers, it is a good starting point.There are some users here liking "exotic" 3D printer kinematics, including me, so you'll find example configurations here in some threads. But probably not for Hangprinter. Just check the documentation for hangprinter in https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareHangprinter how to setup (there will be details to change for RRF3).
-
@peta said in Hangprinter (v3/v4) + Duet2Wifi + Nema23:
I could imagine among the Duet forum users should be people with experience in hangprinter builds and in applying Torbjørn's firmware???
There may be, but I haven't really seen it discussed much here. Most of the activity would have been on the reprap forums or on Torbjorns github page.
