Support RS485 control of Huanyang VFD (chinese spindles)

[Harvie]

Hello, can you please add support for this?

http://fightpc.blogspot.com/2014/10/vfd-control-with-arduino-using-rs485.html

[terjeio]

I can make a plugin. You can test as I do not own one? If so which driver to start with?

[Harvie]

Yes, i can test it :-)

I guess the C driver from LinuxCNC should be safe bet: https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/huanyang-vfd/hy_vfd.c

Or maybe you can try to merge this code from GRBL_ESP32: https://github.com/davehines91/Grbl_Esp32/blob/Grbl_ESP32_RS485_VFD/Grbl_Esp32/VFD.cpp

But there are drivers in other languages as well: https://github.com/itschleemilch/huanyango (GO) https://github.com/GilchristT/SpindleTalker2 (C#) https://github.com/drogenlied/pyHYControl (Python)

There are also guys who tried to get this merged to original GRBL, but there was not enough space on atmega: https://github.com/bdring/Grbl_Esp32/issues/24 https://github.com/grbl/grbl/issues/516

[bdring]

https://github.com/bdring/Grbl_Esp32/blob/master/Grbl_Esp32/Spindles/HuanyangSpindle.cpp

[terjeio]

Yes, i can test it :-)

For which processor/board then? I am not going to add this to all drivers even if it is going to be a plugin.

A NucleoF411RE board and a Teensy 4.1 is in the mail so it could be one of those, but it will be at least a week before I have any chance of looking into this.

[terjeio]

grblHAL has a spindle_at_speed signal that is only partly implemented. Perhaps this could be a good opportunity to complete that? Again using LinuxCNC as a base specification, see here and here.

Currently the MSP432 is the only driver that has spindle_at_speed support, from encoder input and defined as beeing within ±10% of the commanded speed. The grblHAL core will currently wait for a number of seconds before timing out and continuing, IMO an alarm should be issued if the speed is not achieved. What do you think?

https://github.com/terjeio/grblHAL/blob/0c0d6afcb85f9b5d22646046e9628274a6dc8463/grbl/spindle_control.c#L70-L91

[Harvie]

For which processor/board then? I am not going to add this to all drivers even if it is going to be a plugin.

I have "esp32 devkit v1"

[phil-barrett]

Is the interface just standard serial to an RS485 converter? Are there any other control signals needed? My T4.x boards have a serial out connector.

[terjeio]

Are there any other control signals needed?

Not if the converter has auto direction circuitry.

My T4.x boards have a serial out connector.

All drivers has at least one serial port available, those that has serial over USB (or network connectivity) as well may assign the serial port to a secondary function such as a MPG or ModBus. Since RS485 VFD plugins should not handle the serial port peripheral directly, I am considering adding a driver level HAL to let the driver allocate a port and provide a standardized interface.

The main challenge could be how to handle the silence required around ModBus messages in a generic way, preferably in the plugin code...

[Harvie]

I only have MAX485 module available for testing, it has following pins at uC side: DI, DE, RE, RO

RO - Receiver out RE - Receiver enable (enabled when this pin is LOW) DE - Driver enable (enabled when this pin is HIGH) DI - Driver in (the transmitter pin)

[terjeio]

@Harvie Which pin mappings are you using for your board?

I have started coding and are ready to start simulating but hit a snag as the messaging protocol is not ModBus, it is a chinese lookalike. This means my plan to code a ModBus emulation for the VFD is not possible, I have to write an emulation from scratch instead. I have a ModBus stack available so a real ModBus VFD emulator would be easy to write, but no luck with that...

Also, error handling needs to be implemented - it seems to me that implementation for the @bdring ESP32 port is rather crude in that respect, it would silently continue on a timeout or on an exception returned from the VFD (assuming the chinese ModBus lookalike might return exceptions per the ModBus standard). Executing g-code that makes chips with a non-running spindle is IMO not a good idea...

[Harvie]

I think for tests we can use mapping of this board:

https://www.tindie.com/products/33366583/grbl_esp32-cnc-development-board-v41/ https://github.com/bdring/Grbl_Esp32/wiki/Setting-Up-the-I-O-Pins#spindle

It does use following pinout:

#define SPINDLE_PWM_PIN         GPIO_NUM_25
#define SPINDLE_ENABLE_PIN      GPIO_NUM_22
#define SPINDLE_DIR_PIN         GPIO_NUM_18

So i guess these pins can be reused for digital communication instead... Is the pinout user-configurable? (at least during compilation) if i later decide to change it?

[Harvie]

I have started coding and are ready to start simulating but hit a snag as the messaging protocol is not ModBus, it is a chinese lookalike.

Yes, it uses RS485 physical layer, but the protocol might be rather chinese... Earlier i've sent links to code which implements the protocol. I am not sure how different from ModBus it can be, maybe there's some compatible subset, which might be enough for basic communication. But that's just guess.

Also, error handling needs to be implemented

What happens if you ignore this? I think there should be no collisions on the line as long as there is only VFD and ESP32, which is probably typical setup. I expect VFD to not actively send any status reports unless polled, but i am not sure... If such collisions are occuring, i think it might be enough to send every command 3 times with small random delay no matter if collision occured.

[terjeio]

Is the pinout user-configurable?

Yes, there are board map files that may be changed or new ones created. I have to revisit the ESP32 code to see what limits apply. Note I am doing the initial coding for a processor that has a debugger.

I am not sure how different from ModBus it can be

It deviates enough to prompt me to make an emulator from scratch, I have the basics working now - I only need to add fault scenarioes to make it complete?

The plugin also supports P2x Huanyang VFD's which seems to use a 100% ModBus compliant protocol.

Error handling:

Status reports has to be requested so no risk of collisions with a correctly configured setup. What I was thinking of is what to do if the VFD does not respond as expected or not at all. IMO that is a critical error.

A complicating factor is that communication with the VFD can happen in an ISR context, and at least the dynamic RPM change in stepper.c is time critical. grblHAL has support for CSS (Constant Surface Speed) mode that uses this. Waiting for a response from the VFD in time critical code is a big no-no. Then there is the ESP32 that simply crashes if a float variable (RPM) is referenced in an ISR context, I see that Bart has changed rpm to an int in his port - I assume to avoid this.

Another is that the spindle will be stopped on a reset (mc_reset) which also might happen in an ISR context, e.g. when a hard limit is triggered.

All in all this is a harder task to get 100% right than I first thought...

[Harvie]

The plugin also supports P2x Huanyang VFD's which seems to use a 100% ModBus compliant protocol.

This manual seems to apply https://wiki.spoje.net/lib/exe/fetch.php/howto/mechanical_engineering/huanyang_vfd_inverter_manual.pdf On page 55 of that manual there are details about MODBUS implementation if that helps.

Hardware i have available for testing looks like this, i am not sure which model exactly it is. But it is 1.5kW HuanYang.

[Harvie]

Also according to manual it seems that following stuff can be set:

Communication Address 1-250

Baud Rate 4800 b/s 9600 b/s 19200 b/s 34800 b/s 

Communication Data Method 
0：8N1 For ASCII 1：8E1 For ASCII 2：8O1 For ASCII
3：8N1 For RTU 4：8E1 For RTU 5：8O1 For RTU 

The communication protocol has two kinds of control mode：
⑴ RTU (Remote Terminal Unit) mode
⑵ ASCII（American Standard Code for information interchange）mode
Information of codes:
RTU mode: Each of 8-bit data is composed of two 4-bit (hexadecimal), for example: 64H
ASCII mode: Each of 8-bit data is composed of two ASCⅡbyte, for example:
One 1-bit data 64H (hexadecimal) i

[terjeio]

I have reorganized the core grblHAL a bit code in order to avoid setting spindle parameters from an ISR context and have successfully tested functionality with my VFD emulator (on a TM4C123 board) and development board (MSP432).

So am I now ready to add the plugin to the ESP32 driver. However the board you suggested does not have spindle direction pin available:

I think for tests we can use mapping of this board: https://www.tindie.com/products/33366583/grbl_esp32-cnc-development-board-v41/

If I am not mistaken this uses the 3axis_v4 pin mapping file.

An addtional pin is required for VFD comms, which one to sacrifice? The Mist pin?

Note that I have not yet verified that the pins available are possible to use for serial comms.

[Harvie]

Yes, i think the mist might be sacrificed for now as i do not have misting device and i definitely do not plan to use it during the spindle communication test.

[terjeio]

The plugin code is now ready for testing in the development branch - only for the ESP32 driver for now.

Settings can be found here:

https://github.com/terjeio/grblHAL/blob/9845e693296553caff13fcaf5c6a6aff3743152d/drivers/ESP32/bdring_v4_map.h#L98-L103

I have only tested with boosterpack_map.h which has different pin allocations.

The plugin supports P2x spindles as well, but I have not yet made that an option in the CMakeLists.txt.

Note that I am not yet 100% happy with the way ESP32 interacts with the plugin but with luck the core functionality should work. Among the issues I have with this driver is low polling frequency and the snowflake guru crashing the app if a float is encountered in an ISR context. To be resolved later.

[Harvie]

Sorry i was bit busy and totaly forgot to test this... Should be able to setup the test in few days...

[Harvie]

I am kinda confused about how to build grblHAL for ESP32... There does not seem to be examples directory in esp32 driver in order to be able to compile it using arduino IDE as described here https://github.com/terjeio/grblHAL/wiki/Compiling-GrblHAL

I might use make or cmake until arduino IDE support is added for ESP32, but i am not sure how...

[terjeio]

It has to be built with ESP-IDF v3.2 or later - but not v4+. I do not use Arduino libraries so not sure it can be built using the Arduino IDE, or what it would take to convert it for that. The project is set up for cmake.

https://github.com/terjeio/grblHAL/tree/master/drivers/ESP32

[Harvie]

I guess i still miss something... I've just copied grbl and spindle plugin to the ESP32 driver as required in readme.

[harvie@anemophobia ESP32]$ pwd
/home/harvie/Temp/grblHAL/drivers/ESP32
[harvie@anemophobia ESP32]$ git branch
  master
* test
[harvie@anemophobia ESP32]$ cmake .
CMake Error at CMakeLists.txt:88 (include):
  include could not find load file:

    /tools/cmake/project.cmake

-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:92 (target_compile_definitions):
  Cannot specify compile definitions for target "grbl.elf" which is not built
  by this project.

CMake Error at CMakeLists.txt:93 (target_compile_definitions):
  Cannot specify compile definitions for target "grbl.elf" which is not built
  by this project.

CMake Error at CMakeLists.txt:136 (target_add_binary_data):
  Unknown CMake command "target_add_binary_data".

-- Configuring incomplete, errors occurred!

[Harvie]

I do not use Arduino libraries so not sure it can be built using the Arduino IDE, or what it would take to convert it for that.

I beleive it's merely about providing the directory structure and library.properties file expected by arduino IDE, since the ESP32 support package for arduino is based on ESP-IDF and there's not really a reason to use the Arduino compatible API wrapper layer, because ESP-IDF API can be called directly from Arduino IDE as well... (given that you are compatible with ESP-IDF version bundled in Arduino IDE)

[terjeio]

Are you compiling with ESP-IDF?

I beleive it's merely about providing the directory structure and library.properties file expected by arduino IDE

You can do that then?

[Harvie]

Are you compiling with ESP-IDF?

Where do i put the ESP-IDF source code?

You can do that then?

Perhaps i can try to make PR later to support this. Just checked and it seems that Arduino IDE uses ESP-IDF 3.2: https://github.com/espressif/arduino-esp32/releases

BTW https://github.com/espressif/esp-idf/blob/master/SUPPORT_POLICY.md

As previously announced, Espressif will stop supporting v3.1 and v3.2 releases after October 2020. For more information please see the ESP-IDF Support Policy. Customers who are using v3.2 release series are encouraged to migrate to more recent releases. ESP-IDF v4.1 is the latest stable release of ESP-IDF at time of writing.

[Harvie]

Ok, i've managed to setup esp-idf, hopefully it will build now...

[Harvie]

With ESP-IDF master (4.x) it builds but does not link, with v3.2 i did not tried to build at all, since they use different build system and i would have need to setup things differently.

With ESP-IDF v3.3 i get this:

[harvie@anemophobia ESP32]$ pwd
/home/harvie/Temp/grblHAL/drivers/ESP32
[harvie@anemophobia ESP32]$ idf.py build
Note: You are using Python 3.8.6. Python 3 support is new, please report any problems you encounter. Search for 'Setting the Python Interpreter' in the ESP-IDF docs if you want to use Python 2.7.
Checking Python dependencies...
Python requirements from /home/harvie/esp/esp-idf/requirements.txt are satisfied.
Running cmake in directory /home/harvie/Temp/grblHAL/drivers/ESP32/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 --warn-uninitialized /home/harvie/Temp/grblHAL/drivers/ESP32"...
Warn about uninitialized values.
-- Found Git: /usr/bin/git (found version "2.29.2") 
-- IDF_TARGET not set, using default target: esp32
-- Building for target esp32
-- ccache will be used for faster builds
-- The C compiler identification is GNU 5.2.0
-- The CXX compiler identification is GNU 5.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/harvie/.espressif/tools/xtensa-esp32-elf/1.22.0-97-gc752ad5-5.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/harvie/.espressif/tools/xtensa-esp32-elf/1.22.0-97-gc752ad5-5.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/harvie/.espressif/tools/xtensa-esp32-elf/1.22.0-97-gc752ad5-5.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building empty aws_iot component due to configuration
-- Component names: soc log heap freertos vfs newlib esp_ringbuf driver esp_event ethernet mbedtls micro-ecc efuse bootloader_support partition_table app_update spi_flash nvs_flash lwip tcpip_adapter pthread smartconfig_ack wpa_supplicant xtensa-debug-module espcoredump esp32 cxx app_trace asio jsmn aws_iot bootloader nimble bt coap console nghttp esp-tls esp_adc_cal tcp_transport esp_http_client esp_http_server esp_https_ota openssl esp_https_server esp_websocket_client esptool_py expat wear_levelling sdmmc fatfs freemodbus idf_test json libsodium mdns mqtt protobuf-c protocomm spiffs ulp unity wifi_provisioning
-- Component paths: /home/harvie/esp/esp-idf/components/soc;/home/harvie/esp/esp-idf/components/log;/home/harvie/esp/esp-idf/components/heap;/home/harvie/esp/esp-idf/components/freertos;/home/harvie/esp/esp-idf/components/vfs;/home/harvie/esp/esp-idf/components/newlib;/home/harvie/esp/esp-idf/components/esp_ringbuf;/home/harvie/esp/esp-idf/components/driver;/home/harvie/esp/esp-idf/components/esp_event;/home/harvie/esp/esp-idf/components/ethernet;/home/harvie/esp/esp-idf/components/mbedtls;/home/harvie/esp/esp-idf/components/micro-ecc;/home/harvie/esp/esp-idf/components/efuse;/home/harvie/esp/esp-idf/components/bootloader_support;/home/harvie/esp/esp-idf/components/partition_table;/home/harvie/esp/esp-idf/components/app_update;/home/harvie/esp/esp-idf/components/spi_flash;/home/harvie/esp/esp-idf/components/nvs_flash;/home/harvie/esp/esp-idf/components/lwip;/home/harvie/esp/esp-idf/components/tcpip_adapter;/home/harvie/esp/esp-idf/components/pthread;/home/harvie/esp/esp-idf/components/smartconfig_ack;/home/harvie/esp/esp-idf/components/wpa_supplicant;/home/harvie/esp/esp-idf/components/xtensa-debug-module;/home/harvie/esp/esp-idf/components/espcoredump;/home/harvie/esp/esp-idf/components/esp32;/home/harvie/esp/esp-idf/components/cxx;/home/harvie/esp/esp-idf/components/app_trace;/home/harvie/esp/esp-idf/components/asio;/home/harvie/esp/esp-idf/components/jsmn;/home/harvie/esp/esp-idf/components/aws_iot;/home/harvie/esp/esp-idf/components/bootloader;/home/harvie/esp/esp-idf/components/nimble;/home/harvie/esp/esp-idf/components/bt;/home/harvie/esp/esp-idf/components/coap;/home/harvie/esp/esp-idf/components/console;/home/harvie/esp/esp-idf/components/nghttp;/home/harvie/esp/esp-idf/components/esp-tls;/home/harvie/esp/esp-idf/components/esp_adc_cal;/home/harvie/esp/esp-idf/components/tcp_transport;/home/harvie/esp/esp-idf/components/esp_http_client;/home/harvie/esp/esp-idf/components/esp_http_server;/home/harvie/esp/esp-idf/components/esp_https_ota;/home/harvie/esp/esp-idf/components/openssl;/home/harvie/esp/esp-idf/components/esp_https_server;/home/harvie/esp/esp-idf/components/esp_websocket_client;/home/harvie/esp/esp-idf/components/esptool_py;/home/harvie/esp/esp-idf/components/expat;/home/harvie/esp/esp-idf/components/wear_levelling;/home/harvie/esp/esp-idf/components/sdmmc;/home/harvie/esp/esp-idf/components/fatfs;/home/harvie/esp/esp-idf/components/freemodbus;/home/harvie/esp/esp-idf/components/idf_test;/home/harvie/esp/esp-idf/components/json;/home/harvie/esp/esp-idf/components/libsodium;/home/harvie/esp/esp-idf/components/mdns;/home/harvie/esp/esp-idf/components/mqtt;/home/harvie/esp/esp-idf/components/protobuf-c;/home/harvie/esp/esp-idf/components/protocomm;/home/harvie/esp/esp-idf/components/spiffs;/home/harvie/esp/esp-idf/components/ulp;/home/harvie/esp/esp-idf/components/unity;/home/harvie/esp/esp-idf/components/wifi_provisioning
-- IDF_VER: v3.3.4-262-ga19f58355
-- Project version: 377742b
-- Found PythonInterp: /home/harvie/.espressif/python_env/idf3.3_py3.8_env/bin/python (found version "3.8.6") 
-- Found Perl: /usr/bin/perl (found version "5.32.0") 
-- Adding linker script /home/harvie/Temp/grblHAL/drivers/ESP32/build/esp-idf/esp32/esp32_out.ld
-- Adding linker script /home/harvie/esp/esp-idf/components/esp32/ld/esp32.rom.ld
-- Adding linker script /home/harvie/esp/esp-idf/components/esp32/ld/esp32.peripherals.ld
-- Adding linker script /home/harvie/esp/esp-idf/components/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script /home/harvie/esp/esp-idf/components/esp32/ld/esp32.rom.spiram_incompatible_fns.ld
-- Building empty aws_iot component due to configuration
-- Component libraries: 
-- Configuring done
CMake Error at /home/harvie/esp/esp-idf/tools/cmake/project.cmake:103 (add_executable):
  Cannot find source file:

    eeprom/eeprom_24LC16B.c

  Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
  .hpp .hxx .in .txx
Call Stack (most recent call first):
  CMakeLists.txt:90 (project)

CMake Error at /home/harvie/esp/esp-idf/tools/cmake/project.cmake:103 (add_executable):
  No SOURCES given to target: grbl.elf
Call Stack (most recent call first):
  CMakeLists.txt:90 (project)

CMake Generate step failed.  Build files cannot be regenerated correctly.
cmake failed with exit code 1

[terjeio]

You have to start the "ESP-IDF Command Prompt", cd to the project folder and build with idf.py build. Or you can build and flash with idf.py -p <port> flash

I have tried several times to compile from Eclipse which is my preferred development platform, but have given up. PlatformIO next? I need a new development machine for that - no disk space for that in my aging machine...

Jus saw your new comment:

missing file: eeprom/eeprom_24LC16B.c

Remove these two lines from CMakeLists.txt:

eeprom/eeprom_24LC16B.c eeprom/eeprom_24AAxxx.c

Perhaps I should port to v4, the current build system is IMO trash (or I am stupid in not understanding it).

[Harvie]

That is what i do...

i've done . export.sh (which setups the commandline environment) then cd to project directory and then idf.py build (or mkdir build; cd build; cmake .. which seems to do the same thing)

Remove these two lines from CMakeLists.txt:

OK, that started building now... we'll see in moment if all goes well.

Update. Seeeems goood:

[1096/1096] Generating grbl.bin
esptool.py v2.8

Project build complete. To flash, run this command:
../../../../esp/esp-idf/components/esptool_py/esptool/esptool.py -p (PORT) -b 460800 --after hard_reset write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/grbl.bin
or run 'idf.py -p (PORT) flash'

[terjeio]

FYI I just built and flashed my ESP32 (with v3.3).

Any helpful info here?

https://docs.espressif.com/projects/esp-idf/en/v3.2.2/get-started/index.html#get-started-get-esp-idf

[terjeio]

Ouch, I did no see your latest comment... Sorry for the noise.

[Harvie]

BTW i've changed the baudrate to 9600, which is probably better for high EMI environment that is usualy a big problem anywhere near the VFD stuff and rebuilt the firmware. Is it ok, that other defines did not changed?

# grep -ri baud .  | grep -i modb
./driver.c:#ifndef MODBUS_BAUD
./driver.c:#define MODBUS_BAUD 19200
./driver.c:    serial2Init(MODBUS_BAUD);
./bdring_v4_map.h:#define MODBUS_BAUD             9600
./cnc_boosterpack_map.h:#define MODBUS_BAUD             19200

[Harvie]

Anyway it's great that i was able to build this. I can now debug bCNC to fix grblHAL compatibility issues that people report...

And of course i will test the RS485 spindle compatibility soon...

[Harvie]

So i've compiled the code, uploaded firmware to esp32, hooked logic analyzer to pins 2, 21 and 22 and i do not see any digital signal when i issue M3 S12000 or M5 g-code command...

[Harvie]

Any chances i do need to configure anything else than just copying in these files?

$ ls spindle/
huanyang.c  huanyang.h  modbus.c  modbus.h  README.md

[terjeio]

So i've compiled the code, uploaded firmware to esp32, hooked logic analyzer to pins 2, 21 and 22 and i do not see any digital signal when i issue M3 S12000 or M5 g-code command...

Which board map file? Seems it is only _bdring_v4map.h that has the driver configs for ModBus. But looks like you have figured this out already.

_mymachine.h contains settings not covered by CMakeLists.txt.

Any chances i do need to configure anything else than just copying in these files?

You must enable Huanyang spindle support in CMakeLists.txt.

---

I am just back home, it has been a busy day today so will revisit/recheck this tomorrow.

[Harvie]

You must enable Huanyang spindle support in CMakeLists.txt.

Switched vfd spindle from OFF to ON, and uncommented #define BOARD_BDRING_V4, now i get this:

../esp32-hal-uart.c: In function 'uartConfig':
../esp32-hal-uart.c:213:33: error: 'UART2_TX_PIN' undeclared (first use in this function)
         uart_set_pin(uart->num, UART2_TX_PIN, UART2_RX_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);
                                 ^
../esp32-hal-uart.c:213:33: note: each undeclared identifier is reported only once for each function it appears in
../esp32-hal-uart.c:213:47: error: 'UART2_RX_PIN' undeclared (first use in this function)
         uart_set_pin(uart->num, UART2_TX_PIN, UART2_RX_PIN, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE);
                                               ^

[Harvie]

i've added following to esp32-hal-uart.c

#define UART2_RX_PIN            GPIO_NUM_22
#define UART2_TX_PIN            GPIO_NUM_21
#define MODBUS_DIRECTION_PIN    GPIO_NUM_2
#define MODBUS_BAUD             9600

But i still get an error:

../driver.c: In function 'driver_setup':
../driver.c:1347:62: error: 'SPINDLE_MASK' undeclared (first use in this function)
         .pin_bit_mask = DIRECTION_MASK|STEPPERS_DISABLE_MASK|SPINDLE_MASK|COOLANT_MASK,
                                                              ^
../driver.c:1347:62: note: each undeclared identifier is reported only once for each function it appears in
../driver.c: In function 'vModBusPollCallback':
../driver.c:1456:5: error: implicit declaration of function 'modbus_poll' [-Werror=implicit-function-declaration]
     modbus_poll();
     ^

modbus_poll() without arguments is nowhere to be found. i only found void modbus_poll (uint_fast16_t grbl_state); in spindle/modbus.c, but that expects arguments and is not even exported in modbus.h...

[terjeio]

I'll take a look at this tomorrow, be patient. It is likely I have messed up a bit since the grblHAL core has had a lot of changes lately to facilitate better plugin support. So sorry for stressing you about this without verifying the code first.

[Harvie]

Don't worry. I am very grateful for your effort and some testing is the least i can do. Also it is my fault that i've not tested the code back then when it was compatible.

[terjeio]

Test branch updated with fix for the regression (it was mainly due to core changes). With a little luck it should now work, at least my simulator accepts what I believe are the correct commands.

Note that I have moved more options to CMakeLists.txt for simpler configuration when cmake is used for compilation.

[Harvie]

Test branch updated with fix for the regression

Ok, this builds, but when i enable HUANYANG, it fails to communicate with sender over serial line. theres nothing shown in serial console... When i disable HUANYANG, it starts working again...

ESP32 UART peripherals provide quite complex configuration options, so i guess there is a lot of room for errors: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/uart.html

[terjeio]

Can you post the $I output when it works please. And did you update the plugin code?

[Harvie]

And did you update the plugin code?

stupid me :-) i'll try now

[Harvie]

Nice! Now i have some serial data on the output pins! But when i click spindle enable in bCNC the GRBL reports Alarm:14, perhaps because spindle is not connected. Hopefully i will try tomorow with real spindle to see if it works...

$I
[VER:1.1f(ESP32).20201120:]
[OPT:VNSL,35,1024,3,0]
[NEWOPT:*FLASH,TC]
[DRIVER VERSION:201122]
[BOARD:BDRING v4]
[PLUGIN:MODBUS v0.01]
[PLUGIN:HUANYANG VFD v0.01]

update: just checked the code and alarm 14 really seems to be spindle fault raised by huanyang module, so it's probably the case...

[Harvie]

So just tested with spindle. It works like 10% of the time, but i get lot of alarms. error:9 and error:14 mostly... Managed to get spindle running, change RPM while running and stop it again. But most of the times i get an error instead of spindle doing anything...

Note that i do not have anything else connected to esp32 (except for RS485 transciever). I inverted endstops using $18=7 to prevent them from being triggered.

[Harvie]

It seems to me like some RPM settings do work, while others does not. weird. Sometimes alarm is caused, sometimes no alarm is caused, but spindle does not react.... Sometimes it does work. weird. Lot of times, the RPM shown on VFD display is 1 lower than requested RPM, but sometimes it is the same as requested.

[Harvie]

Sometimes i get error:20 And i've found that M3/M4/M5 commands are relatively reliable when RPMs are not specified. But when i specify rpm eg. M3 S10000 it causes issues.

[terjeio]

error:14 (or rather alarm:14? is from the plugin), error:9 (not alarm:9) is likely from alarm:14 beeing active.

Wonder if disabling polling for the real-time report will make it more stable, can you try with commenting out this line?

https://github.com/terjeio/grblHAL/blob/61f09cd87cc5ec16fdf1711b90b76ea516ae3d15/plugins/spindle/huanyang.c#L178

It could be down to timing issues, I am not sure my code is 100% compliant with the ModBus spec (and perhaps the spindle is neither).

Sometimes i get error:20

That suggests corrupted gcode. Noise?

Have you controlled the spindle sucessfully with grbl_esp32 before?

[Harvie]

Wonder if disabling polling for the real-time report will make it more stable

Did not helped.

I also tried to comment out system_raise_alarm(Alarm_Spindle); which SEEMS to make things bit better, but i think it's just an illusion :-)

That suggests corrupted gcode. Noise?

You might actually be true... I will have to do a lot of testing... I currently run my machine on 5V arduino and initialy it took me some time to fix the EMI issues. i guess the 3.3V ESP32 might be even more prone to such issues.

So if you don't have any other ideas. (eg. repeat each command 10 times hoping that at least one will be successful even during EMI. = might not be good for debugging, but also might make the overall system bit more robust)

I will try to hunt down the EMI problems... It will probably take some time...