@phaedrux said in M21: Cannot initialise SD card 0: Card is unusable<LF>ok<LF>:

Unfortunately no such damage is not covered by warranty, since it's akin to a wiring fault.
However, we may be able to offer a refurbished unit on exchange at reduced cost. Please contact roland@duet3d.com to inquire about availability. Include a link to this thread.

Thanks a lot for the support, troubleshooting/preventive hints and the suggestion with a refurbished unit!
And thanks a lot for your guy’s effort and contribution to this community of additivist enthusiasts!

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 :).

Re: Hangprinter help on duet 3

@phaedrux said in M21: Cannot initialise SD card 0: Card is unusable<LF>ok<LF>:

Unfortunately no such damage is not covered by warranty, since it's akin to a wiring fault.
However, we may be able to offer a refurbished unit on exchange at reduced cost. Please contact roland@duet3d.com to inquire about availability. Include a link to this thread.

Thanks a lot for the support, troubleshooting/preventive hints and the suggestion with a refurbished unit!
And thanks a lot for your guy’s effort and contribution to this community of additivist enthusiasts!

@phaedrux said in M21: Cannot initialise SD card 0: Card is unusable<LF>ok<LF>:

The Paneldue SD card slot can't be used as the main SD card, only to load Gcode files from.
If it was a ground loop damage there may be other damage that isn't apparent. do any other components get hot?
Replacing the SD card slot may be an option if you have the experience and tools needed, otherwise maybe finding someone who does.

Thank you very much for your reply, your support and for the clarification on the SD card slot of the Paneldue and potential ground loop damage consequences.
Unfortunately, neither do I have the access to appropriate de-/re-soldering equipment for handling pcb/electrical components of such scale, let alone the know how for an accurate and exhaustive forensic analysis :(.
Nor would I know of someone with access to such equipment or skills.

May I ask whether a ground loop damage might be covered by warranty?
I purchased it in June 2020 from one official german reseller (https://www.dold-mechatronik.de/).

Thank you!

@felek said in M21: Cannot initialise SD card 0: Card is unusable<LF>ok<LF>:

@peta This path doesn't look good

Hi felek

here are some more pictures:

• one with bit better details of the soldering points
• one from the back of the board (the usb connector)

@phaedrux
Thanks for the quick reply!
Yes, I can confirm, the board is otherwise recognised over USB and takes commands (e.g. I could set up the records for a new wifi connection, just couldn't reach the web interface because the sd card wasn't detected).

The "ground loop" assumption sounds like a plausible explanation.

Would you know of a work around to attach an sd card socket otherwise?
(I only know that the PanalDue has a sd card slot. Would this be the only extension with a sd card slot? Would it even be possible to use it as the main sd card interface?)

Thanks, Phaedrux!

@dc42

Dear admins

Unfortunately, I have a similar problem with my SD-Card on my Duet 2 Wifi.
I have the board since June 2020 and was using it since in a test setting, not in a working production setting yet. But recently, as the setup was running as usual (connected to 24V PSU + 4x NEMA23 motors, no hotend, probes or printheads etc.).
I connected the Duet 2 Wifi board additionally via USB to my computer. This was unproblematic before. But this time there was a hissing sound and next the SD-Card was ejected out of its slot and landed around two meters away.
I immediately switched off the 24V PSU. As I picked up the fugitive SD-Card I felt that it was pretty warm.
I tied to put it back in the SD-Card slot and realised, that its retaining mechanism wasn’t working anymore and the card wouldn’t stay in the slot.
When supported/held back the card it would be read as usual and the hissing sound didn’t come back again either.
But now, the card cannot be read and when I check it with Serial Tools (Mac) I receive the error message:

Cannot initialise SD card 0: Card is unusable

I tried other SD-Cards (properly formatted with SD-Card Formatter), which work fine in other computers.

Would it be a warranty case or would it be possible to fix it somehow?

Thanks in advance!

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

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 :).

Re: Hangprinter help on duet 3