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:
bdring/Grbl_Esp32#24
grbl/grbl#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?

grblHAL/grbl/spindle_control.c

Lines 70 to 91 in 0c0d6af

	// G-code parser entry-point for setting spindle state. Forces a planner buffer sync and bails
	// if an abort or check-mode is active.
	bool spindle_sync (spindle_state_t state, float rpm)
	{
	bool ok = true;
	bool at_speed = sys.state == STATE_CHECK_MODE || !hal.driver_cap.spindle_at_speed;
	if (sys.state != STATE_CHECK_MODE) {
	// Empty planner buffer to ensure spindle is set when programmed.
	if((ok = protocol_buffer_synchronize()) && spindle_set_state(state, rpm) && !at_speed) {
	float delay = 0.0f;
	while(!(at_speed = hal.spindle_get_state().at_speed)) {
	delay_sec(0.1f, DelayMode_Dwell);
	delay += 0.1f;
	if(ABORTED || delay >= SAFETY_DOOR_SPINDLE_DELAY)
	break;
	}
	}
	}
	return ok && at_speed;
	}

[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:

grblHAL/drivers/ESP32/bdring_v4_map.h

Lines 98 to 103 in 9845e69

	#if MODBUS_ENABLE
	#define UART2_RX_PIN GPIO_NUM_22
	#define UART2_TX_PIN GPIO_NUM_21
	#define MODBUS_DIRECTION_PIN GPIO_NUM_2
	#define MODBUS_BAUD 19200
	#endif

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

[Harvie]

I guess I need to buy a Huanyang VFD to be able to dig into this myself...

What spindle do you currently run on your machine?

[terjeio]

What spindle do you currently run on your machine?

Kress FM1050 for the router (has Mach3/ethernet Smootstepper - not going to change to grbl).
Small 48V DC motor for the mini router.
Washing machine motor with no brandname VFD for the lathe (0-10V control), no RS-485 interface AFAIKT.

[Harvie]

I've just checked test branch and i see you've added following settings:

$374: ModBus baud rate:
0 - 2400
1 - 4800
2 - 9600
3 - 19200
4 - 38400
5 - 115200
$375: ModBus RX timeout in milliseconds, range: 50 - 250

can you please add option to set $375=0 in order to ignore unresponsive VFD? I have several use cases:

• if you are optimistic you can save the RX pin for some other use and hope the modbus messages sent on TX pin will get received.
• i usualy flash and test the grblHAL at home and when everything seems OK i bring it to the workshop to install it into the machine. So i get ALARM:14 because i don't have VFD at home, it would be super useful for me to be able to test everything but ignore missing VFD (without having to rebuild everything with disabled modbus).
• For some reason i might want to be able to configure VFD frequency manualy by the buttons on device, therefore i need to be able to tell grblHAL to ignore it.

[raenji-sk]

Is anyone using the Modbus with grblHAL?
I've been looking at the Invertek range of VFDs which support Modbus, would it work with other than the Chinese VFDs?
Also, how should it be wired to Phil's Teensy 4.1 BOB?

Here's a link to the manual, Modbus description on page 36 - https://inverterdrive.com/file/Invertek-Optidrive-E3-Manual

[Harvie]

I don't think this will work without modification with other brands, but the boilerplate code is there and you can probably modify it if you know what modbus commands your unit expects.

[raenji-sk]

Ok, thanks. I'll try to look into it when or if I decide to upgrade the spindle. Or bother you here for help 😅.

[terjeio]

More details can be found in this application note.

As @Harvie writes it is unlikely that the Huanyang code can be used as-is, copying it to a new file for Invertek and modifying that to match the Invertek protocol is the way to go ahead. Do not modify the Huanyang code unless it is adding support for further variants or expand functionality for the existing ones.

[raenji-sk]

Thanks @terjeio ,I'll look at the document. But I think it will be above my programming skills to do it.
But I am in no rush so there's time to learn something new perhaps.
Do you know how it would interface to the @phil-barrett teensy board? Can it be done directly or is some serial to rs485 converter needed?

[phil-barrett]

It needs an RS485 adaptor. That is something I am planning to do. That is one of the reasons the new Pro board has mounting holes for a UART daughter card.

[terjeio]

But I am in no rush so there's time to learn something new perhaps.

I think we can sort this out together, for basic control not much code needs to be changed - the largest part of the job is to figure out which commands to send and testing.

[phil-barrett]

Here are 2 cards that might work for you. I have the first (ANMBEST) but think the chip is not really a max485
https://www.amazon.com/ANMBEST-Transceiver-Arduino-Raspberry-Industrial-Control/dp/B088Q8TD4V/
https://www.amazon.com/HiLetgo-Reciprocal-Hardware-Automatic-Converter/dp/B082Y19KV9/

[raenji-sk]

Ok, thanks for the supportive comment .
@phil-barrett Do you have an ETA on the new board?

Again I am no hurry to get any of the above, but if it could be sorted sometime this year then it would make a nice Christmas present 😉 .

[MisterDiz]

I'm attempting to get my Huanyang VFD working with grblHAL on a Teensy 4.1

Is this implemented for the Teensy?

I have it defined in my_machine.h. Is it then just a case of defining the pins in the T41U5XBB_map.h?
Do I comment out the existing spindle definitions, replacing with something like...

#if SPINDLE_HUANYANG
#define UART2_RX_PIN (12u)
#define UART2_TX_PIN (13u)
#define MODBUS_DIRECTION_PIN (11u)
#define MODBUS_BAUD 19200
#endif

I also saw this in the driver.h file for the ESP32, is it necessary?

#if SPINDLE_HUANYANG
#define RS485_DIR_ENABLE 1
#else
#define RS485_DIR_ENABLE 0
#endif

Am I then good to go after plugging in my 3.3v TTL to RS485 adapter?

[dresco]

I'm attempting to get my Huanyang VFD working with grblHAL on a Teensy 4.1
Is this implemented for the Teensy?

Yes, but is easier than that. You will just need to define VFD_ENABLE=1 and SPINDLE_RPM_CONTROLLED in your my_machine.h (or in platformio.ini if building from that)

Note that you will want to pull the latest code from github.com/grblHAL/, as this repo is the old location and out of date..

[MisterDiz]

Ha! Nothing in my world is ever easy ;P

Thanks for the quick reply Dresco, I'm now with a less archaic version, changed those 2 lines and compiled successfully :)

Should I use the "SPINDLE_ENABLE_PIN" for RX
and "SPINDLE_PWM_PIN" for TX?

Presumably there's nothing else I need to change?

[dresco]

It will default to Serial1, which I think is pin 0 for RX and pin 1 for TX. (The RS485 adapters I'm using don't have an enable line, so not sure what pin that would be mapped to if you need it).

Are you using Phils breakout board? If so, just hook your 3.3v TTL to RS485 adapter up to the serial header & should be good to go..

Cheers.

[MisterDiz]

Cool, will give that a go. I'm using a slightly ghetto looking DIY BOB, currently I'm having post upload 'GRBL not found'/'offline' issues with the new GrblHAL when connecting to my all my G-Code senders. :/

Thanks for your help

[MisterDiz]

Ok, so I have the latest GrblHAL up and running and active without spindle, when attempting to enable RS485 control, my sender can see the Teensy but I cannot get communication.

I have the spindle plug in folder with the 3 files and the only code changes I've made are by adding
#define VFD_ENABLE 1 // Set to 1 or 2 for Huanyang VFD spindle. More here https://github.com/grblHAL/Plugins_spindle
#define SPINDLE_RPM_CONTROLLED
to my_machine.h

Apologies for the school boy errors, what am I missing?

[phil-barrett]

Have you gone through the first run settings? It is fairly common for a different configuration to return previous settings to default. Try grounding the halt pin - the default is NC.

[MisterDiz]

Thanks Phil, yes, I inverted all the pins for $5, $6 and $14 on my first setup, the machine started with no alarms and worked as it should - my problem is that when I define VFD_ENABLE 1 and SPINDLE_RPM_CONTROLLED in my_machine.h, after reboot I get an offline status. Commenting these two lines out gives me my machine back but obviously no VFD control.

Do I need to comment out the default spindle control settings or are they ignored? (I was fearing this would lead to compile issues)

[terjeio]

Ok, so I have the latest GrblHAL up and running and active without spindle, when attempting to enable RS485 control, my sender can see the Teensy but I cannot get communication.

Is this the version form the new repository? I am about to archive this to avoid confusion...

after reboot I get an offline status.

Are you connecting to the controller via UART or USB? "Oflline status" is from a sender, does the controller respond if you connect with a terminal application such as puTTY?

[MisterDiz]

Hi Terjeio, yes, after the advice of Dresco, I am now on the correct latest build from the other repository :)

My Teensy 4.1 is connected by USB, senders can identify a port and open a connection, but Grbl communication isn't ready. I've not tried to ssh, what address would I use?

[terjeio]

I've not tried to ssh, what address would I use?

Connect via the USB com port. Do you get a response when sending ? (for getting a real-time report)?

If the the VFD is not set up correctly or the baud rate is wrong the controller will start up with alarm 14 active. Baud rate is set with $374. Use $help modbus from the terminal to get info about settings if you can communicate with the controller.

[MisterDiz]

Good news, whilst PuTTY failed to connect (no status or position was returned), the problem was that I was adding SPINDLE_RPM_CONTROLLED to my_machine.h rather than uncommenting in grbl/config.h

Controller now boots and connects :)

Thanks also for the $modbus tip, I am fiddling with the hardware before connecting it all up.

In my board map, are the Spindle enable, direction and PWM pins redundant? (so I should uncomment them?)
Conversely, if I leave the enable pin defined, will it be available to control other relays?

[terjeio]

In my board map, are the Spindle enable, direction and PWM pins redundant? (so I should uncomment them?)
Conversely, if I leave the enable pin defined, will it be available to control other relays?

Yes. However, if the PWM pin definition is missing it will generate a compiler error unless you update to the version just committed.

[dresco]

the problem was that I was adding SPINDLE_RPM_CONTROLLED to my_machine.h rather than uncommenting in grbl/config.h

Apologies, that probably came from my suggestion didn't it. I pass the defines in from IDE options, so had overlooked where it's set..

[MisterDiz]

No need to apologise Dresco. All is good. I now have full spindle talkie talkie and no release of magic smoke! 👍

Thanks again for all the help everyone.