Add Dagoma D6 board as used in their DiscoUltimate v2 TMC.

[Sophist-UK]

trafficstars

Description

Add the Dagoma3D D6 motherboard as used in their Disco Ultimate v2 TMC printer (and possibly other models).

Requirements

Dagom3D D6 motherboard

Benefits

Adds support for a new motherboard.

Configurations

Taken from the Dagoma fork of Marlin DU_MC branch (where it is called FYSETC_DAGOMA_F5) and explicitly confirmed by Dagoma as being the D6 in response to a ticket I raised with them:

"the BOARD_FYSETC_DAGOMA_F5 is effectively the definition for the D6"

Related Issues

No.

[ellensp]

env:mega2560 does not support io pins > 69

On This board [XYZE0]_SERIAL_RX_PIN and [XYZE0]_SERIAL_TX_PIN are set to IO pin 73.

for IO pins 70-85 you must used env:mega2560ext set in Marlin/src/pins/pins.h

[Sophist-UK]

My mistake - I failed to copy the Dagoma comments. Pushing a fix now.

[InsanityAutomation]

A dev working for Dagoma used to be active on discord a few years back. I sent him a ping to see if he was still active and/or employed there to chime in if there is anything to note.

[InsanityAutomation]

Orel confirmed on discord that the naming was retained from a prototype board and everything matches, so just the env call to adjust.

[0r31]

@ellensp and @InsanityAutomation : The board is based on the Fysetc F6, that's why we use pin 73.

@Sophist-UK : The right env to set is env:FYSETC_F6.

(Thanks @InsanityAutomation to ping me ;))

[0r31]

Short explanation : From platformio platform-atmelavr : https://github.com/platformio/platform-atmelavr/blob/d9d2738bcb1c632e2f5e3c57318e6ae8281ee960/boards/fysetc_f6_13.json#L13 There is a fysetcf6 variant.

I don't exactly know from where the pin definition file is retrieved (i don't find it https://github.com/arduino/ArduinoCore-avr), but in the platformio framework-arduino-avr package on my computer, the variant file exists : variants\fysetcf6\pins_arduino.h.

Inside this file, the pin 73 is explicity defined and used :

[InsanityAutomation]

@0r31 It appears at a glance to be a limited implementation of what mega2560ext has, as it likely predates it, with just what they needed. Id like to see if it behaves with the standard definition in order to avoid confusion calling for a fysetc environment with a board not labeled fysetc, but if we cant confirm that then I suppose leaving it as-is works without any additional effort.

[0r31]

@InsanityAutomation understood. I didn't know the fysetcf6 variant is "derived" from mega2560ext.

[Sophist-UK]

I was a little bit concerned that this was going to end up being different from the Dagoma version, so happy that we have now settled on it being the same.

[thisiskeithb]

@Sophist-UK: Please test this board with the mega2560ext environment and let us know if it still works as expected.

[InsanityAutomation]

1 more hindsight thought here... The TMC slave addresses are sometimes in configs sometimes in pins... Should we move this one to the pins file to simplify things for end users?

[Sophist-UK]

@thisiskeithb Sorry, but I don't have either the D6 board or the printer it is used in. I am trying to generate up to date versions of firmware for a variety of models equivalent to the out-of-date builds provided by the manufacturer.

But this is the board definition taken verbatim from the Marlin fork that they built their own firmware with.

[Sophist-UK]

The TMC slave addresses are sometimes in configs sometimes in pins... Should we move this one to the pins file to simplify things for end users?

I don't know what this means - where would I find these TMC Slave Addresses defined in the Dagoma fork of Marlin for this board? In config_adv.h?

[thisiskeithb]

1 more hindsight thought here... The TMC slave addresses are sometimes in configs sometimes in pins... Should we move this one to the pins file to simplify things for end users?

We can assert them in the pins files like I did in https://github.com/MarlinFirmware/Marlin/pull/26842 so configs don’t get recycled into a new build with a different motherboard and end up with incorrect values.

[thisiskeithb]

But this is the board definition taken verbatim from the Marlin fork that they built their own firmware with.

Right, but we’re trying to generalize it so it’s not confusing for anyone looking at this in the future.

It's common for us to clean up a fork's implementation of code / pins / etc.

[0r31]

@Sophist-UK @InsanityAutomation : The slave addresses are defined in the config file, as Marlins states it should be.

https://github.com/dagoma3d/Marlin/blob/DU_MC/Marlin/Configuration_adv.h#L2947-L2965

But to be printer agnostic, maybe it should be a good idea to add it in the pin definition file. I don't know which is the right convention to follow.

[InsanityAutomation]

Theyre soldered on, so when the board is defined... immutable. Thats when I support setting them in pins file.

#define X_SLAVE_ADDRESS 0 #define Y_SLAVE_ADDRESS 1 #define Z_SLAVE_ADDRESS 2 #define E0_SLAVE_ADDRESS 3 #define E1_SLAVE_ADDRESS 3

Very often we surround em with an #ifndef to allow an override,

We have a very solid mix of which way theyre defined so I wouldnt say either is right or wrong.

[Sophist-UK]

I hope that I have done as requested by merging what @0r31 pointed in in the format that @thisiskeithb pointed to.

(Apologies for the delay in pushing - my PC is doing a large file xfer to my NAS :-( )

[0r31]

@Sophist-UK : seems good to me.

I will test the board with the mega2560ext env before the end of the week. If it works, i will notify you then you could go to this env.

[Sophist-UK]

I will test the board with the mega2560ext env before the end of the week.

Thank you - that is extremely good of you to offer.

[thisiskeithb]

I will test the board with the mega2560ext env before the end of the week. If it works, i will notify you then you could go to this env.

Thank you! I've marked this PR as a draft for now until you can report back, so please let us know.

[0r31]

Hi,

Just a quick update. Today i shortly checked :

• The fmk arduino pin file related to mega2560ext ---> ok
• The firmware compilation using this env ---> ok

Tomorrow ---> Tests

[0r31]

@Sophist-UK,

It is a final go for me to use the mega2560ext env. The printer i use to test behaves exactly the same as before.

Thanks @InsanityAutomation and @thisiskeithb for your wise advices.

[Sophist-UK]

I have reapplied the env:mega2560ext fix suggested by early review comments.

Thanks to @0r31 for testing this. 👍

[Sophist-UK]

Thanks to everyone who helped with this PR - especially @0r31 Orel who has put in much more effort than I did.

[sjasonsmith]

I observed that @0r31 did earlier work on this and jump in to test. I made sure they were credited as a co-author on the merge.