M10CUBE PICO CNC. A Universal Controller ?

[M10CUBE]

Welcome open minders and dreamers. Welcome everybody.

Why another PICO CNC?. Because will learn a lot in the process specially in KiCAD6 design, but the most important this concept will be different from what is designed so far.

Work in progress and based to the following excellent designs. More designs and adapt ideas in the process
https://github.com/terjeio/CNC_Breakout_Nucleo64
https://github.com/Expatria-Technologies/PicoBOB
https://github.com/terjeio/CNC_Boosterpack
#3 (reply in thread)

Soon a block diagram of the expandable system will be provided and everybody will get the idea of the final M10CUBE concept and how M10NumericControll (code name M10NCXX-XX) module will fit to the total M10CUBE platform.

This is not an easy task and the end product defiantly will require some patches into GRBLHAL code.
This is an EXPERIMENTAL module code named M10NC02-10 designed with KiCAD6.
Previews M10CUBE module code name M10NC01-10 was designed and sent for fabrication in LJCPCB.
https://hackaday.io/project/171770-m10cube/log/202097-m10cube-nucleo64-cnc
That was work of @terjeio and I just ported on M10CUBE format to test it with the M10CUBE platform I/O modules.
https://github.com/terjeio/CNC_Breakout_Nucleo64
This board when finally build will be another addition to M10CUBE project available to the community
https://gitlab.com/m10cube/m10

Hardware on board so far but that can be change in the process and depends of the community ideas . This is just a roadmap of what the project is directed

1 - Raspberry Pico,
2 - 6 X StepStick. Not sure about the sixth driver, (Pico pins limitation) . External connectors for larger drivers
3 - Opto - isolated spindle PWM.

Future ideas include encoder inputs on board and more...
I/O will be moved to other M10CUBE I2C modules. Patches must be written to GRBLHAL for I2C strobe I/Os (Interrupt).

First of all the attempt is to be a unified controller both for GRBLHAL and MARLINHAL applications. HAL porting was a grate idea and M10CUBE will add value to this excellent work (hopefully)

M10CUBE design follows a different experimental approach. That is not the monolithic PCB design (all in one) but many modules connected together and sharing I/O boards that can be used for other control purposes.

At the moment basic I/O modules are designed like Relay, SSR and Transistor isolated IN/OUT. If more needs arisen it is easy to design using other M10CUBE PCB as a template. If you think of a module just ask.

The situation is that we need more and more axis. Not actually for CNC but generally we we need to have control to many motors in the future, more than one PCB module can handle. Monolithic PCB is a dead end and a modular approach looks to have a future. M10CUBE idea is to be able to connect many Driver Boards together (A DRIVE as it is called in In Automation industry) with a high speed bus like the new 2 wire ETHERNET 10BASE-T1L or I3C. Both will be available commercially in 2021 - 2022. These buses can deliver 10MBPS in 2 wires in a long distance. Thus if 12 step (or more) motors needed XxM10CUBE CNC can be linked together with any CPU (e.g Raspberry PI plugged on the bus) as a main controller and do motor control on the edge . The connected number of "DRIVES" can be practically unlimited.

It is the same concept Industrial motion control is made. There is a PLC as a central controller and many motor Drives on an installation in the field. All connected with a a real time field bus e,g CANOPEN or better EtherCAT .

In our case the field bus can be the new ETHERNET 10BASE-T1L or I3C (not real time though but that is no problem at the moment since ETHERNET 10BASE-T1L and I3C provides Interrupt through the same 2 wires with no extra strobe wire).
At the moments I2C with interrupt will be used and have an open mind on the ETHERNET 10BASE-T1L or I3C . Embed them when ready. M10CUBE modules can be converted very easy to adapt the new standards.
As I said this is an experiment to examine the limitation and possibilities of the M10CUBE platform.

M10CUBE modules can be reused for any automation applications. M10CUBE modules philosophy is to design hardware "application agnostic" like any Industrial PLC in the market. From Robotics to Home Automation

The PDF schematic is just to get an idea. Work in progress...
https://drive.google.com/file/d/1cWySYlnZWCqdnk4ih0ypQZ-8SZzeVYCb/view?usp=sharing

This design has his space in hackaday.io together with other M10CUBE modules
https://hackaday.io/project/171770-m10cube/log/202098-m10cube-pico-cnc

Please to not hesitate to place your ideas to here. The journey may look long but everybody will benefit.

[Volksolive]

That's a nice project !

Just a couple of reflections:

• Why not put a RP2040 chip directly instead of the PI Pico, you'll get some more pins this way as the Pi Pico does not breakout all the RP2040's pins.
• Have you considered other stepsticks then the TMC's, For example DRV8825, A4988, etc.
• With the stepstick height, I guess this board will be on top of the stack ?
• How will you manage the forced cooling of the stepsticks ? Without it the maximum motor current is quite lower than the max spec.

[M10CUBE]

Now we are talking! This is where the brain storming starts...

* Why not put a RP2040 chip directly instead of the PI Pico, you'll get some more pins this way as the Pi Pico does not breakout all the RP2040's pins.

That is a consideration but these are the reasons why the ready module is choose (Of course we can always change down the road.)
1 - Raspberry PICO module is ready available. This plug in beast can be used for other experiments.
2 - I am sure next Raspberry PICO pin compatible will include mode hardware on board like WiFi like DiP-Pi PICO PIOT (WiFi, SD card, and more on board). I do not want makers to loose that opportunity
3 - Time to market will be very fast using the module.
4 - Cheaper to build than getting and soldering the individual.
Bottom line is that can do both. "Quick and dirty" build the ready module in no time and then if we need more pins continue with the chip but this one will take more time. I am counting PICO pins now to see if we can have 6 motors connected.
I am even thinking to move I2C PWM spindle to other M10CUBE module to free PICO pins. Any help will appreciated on that.
We may design a new M10CUBE (multi function) module to contain all I/O needs for CNC or 3D printer )

* Have you considered other stepsticks then the TMC's, For example DRV8825, A4988, etc.

The design will follow what @terjeiro did and that is:
On-board sockets for Polulu (A4998 and DRV8825) or Trinamic (TMC2130 or TMC5160 - SPI mode, TMC2209 - UART mode) style motor driver modules.
The same circuit is on the M10NC01-10 module
https://hackaday.io/project/171770-m10cube/log/202097-m10cube-nucleo64-cnc

* With the stepstick height, I guess this board will be on top of the stack ?

* How will you manage the forced cooling of the stepsticks ? Without it the maximum motor current is quite lower than the max spec.

OK good question. At the moment this board will be the first one so the TOP will be open for cooling gear. Even if you put another on top we can made more distance between the boards. Many ideas can be applied here.
We already did some 3D printed boxes to contain the stack-able design and we can see these down the road.
People with 3D design knowledge can help on that. I will be glad to provide the files so far. We are even thinking IP protection.
The idea is all modules to mount on a DIN-RAIL vertically or Horizontally with mounting holes on the boxes OR individually mounted on a container floor . The connection between the boards can be with the 40cores flat cable found from old HD connections. That way all tops can be free.

[M10CUBE]

Today I revised and publish a draft PDF about PICO CNC design based on M10CUBE platform
Work done so far on the schematic:
https://drive.google.com/file/d/1xL0l2rpjPlcgtTsyU6HfuBw3rf6bvVk9/view?usp=sharing
The idea is to use the 6XTrinamic/Polulu design based on terjeio/CNC_Breakout_Nucleo64 design . Because of PICO pins limitation the shift register approach was used for the ENABLE signals
Trejeiro was using individual XLim,YLim,ZLim,ALim,BLim signals for controlling the StepSticks.
At the moment this left to consider using some ideas (a shift register or connecting all together in one signal)

1 - X,Y,Z,Y,A axis share the same PICO pins as PicoBOB design and B,C axis placed on unused pins
2 - ENABLE signals follows Phil Barrett approach using shift register.
3 - Spindle control needs redesign and more talk
Please I would like your opinion

[Volksolive]

Why not using the shift register(s) for step and dir too as on the Phil Barrett's Pico CNC? That would save a lot of pins, 12 pins actually if you already consider using the shift register for the ENABLES.

Regarding the end limit input, I think it is better to have them separated for f.ex ganged axis.

What kind of spindle control are you considering? PWM, 0-10V, 4-20mA, RS485, other ?

[M10CUBE]

Why not using the shift register(s) for step and dir too as on the Phil Barrett's Pico CNC? That would save a lot of pins, 12 pins actually if you already consider using the shift register for the ENABLES.

Yes we can. That was the initial idea and actually designed it but then I thought to save space and use PICO pins like on PICOBOB.
On second thoughts 6 signals on StepSticks are seeking for pins and there are XLim,YLim,ZLim,ALim,BLim,CLim,DLim .
I will give it a try and see how its goes. You must read the PDF when published within the day.

Regarding the end limit input, I think it is better to have them separated for f.ex ganged axis.6

The previews modification(shift registers as Phil Barrett design) answers this too. We will have free pins on PICO to do that now

What kind of spindle control are you considering? PWM, 0-10V, 4-20mA, RS485, other ?

All kinds so everybody will "get the egg". That is why we need ideas on what is in the market.
Mine for instance has this popular controller:
#3 (reply in thread)
Defiantly needs isolation. Needs an ON/OF relay contact for start stop and 0-1,8 V for speed control.
I think 0-10V Isolated output will cover all needs even commercial Frequency Inverters (VFD).
Then PWM. I will see specifications for a VFD and adjust it properly.
As a bonus I am thinking an RS485 interface on board (Or pin compatible SN65MLVD200 LVDS Interface). That can be used for a remote control module or to regulate speed in a VFD or for other control purposes. As everybody knows It is very popular in industry (in CNC community too) and comes with no cost.
That way the same module (only PICO populated) and an I2C keyboard can be used as the remote control module. For this reason I may consider an encoder input on board for the rotary encoder knob. Thus having Shift registers as you propose I may have the pins needed.

[M10CUBE]

Here comes a problem. In an ordinary CNC module Limit Switches interface is located on the main CPU module. In the M10CUBE concept Limit Switches are located on another I2C (Interrupted) M10CUBE module. Thus physical input on the main (CPU) PCB is not existed.
Some turnaround for the problem.
1 - Reversing the procedure and ask the CPU when Limit signal detected to output these signals to StepSticks . If not many pins we can connect them together in one signal (Not very good idea) or better to use another shift register for that purpose
2 - Forget the remote I2C and put Limit switches on the main board. That violates M10CUBE philosophy for distributed bus I/O but we can make an exception for high speed inputs like Limit switches. These six high speed inputs can be used for other purposes like rotary encoder inputs for use on the remote control module.
3 - Since we have Rarpberry 40 pin BUS e can design M10CUBE Input module with inputs transferred not on I2C but on the 40 pin BUS . These will be the critical Inputs like Limit switches
As I said remote control module can be the same PCB with StepStick unpopulated.
I will give a try on the second solution to see if there is space available and then I will try the third one. In fact the individual 8X INPUTS + 8 OUTPUTS (without I2C chip) module can be build anyway as part of M10CUBE platform.
In fact having future demands in mind I have designed the current version (10) of I/O boards to Bring the Isolated signals I/O in parallel from the board using a 2X8 flat cable IDC connector. This connector can be in place of the 8 LEDS (INPUT and OUTPUT side) on the edge indicating the state of I/O
That is why I mounted the LEDs that way. Using 2x4 Pin 8 Pin IDC connector in place of LEDs.

The only thing needed is a 2X8 pin header and a flat cable to bridge the two boards. This a free bonus or anyone building on M1OCUBE. Check that out on the PDF or see the images and you will get the idea. I am using this concept now on my current CNC with UNO CNC shield. There is no isolation as you know on the shield and I had millions of problems before. Solved using the above method. Everything within M10CUBE philosophy

OR

Any opinions are welcomed and adapt the ideas on the final design.

[M10CUBE]

I just finished the new concept with shift registers. The solution chosen was using a connection between a M10CUBE input module direct connecting to PICO after the Isolation. On page 2 I have some explanations. There are some issues because signals have no PICO pins to go (FHOLD, CYST, DOOR, PRB). Can we get the from I2C interrupt?
And no way to find spare for RS485. Spindle circuit needs revising and correction as well.
Waiting for people to revise and give directions,
PDF in the same place
https://drive.google.com/file/d/1xL0l2rpjPlcgtTsyU6HfuBw3rf6bvVk9/view?usp=sharing

[terjeio]

I can reverse engineer his work but it would be quicker/simpler if he could help?

Here is what I have for now.
Jumpers Nucleo64.zip

[M10CUBE]

Thanks @terjeio . Valuable info on top of what you gave us some days ago. It will be grate help to populate the M10NC01-10 PCB. JLCPCB informed me that the PCBs are shipped. I may have them on Monday. Building it can help on the documentation. Many of them will apply to M10CN02-10 (PICO CNC)

[M10CUBE]

Also maybe it is better not to cascade them but actually just to connect in // the SCK and OUT signal to the enables shift register (less useless shifting to do like that). The enables are normally done outside of the motion sequence so there should be no interference between the 2 shift registers for step/dir and the one for enables.

I am not sure If I understand fully what you mean by that but I will study it more to see your point

Regarding the inputs, Probe have to be connected directly to the CPU has it is a time critical inputs. Door probably also needs to be direct to CPU. However, in my opinion FHOLD and CYST are not as time critical as the 2 previous ones...

OK I will have that in mind and do the corrections.

Another solution for these inputs could be to have another SPI input expander (8 or 16 bits, but 8 should IMO suffice) that doesn't go through the RASPBERRY PI 40 pins connectors but directly to the CPU so that it should be possible to use the PIO to read the inputs really quickly without the need for the CPU. The PIO would wait for the expander interrupt signal, read the input register when the interrupt signal is active and finally create an internal interrupt for the CPU to process the inputs. That would be a very fast way to handle these inputs and save 5 pins at least. I need to think that a bit more thoroughly but I am pretty confident it could work. However, there is also another possibility to make that work by using the second CPU of the Pico to manage the inputs and outputs and unload the first CPU from these tasks.

This is a very interesting point of view and brings on the table the idea I had when using MCP23017 chip and this is the direct pin replacement MCP23S17. That SPI of course. SPI signals from PICO can be placed on 40pin connector. That frees space from main board. All I need is a CS signal.
That way we can have 16XSPI speed M10CUBE I/Os. More can be obtained by adding SPI M10CUBE modules. Here are some questions to be answered.
1 - Can this substitute all High speed inputs without using shift registers?. That will free CPU board from pins to add two more StepSticks or RS485 for the remote control or adding a ESP-01 for WiFi communications
2 - Can other people use this module as a high speed I/O HAT for RaspberryPI?. My answer to that is YES. From day one M10CUBE has all the specs to work as a Raspberry HAT as I quoted here on the wiki page along time ago... "Add on modules must conform with HAT specification as the electric diagram is concerning."
https://gitlab.com/m10cube/m10/-/wikis/home
Careful design with provision for CS pins (maybe at least 4 to accommodate more I/Os) mast take place. Which pins are best to use on Raspberry 40pin connector? What are the best practices?
If we find good that idea I can redesign the I/Os to get the MCP23S17 chip in no time. In fact with a couple of jumpers the modules can be SPI or I2C depending on the configuration and that can be stored on the EEPROM already on the module.
If you find it a working idea, I can have the new I/Os ready at the end of the month.

The PWM should also be connected directly to the CPU because of the Spindle sync or laser sync.

Ok we will leave PWM on board but still I have on the droning board a M10CUBE PWM module. But In fact here is more...that needs some answers.
PWM SPI chip TLC59711 or MC33999 or TLC5940 or LC59711 (Adafruit makes one with this chip)
Worth of doing a module also with SPI PWM ? Do we will have the speed now to use this and free CPU from space?
That is why we need proper placement of the SPI CS pins on the 40pin connector. To have in mind these boards can be used for the Raspberry community as a HAT to their projects. So to comply with M10CUBE nomenclature...reuse

Regarding the 3.3V, I am just a bit concerned that there is no protection...

OK good idea. I got it out. Free some space too.
All the mistakes you find on StepStick age are corrected. Funny I went through the circuit many times without noticing them. Brain games...

[Volksolive]

The idea for the shift registers is to put the 2 shift registers for steps and dir in series and the 1 shift register for enables in parallel of the 1st step/dir register. The advantage of doing that rather than have the 3 shift registers in series is that the code doesn't have to shift an extra 16 bits after the 6 enables data. And this is poss
ible because the enables signal are asserted/reset before / after the step/dir generation takes place, so there would not be cases where both enables and step/dir signal have to be shifted.

Can this substitute all High speed inputs without using shift registers?

The shift registers are there for the step/dir and enables output signals.

The idea with the SPI I/O expander is to only use the I/O expander as input and on dedicated SPI bus because as soon as you use them as output too and multiple of them you'll need a communication buffer to handle the different messages coming from different part of the firmware (main code and ISR code) and also which I/O expander and which CS pin to assert. This slows down the reading of the inputs, which also slows down the reactivity of the firmware when an endstop is triggered while the machine is running.

The same reasoning applies for the PWM, if you have multiple I/O and PWM over SPI being controlled by different part of the firmware, how to be sure that the one controlled by the ISR of the step generation for PWM sync will be prioritized over the others. There might be possibilities in the firmware to prioritize the SPI communication for ISR part of the code though. It would be better to use 2 different SPI for the PWM and the I/O Expander.

Regarding which Raspberry Pi connector pin to use for the CS, an obvious choice is to use the pin that already have the alternative function like pins 24 and 26 for SPI0 and pin 36 for SPI1. Then for additional CS pins it would be wise not to use a pin that has an alternative function. Don't you have a list of already used pins by other M10 module ?

[M10CUBE]

During last days I did a lot of work and I think we have our roads crossed. Here we are...

The idea for the shift registers is to put the 2 shift registers for steps and dir in series and the 1 shift register for enables in parallel of the 1st step/dir register. The advantage of doing that rather than have the 3 shift registers in series is that the code doesn't have to shift an extra 16 bits after the 6 enables data. And this is poss ible because the enables signal are asserted/reset before / after the step/dir generation takes place, so there would not be cases where both enables and step/dir signal have to be shifted.

Yes and this is corrected on latest PDF if anything misunderstood correctly on page "SERIAL"
Correct please if anything wrong.

Can this substitute all High speed inputs without using shift registers?

The shift registers are there for the step/dir and enables output signals.

The idea with the SPI I/O expander is to only use the I/O expander as input and on dedicated SPI bus because as soon as you use them as output too and multiple of them you'll need a communication buffer to handle the different messages coming from different part of the firmware (main code and ISR code) and also which I/O expander and which CS pin to assert. This slows down the reading of the inputs, which also slows down the reactivity of the firmware when an endstop is triggered while the machine is running.

ABSOLUTELY!

The same reasoning applies for the PWM, if you have multiple I/O and PWM over SPI being controlled by different part of the firmware, how to be sure that the one controlled by the ISR of the step generation for PWM sync will be prioritized over the others. There might be possibilities in the firmware to prioritize the SPI communication for ISR part of the code though. It would be better to use 2 different SPI for the PWM and the I/O Expander.

Ok. We will leave PWM for spindle on main CPU as seen on CNC PDF. This case is closed I think. M10CUBE I2C (Or SPI) PWM may be build anyway in future time to enhance the overall functionality of M10CUBE concept. Here is the updated PDF.
https://drive.google.com/file/d/1xL0l2rpjPlcgtTsyU6HfuBw3rf6bvVk9/view?usp=sharing

Regarding which Raspberry Pi connector pin to use for the CS, an obvious choice is to use the pin that already have the alternative function like pins 24 and 26 for SPI0 and pin 36 for SPI1. Then for additional CS pins it would be wise not to use a pin that has an alternative function. Don't you have a list of already used pins by other M10 module ?

Yes indeed. Other M10CUBE modules do not use these pins. I already finished the schematic for the I2C/SPI module. If there is a problem to use the SPI part of the output we can use only the INPUT part and use the output part from another (same type module ) but configure it as I2C OUTPUT and I2C INPUT for low priority.
Is that OK . Still I am thinking other possibilities. There is shortage in the market for chips MCP23S17 SOP-18. Among other hardware like the NUCLEO 64 modules. I am troubling to find solutions to overcame the shortage.
Here is the I2C/SPI module. It only needs routing. But I will start routing when we fix the schematic. I may post a 3D layout tomorrow.
https://drive.google.com/file/d/1fxHiN5NxbgP5qm2ip31o61FZPp1rPZWn/view?usp=sharing
Enjoy...

[M10CUBE]

After puzzling on what @Volksolive said NOT to have the output module on the SPI bus I came up with an idea.
It is not final yet but examining the possibilities and if all agree I will provide the schematics and then try routing the PCB
What this M10CUBEmodule is?
This is the M10DX03-10 8 X INPUTs + 8 X OUTPUTS module
2 separate I/O extensions chips using MCP2308 (I2C) or MCP23S08 (SPI).
The advantage is that any INPUT or OUTPUT part can configured to be used as I2C or SPI depending on the chip used (pin compatibles).
That is INPUT part can use SPI bus and OUTPUT part can use I2C bus. Thus fulfilling @Volksolive demands (SPI for high speed Input and I2C for output)
That way only one board will be used for I/O and not two. Provision for one more on the SPI bus? Yes using some other SPI CS for the second board. That way we will have 16 SPI INPUTS and 16 I2C OUTPUTS
As you can see on another module you can use both chips MCP2308 and have only I2C
The cost using the two chips version (MCP23X08) is the same as using one chip (MCP23X17) . The bonus is that if there is a shortage in the market as it is now for MCP23S17 chip as it is now we can use the MC23X08.
Here is a first draft of the M10DX03-10 module (2 X MCP23X08)

And this is a draft of the M10DX01-10 module 1 X MCP23X017

When you have time please I would like to hear some opinion. We can send for fabrication together with the PICO CNC modules
Keep the ideas coming and I will make it.

[M10CUBE]

There is an issue here regarding the interrupt signals. Multiple module boards means multiple interrupt signals but then if they are multiplexed by a diode for example, the CPU won't know which board has asserted the interrupt. >

Yes indeed and that is why I had a discussion about that with @terjeio here.
terjeio/CNC_Breakout_Nucleo64#3 (comment)
He seems to have a solution of some king but not know exactly. He may give us some "light" is he finds free time.

Nevertheless @terjeio triggered my mind, made some homework and find this interesting post.
https://www.best-microcontroller-projects.com/mcp23017-interrupt.html
That may help to deal with the situation.

TO DO
1 - M10DX03-10 (2XMCP23X08) . Finalize the CS pins for the SPI signals. I must be able to choose CS signal from another two pins in additions to GPIO8 (SPI0 CS) GPIO7 (SPI1 CS). With jumper the user can use another 2 "free" GPIOS. When I say free it is not for M10CUBE modules but to see the various HAT expansion boards in the marker and find what pins are using. If that is too much trouble I will choose two GPIOS that is convenient to me and have these pins reserved from other M10CUBE modules.
2 - M10DX01-10 (1XMCP23X17). Make the above changes on the 1XMCP23S17/MCP02317 module
3 - M10NC02-10 (PICO CNC). Correct and clean up the module (RS485, and make all the hardware on boars to be used as a remote control module to a PICO CNC module. For that I have now remaining pins for some switches and knob encoder to be used on the remote control plus IC connector for I2C keypad. So PICO CNC module depending on the population on board to be used as a CNC controller or CNC remote control wired (RS485) or wireless with the adaption of a ESP-01 module. I would like to have some thoughts for this idea.

The way you have designed the board now with the MCP23X08, you have space for 2x8 inputs with 2 separate int signals which work but you can't add more module.>

Just to make a note the 2X MCP23X08 module can have 8XINPUTS + 8XOUTPUTS. Each INPUT/OUTPUT can use I2C (MCP23008) or SPI (MCP23S08) chip. Tomorrow I may finish and post a more detailed draft for all three boards to see any errors.
As I said my intention is to have these boards finished at the end of the month and send them for fabrication. I hope you can make all the modifications on the GRBLHAL. I can sent you a set of bare boards if you like. That goes for @terjeio too.

[Volksolive]

Another issue with this setup is that you can’t have the sensorless endstop with the TMC drivers. You’ll need a connector between the Pico module and the I/O module.

I checked the link you mentioned, all the interrupt signals are configured as open drain and connected together with a pull-up resistor. Their solution is to read all of the I/O expanders interrupt flag register to find which one triggered the interrupt. I think, as long as the first I/O expander is the one where the time critical inputs are connected it should be fine. However, there are still the possibility that multiple I/O expander have triggered the interrupt at the same time but this can be handled in Firmware.

The nice thing about the MCP23x is that they can have a dedicated address in I2C and in SPI which means one CS signal can manage multiple MCP. But of course having more CS signals is a good think for other modules !

For the Pico remote control it would be nice to have a screen connected to it. That can be achieve with the I2C connection or SPI connection even UART connection!

regarding the Pico module, is there a reason why you have removed the 0-10V spindle signal?

There is signal labeling issue on the connector LK15 (stepstick Axis C) labeling should be SDOt instead of SDIt. Also SPI signal on stepstick axis A should be SPI1_TX instead of RX and on the connector LK2 SPI1_RX instead of TX.

For the shift registers signal SR0_LCK should be common for the shift registers connected in series (the 2 on the left side) and SR1_LCK for the one on the right side.

[M10CUBE]

Another issue with this setup is that you can’t have the sensorless endstop with the TMC drivers. You’ll need a connector between the Pico module and the I/O module.

The solution I propose here is to use the connectors JPA and JPB on PICO stage (page2)
These connectors have direct access with I/O modules. Signals are going directly after isolation as explained before. Connector on I/O module goes where indicating LEDs are on the edge of PCB. That is 8 inputs from the 8 input + 8 output module.
We can always build a 16 inputs module if we want more direct inputs to PICO module.
That can also be used in remote module to accommodate switches.

I checked the link you mentioned, all the interrupt signals are configured as open drain and connected together with a pull-up resistor. Their solution is to read all of the I/O expanders interrupt flag register to find which one triggered the interrupt. I think, as long as the first I/O expander is the one where the time critical inputs are connected it should be fine. However, there are still the possibility that multiple I/O expander have triggered the interrupt at the same time but this can be handled in Firmware.

The nice thing about the MCP23x is that they can have a dedicated address in I2C and in SPI which means one CS signal can manage multiple MCP. But of course having more CS signals is a good think for other modules !

Ok I am thinking 2 more INT signals. PICO has some free pins now. See on schematic (GPIO3,GPIO7,GPIO8).
To be able to accommodate on more I/O module. I think that is more than enough.

For the Pico remote control it would be nice to have a screen connected to it. That can be achieve with the I2C connection or SPI connection even UART connection!>

I placed a connector for I2C display and next I will place one for SPI display. If we use the PICO CNC as a remote control there are many pins free to use SPI LCD. That is for TODO.To together with any nice idea that help us to do a high tech remote control. I am imagining a " CUBE REMOTE CONTROL"

regarding the Pico module, is there a reason why you have removed the 0-10V spindle signal?

I did that because 0-10Volt was not isolated. I made a not now on spindle page what way can we incorporate that. That will be the easy part.

There is signal labeling issue on the connector LK15 (stepstick Axis C) labeling should be SDOt instead of SDIt. Also SPI signal on stepstick axis A should be SPI1_TX instead of RX and on the connector LK2 SPI1_RX instead of TX.

For the shift registers signal SR0_LCK should be common for the shift registers connected in series (the 2 on the left side) and SR1_LCK for the one on the right side.>

Thanks I corrected all theese now but you never know. Have a look on the revised PDF in the usual links
M10NC02-10
https://drive.google.com/file/d/1xL0l2rpjPlcgtTsyU6HfuBw3rf6bvVk9/view?usp=sharing

M10DX03-10
https://drive.google.com/file/d/1gsIQwHnfET--QKSHRnmEgUoBHrH9m3-p/view?usp=sharing
Enjoy

[Volksolive]

Couples of corrections and reflections on the M10NC02-10:

On page 3

• 3V3_BUS must be disconnected from 3.3V out pin 36 also decoupling capacitor C200 3.3V not needed
• LED should be connected to +5V instead of 5V_BUS
• PRB on pin 19 and FHOLD on pin 20 not needed because they will be connected to SPI and I2C input module
• Is Reset pin 29 really needed? can't 'RUN' be enough for the reset?
• Is the buzzer really needed? if yes, needs to be connected to Pico pin
• PRB and RESET on connector JA not needed
• RX and TX on pin 1 and 2 are not breakout on a connector, also can't they be used for RS485 also so 2 pins are saved ?
• Label on SD card must be changed from SR1_SCK to SPI1_SCK
• Since there is empty pins the SD card should be connected to a second SPI to give the 1st SPI priority on the inputs reading

On page 4
Everything looks fine

On page 5

• Shift register to the right side must be connected to SR1_LCK and LCK label removed, also all the enable signals must be connected on that SR
• SR to the left side must be all Step signals and the one on the middle all dir signals
• I am wondering if the unused QH output should be tied to ground through a resistor?

On page 6

• Is something like that what you mean?
  

[M10CUBE]

OK took me some time. Three modules had to manipulate the same time

Couples of corrections and reflections on the M10NC02-10:

On page 3

Done

* Since there is empty pins the SD card should be connected to a second SPI to give the 1st SPI priority on the inputs reading

No free pins as you can see becouse 6 separate signals are provided to 40 pin RASPI as noted in page 2.
BELOW SIGNALS ARE CONNECTED TO
RASPI 40 PIN CONNECTOR

INT_0
INT_1
INT_2
SPI_BUS_CS0
SPI_BUS_CS1
SPI_BUS_CS2

RASPI HAS PROVISION FOR MORE SIGNALS FOR MORE I/O MODULES
IF MORE PICO PINS FREED
INT_3,INT_4,INT_5,SPI_BUS_CS3,SPI_BUS_CS4,SPI_BUS_CS5

Thus SD still on SPI1 but we can see what solution can be found.

On page 5

Done

* I am wondering if the unused QH output should be tied to ground through a resistor?

On the datasheet is left unconnected but if you know something we will see.

On page 6

Yes indeed. As you see to save space I have some components shared with jumper.

as usual
M10NC02-10
https://drive.google.com/file/d/1xL0l2rpjPlcgtTsyU6HfuBw3rf6bvVk9/view?usp=sharing
3D is here
https://hackaday.io/project/171770-m10cube/log/202098-m10cube-pico-cnc

I did many corrections to
M10DX03-10
https://drive.google.com/file/d/1gsIQwHnfET--QKSHRnmEgUoBHrH9m3-p/view?usp=sharing
3D is here
https://hackaday.io/project/171770-m10cube/log/202613-m10cube-i2cspi-input-8x24v-output-8xhigh-side-double-io-chips

M10DX01-0
https://drive.google.com/file/d/1fxHiN5NxbgP5qm2ip31o61FZPp1rPZWn/view?usp=sharing
3D is here
https://hackaday.io/project/171770-m10cube/log/202611-m10cube-i2cspi-input-8x24v-output-8xhigh-side

Changes were on the jumper settings due to new SPI CS and INT signals on 40pin
Now we have to choose between 3 INT 3 SPI CS signals . So more modules can be access individually.
It is complicated circuit and may be I made mistakes. So please check when you find time.

Tomorrow I will make here an announcement (first time in public with this detail) here for a radical direction concerning the future development of M0CUBE.
That is necessary to follow the new trends.
Take care

[M10CUBE]

As I promised I am making the announcement here and is presented for the first time publicly
https://gitlab.com/m10cube/m10/-/blob/master/README.md
The idea triggered my mind when @Volksolive said to use RP2040 because of more pins available.
To extend that I propose to have RP2040 chip on board instead of the MCP23XXX chips. Not only as I/O extender, but as any slave PWM, A/D, D/A needed.
Here is a python library that makes RP2040 any I/O remote devise we like.
http://abyz.me.uk/picod/index.html
The chip is dirty cheap and widely available for less that a Euro without shortages.
You had a strong point @Volksolive by proposing the chip. I simply extended your decision. A demo Design can be found KiCad format.
The already designs on the drowning board with the MCP23XXX will be finished but in parallel I will make an I/O module using Pico module and post it for verification.
I am hoping to send this one together with the other boards for fabrication during February. That will be a quick and dirty approach to start experimenting immediately.
Then we will proceed substituting Pico with RP2040 on every M10CUBBE module.
We may need some help for PCB routing. The project will be huge but I am sure it will worth the afford. Just by programming the chip we will get a different slave Interface.
How that sounds?

[M10CUBE]

PICO ETHERNET. Found today in my mailbox from MAGPI magazine.
https://docs.wiznet.io/Product/iEthernet/W5100S/w5100s-evb-pico
or a HAT version so original RAS Pico can be used
https://docs.wiznet.io/Product/Open-Source-Hardware/wiznet_ethernet_hat
I think we must examine the idea on using it instead of original PICO (or to have them both as a choice using the HAT version)
when this is on some of the GPIOS used by our project are occupied. Here is the GPIOS used by Wiznet PICO Ethernet

GPIO16 | Connected to MISO on W5100S
GPIO17 | Connected to CSn on W5100S
GPIO18 | Connected to SCLK on W5100S
GPIO19 | Connected to MOSI on W5100S
GPIO20 | Connected to RSTn on W5100S
GPIO21 | Connected to INTn on W5100S
GPIO24 | VBUS sense - high if VBUS is present, else low
GPIO25 | Connected to user LED
GPIO29 | Used in ADC mode (ADC3) to measure VSYS/3

That will give Ethernet connection between PICO CNC CONTROLLER and PICO remote controller
Am sure next PICO board or on the core of RP2040 chip will have some kind of Wireless communication by (WiFi or Bluetooth or MATTER) by default.
Now the CANBUS idea on board.
That will be a bonus to every new I/O with RP2040 on board.
here are some we can inspired from:
https://www.seeedstudio.com/CANBed-RP2040-CAN-Bus-development-board-p-5262.html?utm_source=cnx_software&utm_medium=link&utm_campaign=cnx_software

as well and here is an add on PICO:
https://www.cnx-software.com/2021/05/26/canpico-open-source-board-adds-can-bus-to-raspberry-pi-pico/

As you realize our first design "PICO on board" (before we put RP2040 on board) can use immediately out of the box these two modules.
Nice and practical addition to our line of M10CUBE interface modules
PR2040 and PICO form factor is gaining hype. That is good because M0CUBE investing on PICO and PR2040 has a solid ground

[M10CUBE]

@Volksolive @terjeio @phil-barrett

There is an important matter to contact with you as soon as possible for a very interesting proposal. That came out yesterday and has a time out frame not set by me of course
So please sent me an email to contact with you because I can not find a way to do in privet through GitHub
my email vorrias.argo@gmail.com
I will answer immediately
Thanks a lot

[M10CUBE]

I am excited to announce here the following:
After a long time working endless hours on our WIZcube project we see it submitted on time to the WIZnet contest.
Two Makers, ​ total strangers between them one in Greece Vasilis Vorrias and other in Denmark Olivier Gaillard teamed up to go for the WIZnet contest and submit the idea before closing.
https://maker.wiznet.io/wiznet-ethernet-hat-contest/​

We shared the same dream to build something different. Something to be useful to the community as being an OSHW project.
It is a huge project and we must finish everything by the end of March.
During the building period it will be more info on our web www.wizcube.eu​

[M10CUBE]

WIZcube PCB fabrication
Four WIZcube PCBs sent for fabrication . While waiting for the delivering, the team members Olivier and Vasilis are preparing the firmware
https://hackaday.io/project/171770-m10cube/log/204587-wizcube-pcb-fabrication

[M10CUBE]

We are happy to announce that our www,wizcube.eu project won the second prize in wiznet contest.
https://maker.wiznet.io/wiznet-ethernet-hat-contest-winners/

Our team is preparing some work to sow, how wizcube really works in real life projects.
https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS

PROJECTS ON HEAVY DEVELOPMENT
1 - CNC CONTROLLER https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS
2 - GREENHOUSE https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS/GREENHOUSE

Please keep this link handy and see interesting real life projects updating nearly every night.

[M10CUBE]

We are happy to announce that our www.wizcube.eu project won the second prize in wiznet contest.
https://maker.wiznet.io/wiznet-ethernet-hat-contest-winners/

Our team is preparing some work to sow, how wizcube really works in real life projects.
https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS

PROJECTS ON HEAVY DEVELOPMENT
1 - CNC CONTROLLER https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS
2 - GREENHOUSE https://gitlab.com/m10cube/m10/-/tree/master/PROJECTS/GREENHOUSE

Please keep this link handy and see interesting real life projects updating nearly every night.

[wakass]

Hey thanks,

I found some SMT connectors that seem to fit the bill and i can receive within not-too-short a time. I already had the boards from JLCPCB in hand when last time i wrote.
For those interested: https://nl.aliexpress.com/item/1005003082452815.html, or harwin M20-7862042 or samtec SSM-120-L-SV (mouser/farnell)

I am now looking to find the minimal working configuration to drive some stepper-motors and a laser. This is my use case so far: XY,Z-stage for focus, laser drive, and a optionally a probe to do bed/workpiece-mapping. I'm also planning to use tmc2209 drivers for possible sensor-less homing, potentially as a replacement for a probe to do workpiece-mapping.
With regards to minimum-viability, looking at the design, I think I can leave out at least the canbus controller, spindle controler, and external raspberrypi connector. I will def. need the shift registers and some transistors, but I haven't made the full stripped-down list yet. I also assume I am able to drive the pico through serial-over-wifi (I tested this already with a prelim setup using GRLBHAL, works well!). Any thoughts what is minimum viable for this?

I also would ofcourse be happy to test out a fully populated board :) I do live in europe, but have limited time so things might be slow.

Best,

WakA

[M10CUBE]

Ok @wakass . Good to know the peculiar" footprint understood and you find the way around.

"...I'm also planning to use tmc2209 dr.."

Nice thought because as you see our I/O module is away of the the main board. That can be as a I2C to the main bus (in this case we emulate the PICO on the I/O module to be an I2C I/O expanded) or via WiFi using a PICO W module.
That way we can increase practically indefinably the I/OS. The problem rises when we wont to insert homing switches into the main CNC containing the stepstick drivers because they need the inputs from home switches. To overcome this problem we made an interconnection between the two boards (in place where the INPUT state LED are. That is a rather complicated PCB design and I am thinking not to have it inn the future.
In that case the sensor-less tmc2209 is a nice choice. We see how it goes.

Canbus and RS485 putted there just for experimentation. There is no need now to use the complicated Can-bus. We have Ethernet (Wireless or wired) . It is faster and easy to implement. Not to mention 10BASE-T1S . This is 2 wire Ethernet 10MBPS without the need of a switch. They are using now in the automotive Industry. I am planning a Raspberry Pico module with 10BASE-T1S on board as a direct plug in replaceable of a normal Raspberry Pico. Thus every wizcube module can have it on board.

"...I also assume I am able to drive the pico through serial-over-wifi (I tested this already with a prelim setup using GRLBHAL, works well!). Any thoughts what is minimum viable for this?..."

I assume want this to make a remote control? Anyway I have finished (some trimming needed) the CNC remote control but needs routing.
It will be a wireles (WiFi) CNC remote control. Unfortunately other obligations made me to step aside for a while. But it is nearly finished. I can upload the work done some time.
You can see it here:
http://wizcube.eu/cnc.html

"... I also would o fcourse be happy to test out a fully populated board :) I do live in europe, but have limited time so things might be slow..."

Living in Europe it is easy to sent you by normal post some components urgently needed. I will try to populate mine as well so to exchange experience and the design the next version.
I hope some others whiling to help as to finish this project.
Think it not only as a CNC controller but can be the basis of a robot or autonomous vehicle in the future due to its expand ability without limits in I/O or sensors as being a truly modular design.

Regards
Vasilis

[wakass]

Hey @M10CUBE/vasilis,

I've started cleaning the design, making things a little more clear for myself in the process. WIP is found here https://gitlab.com/wakarimasu/m10/-/tree/cnc-cleanup

Finding that a lot of the libraries/symbols/footprints are not included in the gitlab repo. So i've also cleaned that up partially. Will let you know how it progresses.

Cheers

[M10CUBE]

Hi @wakass . I really appreciate your afford . That means we are going fast forward. Having said that I am surprised that not any footprint in order. That is because When KiCAD project saved we did it the normal way. That is File/archive project. That produced a zip file. That is the file I uploaded into GITLAB.

Because bad things happened all the time I really want to take a look on the original archived zip project to see if that is a problematic as well.
I am saying that because from that schematic we produced the PCB file for the M10NC02-20 module.
https://drive.google.com/file/d/1fgP5-4F84jjZ3v6jOPA-AunyeMryle9D/view?usp=share_link

This is important to know because if the archive method produces problematic project with missing footprints I must know.
My knowledge of the Gitlab / Gihub are a bit limited (but I am still learning) and I am not familiar with the term WIP. Sure I can learn from you.
Somehow I must see what was the wrong on the schematic and I can not see how to compare the "wrong" with the corrected.
Petty @Volksolive is not with us. He is the guy we have been together in all that. I am hoping to see him again. I am not convinced he lost interest that sudden since he made the PCB working as you can see on the video.
Take care
Vasilis

[wakass]

All good. WIP==Work in progress.

The footprints are there in principle, but they reside in the cache. This makes it rather difficult to edit. The libraries, IOEngineering e.g. are just not present, and the project specific libraries (Found under preferences -> Manage Symbol/Footprint libraries of EESChema and PCBNew, respectively) referenced local paths in some cases.

[M10CUBE]

OK I see. What are you suggesting for me to do to make life easier (and that counts for future releases). To copy all libraries used in a different zip file? Then you can put them in the path. What is the appropriate job? I am getting frustrated if someone spends time (you) for something that somebody else did it (me). It is waste of time (and time is something can not by) So give me directions, I will follow and help you in the process. Thanks a lot

[wakass]

I don't know what zip-files you are referring to. The libraries are simply files, in the project folder (or subdirectory). (kicad_sym files and .kicad_mod) As long as the files are bundled with the project in a coherent manner, there's no problem.

In any case, I've managed to assemble the board partially with a minimum viable configuration. Made some bugfixes to the pinout (see repository). After now wrangling with some code-issues (some own stupid mistakes, missing docs, out-of-date configuration in this repo for the picocnc), I think it's in a state that's it's nearly testable. Hope to test soon.

[M10CUBE]

Nice work @wakass . I am waiting for the results to build mine. Please inform me if any news.
You said that you made the KiCAD corrections on the repository. Can you please send me the link?. I can not see where are the corrections. I am not very good with Github.
Thanks a lot
Happy new year
Vasilis

[wakass]

hey @M10CUBE,

you can find corrections to the schematic here
The most severe error was the shift-register pinout order for SR1. I've bodged my board with some jumper wires to correct it.

I've started collecting my work on the grblHAL side of things over here It's a very minimal configuration for now.

I also have now finally tested the board in its entirety (well...the z-axis), and it seems to work! :)

Best, waka

[M10CUBE]

I see the problem @wakass . Continue doing the tests and see what else is not right. Then we will make an update to KiCAD and resent for fabrication.
I am feeling proud that someone found our design worth of spending valuable time on it. Nice color too.
I hope @Volksolive when see it will be satisfied.
Then we will redesign the nearly finished CNC remote control. Now with Pico W that will be wireless CNC remote control. But first things first. To make it work. I will be available when you add all the axis to start making it. My heavy duty CNC is waiting ...
Take care

[M10CUBE]

Hi @wakass . I finally found some time to continue my M10NC02-20 PCB soldering and start using the CNC already build. Do you have any updates on firmware?
This is crucial to make it work before start tinkering myself with the firmware. A hard job for me to be honest. I have to do many M10CUBE (WIZCUBE) updates using new KICAD V7 .
Any feedback I will greatly appreciate it.
Still I am calling for my friend and distributor @Volksolive to hear from him. He did a lot of work on this project.
Thanks

[wakass]

My configuration is working pretty solidly with the current configuration and fork over here: https://github.com/wakass/RP2040/tree/picocnc-wip
This is with the tmc2209 sensorless homing and the manual bodge on the shift-register as mentioned previously.

• As you probably won't have sensorless the config will look a little different. (Mostly dropping the lines with TRINAMIC_ will do)
• The spindle configuration and cooling might be different. The old pico_cnc_map.h refers to flood/mist etc, but the board doesnt provide for it as far as I can see. It might just work out of the box if you have the electronics wired up.

Cheers

[M10CUBE]

Good news @wakass.

I have the TMC2208 stepstiks but I can have the TMC2209 in 10 days. There is V1.3 and V2.0 Is any difference between? I can have V1.3 earlier and is 2 euros cheaper.
Having said that I but some more info here, so to give me a hand to proceed and fully populate the M10NC02-20 PCB
1 - How far did you go in populating the board? 4 or six axis working?
2 - I will go first installing the TMC2209. That way I will install your firmware as is.
3 - Then next step is to drive directly the stand alone drivers I am working with DM556 at the moment attached to Arduino UNO. At this point I have in stock the interface PCB made from @terjeio to be in place of the stepsticks.
4 - How I will download your firmware? Do I have to do it using VSCODE? I suppose I can not use the WEB BUILDER @terjeio told me (or can)
Sorry about that but it is the first time uploading GRBLHAL.
As far as spindle configuration the board provides just the spindle control (and I have all the components to solder).
For flood/mist we can use the I2c bus and make use of the I2C/expansion. I have another PCB the M10DX01-20
https://gitlab.com/m10cube/m10/-/tree/master/ELECTRICAL/INPUT%20OUTPUT/M10DX01-20
That is 8 inputs and 8 transistor outputs. Both optoisolated. Already build and working.
This board has a PICO on board. The idea is to load a simple firmware and make it I2C slave making the CNC PCB (M10NC02-20) I2C master. I even have provision for 2 interrupt lines in the 40 pin connector exactly for that reason.
On top of that I have provision the M10DX01-20 PCB to have direct connection from the M10DX01-20 INPUTS (after the opto) with the TRINAMIC homing inputs on the M10NC02-2 PCB.
We did that to provide homing inputs. But in case of sensorles is not needed.

Another option and that was the one we concluded with @Volksolive was to have communication between the I/O modules using Ethernet.
Then came the WiFi Pico and everything is simpler. Now we can have all the extra I/O needed using the modules M10DX01-20 or the relay module M10RL01-20

https://gitlab.com/m10cube/m10/-/tree/master/ELECTRICAL/OUTPUT/M10RL01-20

Thus PICO W on board and TCP/IP communication between modules. The Idea @Volksolive proposed was Modubus TCP/IP but someone must put that into the GRBLHAL code

These modules already working fine on separate projects with ESPHOME and Home Assistant in my Home.

I am planning some new versions to cope with the extra needs (like AC triac control) plus making some corrections to old designs.
That way M10 concept I/O boards can be used both in CNC or in Home Automation with ESPHOME and Home Assistant.
If others contributors came in M10 concept can be a really useful to everyone. We can share the enclosures as well. We have some already build but trimming is needed.

That is it for the moment.
Waiting for your response and thoughts if you can find some free time.
Take care

[terjeio]

I suppose I can not use the WEB BUILDER @terjeio told me (or can)

Not until the changes are merged. BTW the pico_cnc_map.h file is for Phil's board so that cannot be modified in a merge.
Programming is simple when a binary is available, connect USB while the BOOTSEL button is pressed and drop the file on the drive that appears on the computer.

Another option and that was the one we concluded with @Volksolive was to have communication between the I/O modules using Ethernet.

The Pico W cannot be used for ethernet without an external module such as the W5500 - this requires a SPI interface plus two control pins on the Pico.

The Idea @Volksolive proposed was Modubus TCP/IP but someone must put that into the GRBLHAL code

Projects implementing Modbus TCP/IP for lwIP raw mode can be found on github, code can be adapted for grblHAL? Here is one project.

[M10CUBE]

Thanks @terjeio for your remarks.
While trying to populate your board looks that @wakass moved on. So I have to populate both boards to have a better chance of success.

Now:
1- For PICO CNC board M10MNC02-20 since I never did a GRBLHAL upload before I will see what @wakass did and guide me trough to do exactly the same procedure for uploding. After first time, it will be simple for me for later uploads. In the process I have to understand where every info is located in the GRBLHAL firmware ( I got one info here from you - pico_cnc_map.h - ). I need to educate myself in the GRBLHAL and I will do it in the process. That way I can contribute better on the PICO M10MNC02-20 hardware. Already @wakass made some corrections and I am looking at them.

2 - As far as Ethernet concerns, this is not a problem because the all M10 modules are designed to use the W5100-EVB-Pico or W5500-EVB-Pico or W6100-EVB-Pico, or a normal PICO + WIZnet Ethernet HAT.
(https://www.wiznet.io/product-item/w6100-evb-pico/).
We used the W5100-EVB module and we got the second prize on the WizNET contest last year. Working like a charm.
Using them as a drop in replacement of the PICO on the M10NC02-20 and in every M10 I/O board we have very easy Ethernet on board. Same applies for PICO W of course.
So TCP/IP is a choice that I think can be evaluated here. It was our concern from the beginning when designing every board. Ethernet (Or WiFi) brings interrupt as well so no input is missed by the CPU.

You already pointed out a project but I am not software expert and it is kind of difficult for me at this moment becouse I have to spend a lot of time to see how I can do it. We need someone with the knowledge here to contribute on that.
If we succeed it will be the first CNC PICO GRBLHAL (or any GRBL) controller with 6 Axis and unlimited I/OS. Worth of trying.
I am also preparing a remote control as well
In a later time anyone can substitute the RP2040 with another CPU (eg STM32) and make another CNC controller using the rest of the subsystems intact. Little KICAD work and firmware tinkering and a new boards can be born.
Thanks again for your time spent
regards

[terjeio]

As far as Ethernet concerns, this is not a problem because the all M10 modules are designed to use the W5100-EVB-Pico or W5500-EVB-Pico or W6100-EVB-Pico

Ok, those are not Pico W boards ;-)

So TCP/IP is a choice that I think can be evaluated here.

You will need to add grblHAL code to handle that, and include the lwIP driver from the Pico board supplier (I assume that it is available).
FYI I recently fixed up the ethernet code for the ESP32 - parts of that can be reused. Parts of the STM32F7xx enet.c code may also be useful - as the driver is not running under FreeRTOS like the ESP3 one does.

If we succeed it will be the first CNC PICO GRBLHAL (or any GRBL) controller with 6 Axis and unlimited I/OS. Worth of trying.

I have already made a 8 axis board map for the STM32F7xx driver, but no breakout board for that exists yet. When I get time I will make one...

[M10CUBE]

Ok, those are not Pico W boards ;-)

Yes this is the module I use. About 10 Euros
https://www.wiznet.io/product-item/w5100s-evb-pico/
here is M10NC02-20 with wiznet module.
https://gitlab.com/wakarimasu/m10/-/tree/master/ELECTRICAL/CNC/M10NC02-20.
Not tested on the CNC but will work since SPI and Interrupt lines working. I/O modules working fine with the wiznet module

You will need to add grblHAL code to handle that, and include the lwIP driver from the Pico board supplier (I assume that it is available). FYI I recently fixed up the ethernet code for the ESP32 - parts of that can be reused. Parts of the STM32F7xx enet.c code may also be useful - as the driver is not running under FreeRTOS like the ESP3 one does.

I have already made a 8 axis board map for the STM32F7xx driver, but no breakout board for that exists yet. When I get time I will make one...

Looks that you already did a nice work. Let us see if @wakass can help and combine everything into the M10NC02-20
Meanwhile I am populating your board . I have transferred it If you remember into M10 form factor. Here is the board M10NC01-10
https://gitlab.com/wakarimasu/m10/-/tree/master/ELECTRICAL/CNC/M10NC01-10
Hopping @wakass to jump in for the M10NC02-20 PCB Ethernet / WiFi implementation

[terjeio]

I am not sure the W5100 (or W5300) is a good choice for grblHAL as the network plugin code is based on the lwIP raw API. It is a rather large job to write/test a new plugin based on a socket API so unless there are lwIP drivers available for these chips then you are stuck? The W5500 is better as it has lwIP drivers available, the ESP32 driver code uses the one from Espressif and that seems to work ok.

It is a pity that the WizNet RP2040 modules do not use the SPI port that the Pico W uses - the port/pins used for WiFi were not brougth out on the Pico making the Pico W pin compatible with the Pico. The WizNet modules claims 6 "standard" pins instead:

[M10CUBE]

It is a pity that the WizNet RP2040 modules do not use the SPI port that the Pico W uses - the port/pins used for WiFi were not brougth out on the Pico making the Pico W pin compatible with the Pico. The WizNet modules claims 6 "standard" pins instead:

May be this is an advantage because Wiznet HAT + PICO W can coexist making a bridge. On M10NC02-20 (or any M10 module) boards I have those pins left for the wiznet module.
We see how it goes...Have in mind that 2 wire 10MBPS Ethernet is out now. Need no switch to connect many Ethernet modules together. Connect them as in a CAN or RS485 bus

[LoganFraser]

is there a rs485/modbus driver converted to grblhal/pico use yet? I haven't found one.

[M10CUBE]

@LoganFraser I do not know but maybe @terjeio can answer that. The RS485 hardware is already on the M10CUBE PICO CNC (M10NC02-20) as seen from the schematics . When GRBLHAL is ready that can work immediately on the M10NC02-20. Can Bus is already there as well (but I prefer RS485 communication).

[terjeio]

is there a rs485/modbus driver converted to grblhal/pico use yet?

No conversion is needed, adding the spindle plugin and the needed config option/init code to the driver is all that is required.

[M10CUBE]

Nice to know that @terjeio . I am doing final trimming on your nucleo breakout and doing some milling. Working like a charm.
I have some problems with accuracy (only on x axis but I am resolving it) in exporting the GCODE from FREECAD Path workbench.
Waiting for @wakass to see how it goes. Then I will try M10CUBE PICO CNC (M10NC02-20) with the RS485 on that with a Toshiba inverter.
Keep doing chips...

[terjeio]

is there a rs485/modbus driver converted to grblhal/pico use yet?

Sorry about wrong answer - it is, enabled in the standard way for VFDs by uncommenting this line and possibly changing the value. If you want to use modbus with your own code then add #define MODBUS_ENABLE 1 to my_machine.h. Note that the board has to have support for a free serial port for it to work.

[LoganFraser]

I'm looking at the skr pico as a low cost/small size controller for use with the printnc mini. It has Uart0 - GPIO0-1 on a breakout header, so it needs an external uart-rs485 adapter.

[M10CUBE]

@LoganFraser here is a space about M10CUBE PICO CNC based on the M10NC02-20 PCB which is already constructed with on board RS485. Please let us stick on that otherwise we will loose track.
Anyway M10CUBE PICO CNC has complete different approach that the skr pico (or any other controller). The M10CUBE PICO approach is lined up with the idea based in industrial controllers (PLC).
I feel confident of this direction of the design after many years in Automation Industry.
Not to mention the latest addition in Arduino family the Arduino Opta RS485 and the PLC key Portenta Machine Control.
All roads drive to my original idea posted back in 2011 here:
Turn Raspberry Pi into a P.L.C
We need more contributors to the idea and we will make something unique. That is an Open source powerful and expandable PLC easy to construct by any Maker.
enjoy:
https://gitlab.com/m10cube/m10
Regards

[M10CUBE]

Ηι @wakass .
Good news from @terjeio. Just inform me that he finished porting the WIZnet driver for RP2040
https://github.com/grblHAL/Plugin_networking/tree/6efb2e29f2d2a9f133ae38a814e15c43539917e2
That means our WIZcube M10NC02-20 module can be Ethernet enabled.
He asked me to provide the board map for the M10CUBE PICO CNC and then he can send us a W5100S binary to try.
Further more that will help hip to provide the firmware for the Web Builder.
I am not really sure how can I privide that since I involved most on the hardware part of the design and left the firmware for the @Volksolive .
I can not spot @Volksolive and that is pity. Can you please provide that and let me understand the procedure.
@terjeio gave me a clue but that must come from a guy with a knowledge.
If we do that we can have our 6 axis CNC PCB working and updating via Web Builder I suppose.
Thanks

[M10CUBE]

Hi Guys. I know I have been missing a long time but other obligations took me away.
Did anybody finished working the M10CUBE PICO CNC?
I did not make the board waiting for someone else to give it a try.
Anyway at the moment I am working with @terjeio CNC Breakout board for Nucleo-64 (M10CUBE form factor)
Thanks

[M10CUBE]

I have started a discussion for an MPG using only 2 Picos. It is an approach started 2 years ago with only some hours spent on the idea.
Considering the interest on that I think it will be an interesting approach, useful to the community.
#92 (comment)
Please comment if you have some spare time. It is nice to know that I am on the right track
Thanks