6-pack CNC controller

[dixi83]

Hi all,
I have a "6pack CNC Controller external driver" board over here... It is originally designed by the creator of FluidNC and developer of grbl-ESP32 bdring.

As far as I see it now it should be possible to run grblHAL on it!
Where do I get started?
Is it only a matter of creating a *_map.h file to the pin-out of the board and adjust the config.h file to my needs? Or is there more involved?

https://oshwlab.com/bdring/6-pack-2-0_copy

[terjeio]

You can try the Web Builder version.

[dixi83]

Thanks,
Is the "bdring 6-axis i2s" the same as the board as the 6-pack "family"?

I am asking this because "6-pack" is the official naming and it is not mentioned anywhere....

[terjeio]

I belive it is the same, it is nearly three years now since I added the map so perhaps it would be wise to check it against a schematic? The schematic I have and which I likely based the map on is named "ESP32 SPI 6 Axis", this may have changed after the rename of Grbl_ESP32 to FluidCNC.

[dixi83]

Thanks for your reply,
I checked the *_map.h file according to the schema. The XY and Z outputs are correct with my board, the inputs need some adjustments... the ABC axis are changed as well. I can make a map file for this particular board of course but it also has optional cards... how can we handle this? I mean for my specific situation it quite clear to me now, but to help I'd like to check out all the available boards and make a map/config/cmakelist file with the options available and do a PR.

[terjeio]

I'd like to check out all the available boards and make a map/config/cmakelist file with the options available and do a PR.

That would be great!

[dixi83]

Hi Terjeio,
I created a new _map, added it to the driver.h and the CMakeLists.txt. I adjusted some settings in the CMakeLists.txt (enable Wifi, WebUI and SDcard) It compiles without errors but it does not seems to boot...
The serial monitor gives this output (The POWERON_RESET was triggered by by me with the reset button):

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1492
load:0x40078000,len:13040
ho 0 tail 12 room 4
load:0x40080400,len:3016
entry 0x400805e4
␀

https://github.com/dixi83/ESP32/blob/master/main/driver.h
https://github.com/dixi83/ESP32/blob/master/main/CMakeLists.txt
https://github.com/dixi83/ESP32/blob/master/main/bdring_i2s_6pack_ext_v2_map.h

What can be wrong?

[terjeio]

I did not update the original file for I2S out as I should have done (I assume the mks_dlc32_2_0_map.h is ok), try this:

bdring_i2s_6pack_ext_v2_map.zip

At least it is starting up as it should.

[dixi83]

I tried the file you provided, the only thing that has changed is the ␀ character is gone now. No clue what that means 😉
If i check the schematics of the MKS_DLC32_v2.0 It has only 1 shift register (on page 2, type undocumented).
On the board i have here and also the 6axis board have here, there are 4 74AHCT595PW,118's in series
Can this be related to the boot issues I'm facing?

I corrected the SD card pins as well (not pushed yet) They should have GPIO_NUM_xx but this was not the solution...

[terjeio]

Odd, I have the controller booting with the new map file:

GrblHAL 1.1f ['$' or '$HELP' for help]
[VER:1.1f.20230601:]
[OPT:VNSL,35,1024,3,0]
[AXS:3:XYZ]
[NEWOPT:ENUMS,RT-,REBOOT,TC,SED,RTC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:ESP32]
[DRIVER VERSION:230511]
[DRIVER OPTIONS:v4.3.1-dirty]
[BOARD:BDRING 6-Pack External drives V2.0]
ok

I did not enable anything but the board in CMakeLists.txt, perhaps you should try that as well?
BTW, which IDF version do you have? Espressif has a habit of introducing breaking changes in new versions. 4.3 is the one that is known to work with grblHAL.

The binary I flashed:

app-template.zip

On the board i have here and also the 6axis board have here, there are 4 74AHCT595PW,118's in series
Can this be related to the boot issues I'm facing?

I do not think so. The shift register is a "dumb" device - the microcontroller is just sending data to it and has no idea if it is working or not (or how may there are in the chain).

[dixi83]

Sorry I just found my mistake.... in CMakeLists.txt I twisted the definitions...

Sorry for wasting your time this morning....
I found this because nothing was changing... I got the feeling that it was still picking the old map file. So I commented out the whole "old" file and suddenly there where compile errors.

It is booting now!

Do you have an idea how to handle the optional boards in a proper way. without creating ~20 map files?

[terjeio]

Do you have an idea how to handle the optional boards in a proper way. without creating ~20 map files?

Most can be handled with the many grblHAL options available? PROBE_ENABLE, SDCARD_ENABLE, ...

BTW the name should be BOARD_FLUIDNC_I2S_6PACK_EXT_V2 to better match the board?

[dixi83]

Yes it is probably a better name.

This is the global idea I have in mind. Will this be workable for the web module in the future?

I am also thinking about to make an option to automatically configure the first free input as the probe input. How can i build in a check if there are enough inputs?

[terjeio]

Will this be workable for the web module in the future?

I am not keen to add a lot of board specific code to the Web Builder.
A common file links to all the driver/board definitions and has the UI definitions (features) and possible resource dependencies. Some are monitored meaning that if the user selects options that exceed available resources warnings are shown and the build is blocked.
Per driver files contains global driver capabilities and board definitions matching each board. All this info is combined to present and handle the UI via browser side javascript.
To achieve this symbol names (#defines) are standardized across all drivers so that the javascript code could be made generic.
There are still issues with this, some might be tricky to work around - but I rather avoid ending up with a big mess by allowing all kinds of special cases than by keeping the code (mostly?) generic.

If possible existing symbol names should be used, perhaps in combination with a few board maps with pin definitions for some of the option cards? A starting point would be to define a few basic configuration options and see how those could be mapped back to the current structure?
If this is not feasible a custom Web Builder for this board has to be made? Or at least a separate tab for it?

[dixi83]

I get you, every "special" complicates things. I'll see what I can work out with _map.h files. and not create to many 😉

For the "external drive" board it will be with the following option cards:

• the bare bare board (no option cards, it already has 6 inputs and 2 outputs)
• 1 DI, 1AO, 1 DO
• 1 DI, 1 RS485, 1 DO
• 1 DI, 1 RO

For the "universal CNC controller" it is a bit harder (more possibilities I could think of) will be with the following option cards:

• 1 DI, 1 AO, 1 DO
• 2 DI, 1 AO, 1 DO
• 1 DI, RS485, 1 DO
• 2 DI, RS485, 1 DO
• 1 DI, 1 RO

This will definitely not serve anyone's needs. If there are suggestions, let me know!

DI = digital input board with 4 inputs
DO = digital output board with 4 outputs
AO = analog output board with 1 0-10v and 2 digital outputs
RS485 = board with RS485 / modbus capabilities

@terjeio Thanks for all the effort you put in this project!

[terjeio]

A cross reference list with which pins are used for what vs. option cards would helpful? Such a list exists already?