some advices

[chinamore]

This version has the biggest problem. I guess no one except you dares to copy this board. My idea is very simple. You can clear all the TMC2660 and use a double-layer board layout, which will save a lot of cost. Provide 4 signals for each axis of the closed-loop printer: P+D+E+GND, which will greatly facilitate players who use external drives

[ghent360]

Could you elaborate what problem you are referring to? I do not believe a double layer board would provide sufficient cooling. Also the cost difference of a double vs 4 layer board is minimal at 10x10cm size (jlcpcb.com). ~V

…

On Wed, Apr 7, 2021 at 5:53 PM chinamore ***@***.***> wrote: This version has the biggest problem. I guess no one except you dares to copy this board. My idea is very simple. You can clear all the TMC2660 and use a double-layer board layout, which will save a lot of cost. Provide 4 signals for each axis of the closed-loop printer: P+D+E+GND, which will greatly facilitate players who use external drives — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FRVQYVCDVCSRX2OOX7BLTHT5ADANCNFSM42R2HBAQ> .

[M10CUBE]

Hi @ghent360
Some time ago we made a hardware platform called M10CUBE
https://hackaday.io/project/171770-m10cube
https://gitlab.com/m10cube/m10
A few days ago I ported to M10CUBE from maker @terjeio a similar to yours (NUCLEO64) hardware but for CNC control
terjeio/CNC_Breakout_Nucleo64#3
I know you made a new version of the REPRAP controller but I like more the NUCLEO idea. More flexible and extremely cheap.
One goal now I am looking is to make a common controller for REPRAP and CNC.
Having all I/Os needed of the main board and use M10CUBE I/O modules

I have explained the concept here:
grblHAL/RP2040#3 (comment)
I am watching this in your you tube channel as well
Thanks

Since you are an experience designer I like to here from you if something like that makes sense to others as it makes sense to me.
Thank and congratulations for your grate designs.

[ghent360]

Hi, One drawback of the nucleo-style board is that a lot of space is wasted on the I/O ports. Especially if you want to go to a 100-pin or larger MCU package - the 2.4mm pin spacing eats a lot of space, so you will have to go to a fancier connector with higher density, which unfortunately removes the price advantages. If you focus on CNC controls - they use a relatively small number of IO lines. If you move to integrated stepper drivers (Trinamic or others) - then you have to add SPI, UART and other pins and the 64-pin package is not sufficient and at one point half your board is consumed by the board-to-board interconnect. It is not an impossible problem to solve - just something to keep in mind as you go along. ~V

…

On Sun, Dec 5, 2021 at 10:30 AM M10CUBE ***@***.***> wrote: Hi @ghent360 <https://github.com/ghent360> Some time ago we made a hardware platform called M10CUBE https://hackaday.io/project/171770-m10cube https://gitlab.com/m10cube/m10 A few days ago I ported to M10CUBE from maker @terjeio <https://github.com/terjeio> a similar to yours (NUCLEO64) hardware but for CNC control terjeio/CNC_Breakout_Nucleo64#3 <terjeio/CNC_Breakout_Nucleo64#3> I know you made a new version of the REPRAP controller but I like more the NUCLEO idea. More flexible and extremely cheap. One goal now I am looking is to make a common controller for REPRAP and CNC. Having all I/Os needed of the main board and use M10CUBE I/O modules I have explained the concept here: grblHAL/RP2040#3 (comment) <grblHAL/RP2040#3 (comment)> I am watching this in your you tube channel as well Thanks Since you are an experience designer I like to here from you if something like that makes sense to others as it makes sense to me. Thank and congratulations for your grate designs. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FRVQHAOEOAT5HO36IML3UPOVTJANCNFSM42R2HBAQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[M10CUBE]

Thanks @ghent360 for the quick response. All you said have solid ground. It is not a simple task to solve. For my M10CUBE concept to make sense is to make some compromises. So I end up thinking the cons and pros
CONS:
1 Some ARM modules are larger than M10CUBE format
2 The density of a design using the actual MPU chips can not achieved in case of using some module incarnation. Using bare bone MPU chip is more dense but you loose the fun of reusing the plug in module.
3 Cost looks higher as well. I made the math.

PROS
1 - Construction in mind using ST Nucleo64 or Raspberry Pi Pico. That is ARM MPU, Cheep, Highly supported, Ready available and have room for next more powerful board announcements in the years to come. Probably these modules are found already in every serious maker.
2 - Fits nicely into M10CUBE concept (90X90 mm and up to 100X100 on the not fixed connectors side)
3 - Some space is lost because of the footage but on top has a lot of hardware impossible to make it on the footprint lost. On top of that you have the real estate underneath the module to place other hardware. In the end you gain more space than you loose
4 - Ready for Analog, Ethernet and Can Bus to experiment (I am sure the newcomer as well I3C or the 10BASE-T1L Ethernet)
5 - Extremely useful for the education community. That was the success of Raspberry (plus the clever engineering of course).
6 - All I/Os will move to an extra M10CUBE module so space on board only used for step drivers (encoder inputs under consideration). I will stic on SPI interface for trinamic and not UART but still I need discrete signals 6XStep/Dir/Enable as maker @terjeiro from GRBLHAL stated. That is to drive any external driver setup
7 - ...more to come

That is to build a common board for GRBL and MAPLIN as I state it here:
grblHAL/RP2040#3 (comment)

The design is not cure for ever illnesses but a "medicine" to cure many and become a useful tool for makers and educational community. So any info and help is valuable to me

Thanks