Hangprinter help on duet 3

[Phaedrux]

I think you'll find many people on there using Duet as well. You may be the first using Duet3 though?

[dc42]

@Shinomori said in Hangprinter help on duet 3:

Thanks. I'll take a look on there too.

It seemed like this was the better place to start since the original design used marlin on a mega and I'm trying to use RepRap on the duet 3.

Although the standard firmware includes HangPrinter kinematics support, I know that the creator of HangPrinter has a fork of RRF with more advanced support. I don't know whether he has ported this to RRF3 yet. I suggest you get in touch with him, https://www.hangprinter.org/contact.

[Shinomori]

@dc42 said in Hangprinter help on duet 3:

@Shinomori said in Hangprinter help on duet 3:

Thanks. I'll take a look on there too.

It seemed like this was the better place to start since the original design used marlin on a mega and I'm trying to use RepRap on the duet 3.

Although the standard firmware includes HangPrinter kinematics support, I know that the creator of HangPrinter has a fork of RRF with more advanced support. I don't know whether he has ported this to RRF3 yet. I suggest you get in touch with him, https://www.hangprinter.org/contact.

I didn't know he was working on a RRF fork. I'll take a look. Any thoughts on what is wrong with my config were the U axis doesn't move like the XYZ do?

Thanks

[dc42]

@Shinomori said in Hangprinter help on duet 3:

When I send g1 s2 u10 the D motor starts moving forward and doesn't stop till I hit e-stop.

Did you send G91 to put the machine in relative coordinate mode before you sent G1 H2 U10 or G1 H2 U-10 ? If you didn't then the machine will try to move to absolute coordinates, which is almost certainly not what you wanted.

[Shinomori]

@dc42 said in Hangprinter help on duet 3:

@Shinomori said in Hangprinter help on duet 3:

When I send g1 s2 u10 the D motor starts moving forward and doesn't stop till I hit e-stop.

Did you send G91 to put the machine in relative coordinate mode before you sent G1 H2 U10 or G1 H2 U-10 ? If you didn't then the machine will try to move to absolute coordinates, which is almost certainly not what you wanted.

That was it. Must have missed it with all the rebooting. Thanks! Got all the axis moving correctly now. Just need to fine tune the movement amounts. (And get a more reliable router. Spent all yesterday not able to connect to printer. )

[Phaedrux]

Please post some photos of the first duet 3 hang printer.

[vmario89]

Hi. I am working on to build a recent HangPrinter with Duet 2 Ethernet v1.04 and MisfitTech Smart Stepper (Mechaduino Fork). I am checking a lot of software stuff due to major and minor compability and accuracy problems. I think with Duet 3 Firmware there seem to exist different difficulties

What i found so far:

• Torbjörn did his own Fork of RepRapFirmware (RRF) due to missing features: https://gitlab.com/tobben/hangprinter/-/tree/version_4_dev/firmware/RepRapFirmware and https://github.com/dc42/RepRapFirmware/pull/186 for detailed description of what he did
• the official docs say that Duet 3 Firmware does not fully support HangPrinter yet. So use Version 2.x (see https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareHangprinter - there is written "Hangprinters are supported in RepRapFirmware 1.20 beta 11 and later. RRF3 currently lacks support.")

if you want to use Smart Stepper there is also official firmware and some custom fork of Torbjörn. He implemented torque control mode.

when i proceed i will try to share my config json. Because at the moment the basics are missing or are stored in hard-to-find places

tobbelobb opened this pull request in dc42/RepRapFirmware

closed Tighter Hangprinter Compatibility #186

[Phaedrux]

@vmario89 said in Hangprinter help on duet 3:

the official docs say that Duet 3 Firmware does not fully support HangPrinter yet. So use Version 2.x (see https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareHangprinter - there is written "Hangprinters are supported in RepRapFirmware 1.20 beta 11 and later. RRF3 currently lacks support.")

I actually updated that based on DC42s comment above, but I think I mistook him to mean RRF3 doesn't support the hang printer, when in fact he was indicating that Torbjörn's fork hadn't been ported to RRF3 yet. Now that may amount to the same thing in the end depending on how critical Torbjörn's modifications are.

[dc42]

I ported many of Torbjörn's changes for Hangprinter to RRF. I stopped when he added the Mechaduino features, because they take over additional ports and thereby affect the normal features of RRF. If Torbjörn can provide me with a PR for RRF3 that doesn't affect other users (preferably with changes only to the HangprinterKinematics module) then I will gladly merge them into the next RRF3 beta.

[Shinomori]

Thanks for the input guys.
Here's what it looks like now. Still on the bench till I get the firmware settings at least somewhat sorted.

We're wanting to print something about 250mm x 250mm x 250mm for the first test. Then will be scaling that print up to 1m(which will need moving anchors and more serious extrusion).

@dc42 said in Hangprinter help on duet 3:

I ported many of Torbjörn's changes for Hangprinter to RRF. I stopped when he added the Mechaduino features, because they take over additional ports and thereby affect the normal features of RRF. If Torbjörn can provide me with a PR for RRF3 that doesn't affect other users (preferably with changes only to the HangprinterKinematics module) then I will gladly merge them into the next RRF3 beta.

Just to clarify. How much of implementation is there in RRF3 for the hangprinter? Same as in the dozuki? Or does it have any of the extra parts that Torbjörn added in his fork?

Thanks

[dc42]

@Shinomori said in Hangprinter help on duet 3:

Just to clarify. How much of implementation is there in RRF3 for the hangprinter? Same as in the dozuki? Or does it have any of the extra parts that Torbjörn added in his fork?

It doesn't have the Mechaduino torque mode support, and I think it may not have spool build-up compensation either.

[Shinomori]

@dc42 said in Hangprinter help on duet 3:

@Shinomori said in Hangprinter help on duet 3:

Just to clarify. How much of implementation is there in RRF3 for the hangprinter? Same as in the dozuki? Or does it have any of the extra parts that Torbjörn added in his fork?

It doesn't have the Mechaduino torque mode support, and I think it may not have spool build-up compensation either.

Ok. That means there's plenty already in for our "proof of concept" phase. Thanks!

[Shinomori]

We got it set up briefly to demonstrate the concept.

And had to tear down again to move locations. It was never intended to print at this spot.

But we got all axis moving and the correct amount of feed on each roll and the extruder. Something was a bit off with the calibration because as it moved some lines would end up with more tension and eventually skip steps or cause other lines to get slack.

On the config are the anchor points measured from the nozzle 0,0 to the center between the pulleys or from the corners on the A/X side to the closer pulley on the anchors?

We are hoping to get printing next time we get it setup.

Thanks

[dc42]

AFAIR, in the configuration X0 Y0 is the position below the D anchor.

Have you read https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareHangprinter ?

[Shinomori]

@dc42 said in Hangprinter help on duet 3:

AFAIR, in the configuration X0 Y0 is the position below the D anchor.

Have you read https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareHangprinter ?

Yep I've gone through it many times and other hangprinter build guides. I haven't yet gone through the whole thread on the reprap forum, but I'm working on it. I'll draw a picture to better ask my question.

My under standing is that in Marlin the config is like this:

Where the anchors are measured from the string connection points on the corners of the frame.

Does the reprap config work the same or is it more like this:

Where 0,0 is the tip of the nozzle and the red lines are reference for the anchors.

Thanks

[dc42]

@Shinomori said in Hangprinter help on duet 3:

Does the reprap config work the same or is it more like this:

Where 0,0 is the tip of the nozzle and the red lines are reference for the anchors.

It's like your second diagram, where (0,0) is the position right below the D anchor. Calling 0,0 the position of the nozzle doesn't make sense, because the nozzle moves.

[vmario89]

Hey, i am working hard to get my Hangprinter working too and doing it with Duet 2 firmware. Neithertheless i figured out that the offical documentations lacks information about the M669 command and it's configuration parameters to use

https://duet3d.dozuki.com/Wiki/Gcode#Section_M669_Set_kinematics_type_and_kinematics_parameters

There is a huge line in config.g (can also be forced to generate by M500 command which write config_override.g). This looks like M669 K6 A0.000:-2000.000:-100.000 B2000.000:1000.000:-100.000 C-2000.000:1000.000:-100.000 D3000.000 P2000.0 Q0.007000 R55.000:55.000:55.000:55.000

ABCD are the anchor point locations

But what are P, Q and R values?

cheers, Mario

[dc42]

P is the print radius. I don't know what Q and R are because they are not supported by the standard firmware. I guess the creator of Hangprinter added them in his fork. Possibly something to do with spool build-up compensation. Best ask him.

[vmario89]

Hi,

finally our printing is working and documentation for a lot of stuff can be found here > https://wiki.fablabchemnitz.de/display/TH

We did not use Duet 3 firmware but there you can find different topics about things like motor wiring, math, coordinate system, PID tuning, etc.

[dc42]

I'm glad you got it working!

I presume you used the RRF firmware fork from the creator of Hangprinter. We'd love to incorporate many of the improvements he has made to Hangprinter support in that fork into our standard build. Unfortunately, in that fork he repurposes the UARTs (to drive Mechaduinos in torque mode AFAIR), which makes it incompatible with normal use of RRF.

Duet/RRF do support I2C, so I don't know why I2C wasn't used. However, i2C is generally a bad choice for connecting different devices because it has no noise immunity. It was designed for interconnecting ICs on the same board only.