Using HangPrinter geometry for Wall Plotter?

  • Hi all,

    i am thinking of building a wall plotter like this one

    just with 3 anchors instead of 2 for more stability.
    Is it possible to achieve this with a Duet Wifi? It seems to be a HangPrinter geometry just without a D axis. I would love to hear some oppinions about this project? 🙂

  • Actually I am also interested if it would also be possible with 2 anchors since mit might be easier as a first step 😉

  • @dc42 Or might it even be possible to define an own geometry?

  • @TC you can implement a new kinematic following this information:

    In the reprapforum is a specific section for hangprinter
    where peta created a thread about using it with Duet.

  • @JoergS5 Thanks that sounds interesting. I just had a look into the kinemetics cpp files and I guess I could do that. Do you know if all the functions need to be present? For example I am not planning to have any kind of auto callibration in the beginning. Bed leveling is obsolete anyway since be are talking about a 2D system 😉

  • @TC just take a cpp and h file of a kinematic which is similar as a template. The public functions in the h file must be implemented, often you can copy the code from the similar kinematic as a first version. You must implement the functions, because most of them are virtual ones.
    I would mark the methods which are not finished yet with a comment with the word todo.

    It is useful to look into the implementations of the methods for the different kinematics, this will tell you the functions the methods are for (e.g. the LinearDelta is very detailed).

    If the sense of a method is unclear, you can ask here.

    I expect you get problems if trying to implement only 2 coordinates, as most functions rely on a 3 axis cardesian world coordinate system. So you should implement the kinematics with a "virtual" third coordinate Z (or maybe Y in your case) which is always 0.

  • This post is deleted!

  • This post is deleted!

  • @JoergS5 I am thinking about a calibration method that uses 4 defined points (like the corners of a paper) to calculate the positions of the two anchor points. That way the user would not need to measure the them himself but instead can manually move the printhead to the 4 points and the maschine saves the relative changes of motor positions.

    My problem now is that this "Homing" procedure involves manual movements and also has to be done to know the anchor points. Is there a way to pass these coordinates to the kinematics after homing is done? My Idea was to redefine the kinematics using M669 at the end of the homing macro...

    In detail without given Position parameters in M669 the kinematics would create the axes A and B which corespondes to the single motor and then can be used by the user inside the homing procedure to move to the calibration points. After the anchor positions are calculated M669 is excecuted again with parameters passed and the kinematics creates a normal X and Z axis.

  • @TC manually moving the steppers don't help, because the firmware doesn't know the position, and it's also not precise. It's only the firmware=>stepper direction working, not from stepper to firmware.

    I would define the 4 limiting borders instead of points and place endstops there (borders are easier to target than points). You could use 4 endstops type NC (normally closed) wired in series (or 2*2) and connect them to one endstop(or 2), so when one of them is triggered, the circuit is open and the endstop is triggered. Then store this stepper positions. (Maybe by means of the new object model). Another method is to trigger the endstops by the wires, but this could be difficult to implement. I thought of optically marking them with a color could be a solution.

    What I don't understand is why you want to measure 4 points. Two positions should be sufficient, because the other position is defined by the distance. The you can set the positions by G92 directly after endstop trigger.

    You can set M669 values at all times and overwrite values also. If a kinematics or cache value recalculation is necessary, the Recalc() method is for this. When M669 reads in parameter X e.g., then in the code to read X must be set a flag to Recalc().

  • @JoergS5 Ah I was not precise enough. I did not mean I would move them by hand but by defining motor A and B as axes and then use DWC to control them.

    Well the idea behind the 4 point system is the following:
    In the beginning the printer knows nothing. The printhead is hanging in two wires at the wall but it does not even know how long the wire is to the each anchor. So what it needs to find out is the X and Y coordinate for each anchor. That gives 4 variables. Now I move to the left top corner and define it as 0,0. For the followig 3 moves it can measure the change in wire length but still does not know its total length. That gives me 3 relative lengths that make it possible to calculate the anchor point. It might be possible with just 3 points but in my derivation it only works with 4 😉

    The problem with endstops is that due to the highly non linear behaviour depending on the start position it is nt even clear which border got hit. Additionally a border only gives my one coordinate... I would need even more measurements

  • @TC you should try your idea. You can use the new object model to store the values and make the calculations, or you set parameters with M669 and let the firmware calculate the distances and other parameters.

    I had some discussions in reprapforum about using wires. There were some interesting ideas to avoid the length deviation due to the take-up on a spindle.
    This here eg:,815780,page=3

  • @JoergS5 oh thanks! I was thinking about the same problem and will study the thread!

  • Moderator

    @JoergS5 said in Using HangPrinter geometry for Wall Plotter?:

    I had some discussions in reprapforum about using wires. There were some interesting ideas to avoid the length deviation due to the take-up on a spindle.
    This here eg:,815780,page=3

    @JoergS5 I remembered that there's this thread on the reprap forums,151871,177714#msg-177714 about using a tilted pulley to feed wire around a pulley. The incoming/outgoing wire is always on the same position, so there isn't an issue with it moving up and down the drive pulley, causing length deviation. Seem like they had problems getting it to work as a CoreXY though, possibly due to tension.


  • @droftarts I didn't mean moving up and down the axis position, but doubling (tripling etc.) the wires on the spindle when they are stacked, changing the radius and so steps/mm. This will result in a changing movement which is difficult to calculate.
    The solution with two pulleys had a problem that the solution had too much friction. I think the solution with the stepper and 4 spindles/pulleys at the edges is a nice solution.

    For tension, there was also a lot of discussion what to take, like FireLine, Kevlar, steel etc.

    One interesting addition was a formula how much friction is needed for wires:,817525,826869#msg-826869
    Unfortunately I didn't understand the formula...

  • @JoergS5 Hey I saw on the other topic you are also building a new kinematic system. Can you help me to build the firmware? I tried to follow the file but it seems some components are not availible for download...

    At point 3. I get to this page:
    which tells me it is outddated 😕

  • @TC the is a file in the github, your link is missing all the part http etc. in front of it.

    The correct path to the file is:
    Please take the one of the branch you're using, they may be different. (Change branch in github, the correct .md file will be shown then)

  • @JoergS5 Yes I know but the download link in the BuildInstruction file in version 3.1.1 did not work. But the link in the file you posted worked 🙂
    Now I followed the instruction and unfortunately am stuck trying to build CoreNG. I get this error:

    17:29:36 **** Incremental Build of configuration Default for project CoreNG ****
    make all
    make: *** No rule to make target 'all'. Stop.
    "make all" terminated with exit code 2. Build might be incomplete.

    17:29:36 Build Failed. 1 errors, 0 warnings. (took 532ms)

  • @TC I don't build for all, so I don't know how to help. I use a specific target, Duet 3 e.g. and then build. When I build RepRapFirmware, it builds all dependent projects automatically (including CoreNG).

  • @JoergS5 I didn't intend to build for all. Do you know how just to build for Duet Wifi?

  • @TC in project RepRapFirmare, right click on project, then select Build Configuration - Select - and select your target.
    I deleted the Duet 2 target in my project, so I cannot tell you how it's named, probably SAM4E8E (that's the name of the MCU).

    I checked, it's probably Duet2_RTOS.

  • @JoergS5 Ok I did not take the different branches into account. Now CoreNG and FreeRTOS work but RRFLibaries dont...
    Do you use these branches?

    RepRapFirmware: v3-dev
    CoreNG: dev
    FreeRTOS: master
    RRFLibraries: dev
    DuetWiFiSocketServer: master
    CANlib : master

    Or did anything change here that is not updated in the instruction?

  • @TC I had also some problems with the different branches. So now I always use tags, currently 3.1.0 tag for all projects (in github, when opening a project, there is a tag button). They compile well. I've not tested it, but RepRapFirmware has a 3.1.1 tag also, this could work also.

  • @JoergS5 yes now we are very close 😉
    Just one more error at the end of Firmware build:

    c:/program files/gnu arm eclipse/build tools/2.6-201507152002/bin//sh: crc32appender: not found
    makefile:94: recipe for target 'post-build' failed
    make[1]: [post-build] Error 127 (ignored)

    Did you see that before?

Log in to reply