Support for VFD RS485 communication about ucnc

[Paciente8159]

Thanks for the feedback. I'll try to implement a modbus capable tool. in the next couple of weeks. I have a huanyang vfd that I can use for testing.

[Paciente8159]

I've implemented modbus protocol support module and a VFD tool that is still fully untested on #239 .
Testing should start next week. I still need to buy a RS485 adapter to connect my the board to my VFD.
In the mean time I'll try to run the test using modbus server emulators.

[Paciente8159]

@Kaminariss quick update on the module. I've made some final modifications on the VFD tool HAL. Bytes seem to be transmitting correctly.
I'm waiting on the RS485-TTL converter to connect to my RAMPS board. It will probably only arrive by the end of the month. Only then I'll be able to test it on my Huanyang VFD.

[pwilkowski]

Thank you for quick response, i've been busy lately building my machine in terms of mechanical parts:

and for now i will be using PWM -> 10V converter which seems to be working.

RS485 will come later once i finish entire build.

[Paciente8159]

That looks awesome. I'll start the tests on the VFD this week. The driver is mostly done but needs improvements.
Out of curiosity what board/MCU are you using to control the machine?

[pwilkowski]

STM32F103 Bluepill

I did some tests today using your firmware

https://cdn.discordapp.com/attachments/799304241256202273/1013322215577616434/VID_20220828_073950.mp4

halGRBL does not support dual Y axis on this board and no support for auto squaring, and from what I see, uCNC does support it

[Paciente8159]

Yes µCNC supports up to 2 dual axis and auto squaring on the core (so it's available for all boards/MCU).
OK. In that case I will do the tests with the VFD using the Bluepill.

Since extension communication ports are all done using pure bit-banging and generic IO pins I'll focus on this MCU first. These type of emulated ports are also used on the TMC drivers but they are very permissive regarding baudrate.
The VFD will not, so I will start with that MCU and run through all others to fine-tune the µs delay routines.

I'm also in the middle of adding the ability to configure a dedicated hardware port to all software communication protocols (SPI and I2C now for IO expansion and UART will be added later) that is being developed in the MultiHAL-IO-expansion branch

[Paciente8159]

OK. M3, M4 and M5 commands are working on the VFD via MODBUS (tested with the Bluepill and on the AVR RAMPS1.4).
I'm getting an error on the speed update command but I assume it's because I don't actually have a spindle connected to the VFD right now. I will test that tomorrow with a proper spindle attached to the VFD.
If all is good it should be ready to go.

Again the tests were run on a Huanyang Type 1.
I have no way of testing other modules.

[pwilkowski]

Which modbus adapter are you using?

[Paciente8159]

I'm using one of these ttl to rs485 adapter:

Works both with 5V and 3.3V

[pwilkowski]

My current board is half assembled:

does uCNC has support for spindle enable pin? could not find that in docs.

[Paciente8159]

Awesome..

does uCNC has support for spindle enable pin? could not find that in docs.

Not on the core really but it's very easy to make one with a generic pin.
You can either turn it on tool loading and of on tool unloading (via M6 command) like on the relay spindle tool or you can even create your own custom M code to control that pin. The M17-M18 extension module is an example of that.

If you need I can later help you set that up.

[Paciente8159]

VFD is implemented and working.
I made a small core modification too. I just need to run the full set of tests and if all is good, it Will be merged in the main branch.

[Paciente8159]

Implemented and merged with #239
Huanyang Type1 tested and working
Other vfd types not tested
It's possible to add additional VFD by adding the message parameter.

[pwilkowski]

Im sorry but im a bit confused about how to set it up...
I would like to enable UART3 on bluepill for rs485 comm, ive got the same converter board like you, just need to figure out how to
"point it" to UART3 which is on PB10 PB11 ? Can you give me some example? I thought just defining

#define DOUT27_BIT 11
#define DOUT27_PORT B
#define DIN27_BIT 10
#define DIN27_PORT B
#define DIN27_PULLUP

but apparently its not enough

[Paciente8159]

Did you setup the tool type in the cnc_hal_config (reassigned TOOL1 to vfd)?
What VFD are you using?
What was de defined baudrate for the VFD?

[pwilkowski]

oh, yeah so i did not configure TOOL1 to be vfd, fixed that
my VFD is Powtran 8100
as for baudrate docs says

The system is tested in 6 kinds of baud rate: 0:1200, 1:2400, 2:4800, 3:9600, 4:19200, 5:38400

perhaps there are some discrepancies between those VFD
here is the docs: https://www.powtran.com/upload/202101/08/202101081445004838.pdf

I believe rs485 commands starts around 154 page

[Paciente8159]

Unfortunately although they all use RS485, not all protocols are standard and message length and functions change from brand to brand.
I'll try to digest the manual and see what I can get. A quick glance at the codes tell me that none of the VFD types messages I have in the vfd code match your type of VDF. You may try switch to VFD_HUANYANG_TYPE2 but I really doubt.

If I'm reading right the message to make the spindle stop is at page 168 and does not match any of the VFD codes (Huanyang types 1 and 2 and YL620)

[Paciente8159]

I have absolutely no idea if it will work. I tried my best to interpret the manual right. I found 0 examples on the web for that VFD. So I'm flying blind here.

Try this branch that is based on version 1.5.2 with the POWTRAN 8100 VFD.

Don't forget to configure your VFD and also the VFD tool file to make it match your VFD (choose the right type, correct address, etc...).

I don't know if it will run because I think that your VFD actually needs an extra command to run. But if at least the fwd and rev indications change then we are on to something.

I'm assuming that F01 sets the spindle speed and F12 is the maximum frequency.
I might have to had some soft of debugging output to allow to inspect the responses if this doesn't work.

Again without having that the hardware in my hands I can only go by the reading and some guessing.

[pwilkowski]

oh wow, i didnt expect it for you to make custom one for me, thank you.

I have it on hand i can connect it to PC via this adapter + uart->usb if there will be any problems.
Also there were some examples on the docs around page 165

[Paciente8159]

Also there were some examples on the docs around page 165

Based on those examples is the reason I suspect that vfd will require an extra command to actually run. But that is easy if the other commands are working.

If you have that usb adapter that will be great to help debug any problem. I can guide you through that too.

[pwilkowski]

I was able to communicate with VFD with uart -> usb connector, ive used two examples from their manual and it was working fine.

As for what is needed to run the vfd, from what i can tell it needs a direction (off, CCW, CW) and frequency.

Problem is, i do not know a program that is able to communicate with it hassle free, i've tested qmodbus, modbus tester and mtest, all of them has some kind of weird quirks and do not allow me to send raw data, which one do you use?

EDIT:

So i have tried the branch you prepared on separate bluepill so i can use that for testing however as soon as change tool1 to vfd, everything breaks, UART connection to PC breaks.

Relevant changes:
cnc_hal_config.h line ~121

#define TOOL1 vfd
// #define TOOL1 spindle_pwm

boardmap_bluepill.h
Tried to redefine 27 for another UART to comm with VFD, not connected yet

#define DOUT27_BIT 11
#define DOUT27_PORT B
#define DIN27_BIT 10
#define DIN27_PORT B
#define DIN27_PULLUP

stm32.ini
here is where i disable USB and use UART for communication with PC (I dont use USB at all)

[env:bluepill_f103c8]
extends = common_stm32
board = bluepill_f103c8
;uart
build_flags = ${common_stm32.build_flags} -D BOARD=BOARD_BLUEPILL -D INTERFACE=0
;usb
;build_flags = ${common_stm32.build_flags} -D BOARD=BOARD_BLUEPILL -D INTERFACE=1

vfd.c

#define VFD_BAUDRATE 19200
#define VFD_POWTRAN8100

EDIT2: Problem was

#define DIN27_PULLUP

as soon as i removed it, it started working, however spindle does not want to move, so probably a little bit of debugging will be needed

[Paciente8159]

Ok. Let go bit by bit.

So i have tried the branch you prepared on separate bluepill so i can use that for testing however as soon as change tool1 to vfd, everything breaks, UART connection to PC breaks.

This should not happen. I will investigate.

boardmap_bluepill.h
Tried to redefine 27 for another UART to comm with VFD, not connected yet

You don't actually have to use Bluepill hardware UART pins. Any generic pin can be used. These low speed communications expansion modules are almost all emulated in software.

EDIT2: Problem was

#define DIN27_PULLUP

as soon as i removed it, it started working, however spindle does not want to move, so probably a little bit of debugging will be needed

Nice. I thing I added the pull up to prevent detecting a false start bit condition but it might be blocking this. I will look into this. This might be related to the previous issue. To do software UART emulation the ISR's are temporarily disabled. If it enters a dead lock this will fail.

Are the FWD and REV indicators changing when you send an M3 or M4 command with S set with any other speed other than 0?
If yes. Then this is good news. As I told you I was expecting that to happen. It has an easy fix.

I've updated the branch with the necessary changes to run the extra command. Please download the branch with the modifications, reconfigure the files and retry.

EDIT:
I think I know the problem behind the UART locking problem. The culprit is most probably the MCU µs delay function used in the software versions of UART/I2C and SPI.
This is transversal to almost all ARM MCU in µCNC. AVR is immune to this problem because of the way this function was programmed.

I'll address this issue too in the next patches.

[pwilkowski]

Nice. I thing I added the pull up to prevent detecting a false start bit condition but it might be blocking this. I will look into this. This might be related to the previous issue. To do software UART emulation the ISR's are temporarily disabled. If it enters a dead lock this will fail.

Yes it certainly looked like CPU wasnt doing anything at all, no led blinking, no response.

Are the FWD and REV indicators changing when you send an M3 or M4 command with S set with any other speed other than 0?
If yes. Then this is good news. As I told you I was expecting that to happen. It has an easy fix.

No, nothing has been changing on keypad

I've updated the branch with the necessary changes to run the extra command. Please download the branch with the modifications, reconfigure the files and retry.

Which branch? I do not see any changes to powtran-vfd ?

[Paciente8159]

Yes it certainly looked like CPU wasnt doing anything at all, no led blinking, no response.

Read the previous message edit. I think I know the underlying problem.

Which branch? I do not see any changes to powtran-vfd ?

I forgot to push the changes. I've done it now.
Try the branch. If it doesn't work leave it aside.
I have some tests I need to do on my PC and also a couple of tests that I need you to run, but probably I'll only be able to describe the whole procedure tomorrow.

That setting
#define DIN27_PULLUP
might be needed after all. But for that I need to fix the locking problem.

[pwilkowski]

I forgot to push the changes. I've done it now.

Unfortunately the same issue occurs,

Also im not in a rush, so whenever you get time its fine.

Question tho, wouldn't it be easier to just use the hardware uart since this board has like 3?

[Paciente8159]

Yes but...

My main focus was to make core features MCU independent or at least as generic as possible. To run µCNC core firmware the only requirement is that the MCU has at least one free 16-bit or better timer, one communication port (UART or USB) and some sort of timer or underlying task to run and RTC timer. That's it.

Having a MCU with that it's possible to implement a HAL layer that matches to mcu.h file. You don't need boardmap files and nothing else. Boardmap files just do pin assignments to the current MCU HAL's that I developed.
You can, if you want to, open for example Arduino IDE, implement your own HAL for a custom MCU by setting the pins and all functions declared by mcu.h and run µCNC on that MCU. If well implemented µCNC will run the same way in any MCU...but I'm getting off topic.

For slow speed communication protocols like TMC (UART and SPI), modbus, LCD's etc.. software implement solutions are usable and have the bonus (in theory at least) to run out of the box in all MCU (AVR, ARM, whatever) because they are just plain code implementations.

I want to expand port capabilities on µCNC but have only been able to implement one additional SPI and I2C for each current supported architecture.
I want to add a second UART and others very very soon.
Doing it in a way that makes it configurable/flexible via boardmap is harder then doing fixed assignments. For example on STM32 the same UART port can be remapped to different pins in the MCU. Also IO capabilities change from STM32F101 to STM32F102 and STM32F103, etc... Making an HAL that fits all MCU flavors with options is not as trivial as fixed assignment.

Finally µCNC is a small project compared to others. I'm currently the only developer running this project.
Implementing and testing is slow and limited and I have tons of ideas to work. I do most of my testings on AVR.
When I do cross development (new ports, etc...) then yes I do tests on Bluepills, blackpills, Re-Arm and a couple of other boards I have for this.
Having more users testing and reporting problems on other MCU would help a lot.

[Paciente8159]

If you find the time re-enable the pull setting and retry with the changes I've just uploaded.
I've reverted the us delay on the STM32F1 MCU to a previous version that uses the Debug clock counter and is ISR independent.

Thanks,

[pwilkowski]

I appreciate time and effort you put in this firmware as imo, its the only modern cnc firmware besides modified 3d printer firmwares, all the others are just some ancient tech.

Unfortunately, new version does not work, mcu is no longer locked up but judginig from erratic led flashing there is still something weird going on. And i cannot connect via universal gcode sender.

I have created patch from local changes I had (so everything that has been changed):
https://nopaste.net/Zprd66yayA

long story short, two UARTS one for comm with PC and one to comm with VFD
tool changed to vfd,
vfd address 8 (is it the same as slave address? If so, my vfd slave id is 8)
vfd baudrate changed to 19200

[Paciente8159]

Thanks.
I'll test as far as I can go on my PC. I'll need you to do some tests of your own later on and I will send you detailed instructions on own to do them. They are the same set of tests I did for Huanyang VFD.
I was going to ask you about your VFD address. I think it is set by parameter A28 on your VFD. I'm going to assume it is 8 and use that as reference.

I'll give you feedback in a day or 2.

[pwilkowski]

Yes its 8, i went and checked in keyboard, this is also what was used when i was testing with qmodbus app.

I also sniffed what keyboard was sending while i pushed FWD and Stop buttons using Serial Port Monitor (in demo mode, not registered)
https://www.sendspace.com/file/3bmh8z

Not sure if it will be of any help

[Paciente8159]

Ok I working on improved delay cycles and bitbang protocols. These show far better results and I'll be applying them to the main branch soon.
From there on it's just a matter of merging the VFD modifications and test.

I'll give you feedback in a day or 2.

[Paciente8159]

New branch based on master

I modified the short delays with a new cycle loop.
I modified the VFD tool update function to prevent a deadlock in case the communication fails.

I connected the bluepill to my usb to serial at 19200 and I'm getting correct transmissions.

Here are a few commands the board is sending
Query Function 12 (max frequency)
08 03 00 0c 00 00 85 50
Stop
08 05 00 00 00 00 cd 53
To turn CW
08 05 00 02 ff 00 2d 63
To turn CCW
08 05 00 02 00 00 6c 93

I did not had the time to go through the qmodbus file you sent.

If you experience any stalls or locks in the vfd file change VFD_RETRY_DELAY_MS to 0

[pwilkowski]

Hello again, this time with new branch I cannot even connect via UART anymore (to PC) am I doing anything wrong?

My changes:
https://nopaste.net/J7fZkRxAul

On branch new-generic-loop-delay
Your branch is up to date with 'origin/new-generic-loop-delay'.        

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   uCNC/cnc_hal_config.h
        modified:   uCNC/src/hal/boards/stm32/boardmap_bluepill.h
        modified:   uCNC/src/hal/boards/stm32/stm32.ini

The way I test it:

Connect Bluepill to two usb uart adapters,

• connect one (to PC) to A9, A10 (i try to reverse cables if comm does not work)
• connect two (to VFD) to B10, B11 (again trying to reverse cables)
• for testing purposes i connect both of them to PC trying to see if there is any communication

And try to connect via universal gcode sender. With new branch I can't even to bluepill via A9, A10

Tried two completely different uart adapters and reversed tx/rx multiple times just in case. UGS does not recognize it.

[Paciente8159]

You probably have emergency stop enabled or unwired.
On cnc_config.h uncomment DISABLE_ALL_CONTROLS to disable ESTOP, HOLD and CYCLE START

If ESTOP is triggered you will be locked in alarm mode.

Also recheck your settings. Some modifications may cause the settings to become invalid and reset to their default (for example when there are modifications to the settings structure or version)

[pwilkowski]

Unfortunately, did not help, I just tried to connect with disabled all controls, and the only thing that is currently issue is connecting to PC via UART on A9 A10 so rest of the settings are not important right now.

When i try realterm using 115200 baudrate, it shows me some garbage when i send $$
https://i.imgur.com/rN437r1.png

I have also confirmed it was built without usb (which is good, says unrecognized device when connected via usb)

I have also tried to reset MCU via button, did not help
I have tried full power cycle, no difference

I have confirmed that UART connection works on older branch powtran-vfd without any additional changes (just the ones i posted in previous post):

[Paciente8159]

Humm. I'll investigate. Sorry

[pwilkowski]

No problem, just ping me and I'll try testing again :)

In the meantime, ill see if USB works and if so, if the VFD works

[Paciente8159]

Found the problem. On the stm32.ini remove that -D FRAMEWORK_CLOCKS_INIT

################
# STM32 Boards #
################

[common_stm32]
platform = ststm32
; debug with st-link
platform_packages = platformio/tool-openocd
debug_build_flags = -Og -g3 -ggdb3 -gdwarf-2
debug_init_cmds =
  target extended-remote $DEBUG_PORT
  load
  monitor reset init
build_flags = ${common.build_flags} -D HAL_TIM_MODULE_DISABLED -D HAL_EXTI_MODULE_DISABLED -D HAL_UART_MODULE_ONLY -D FRAMEWORK_CLOCKS_INIT

I don't recall why the hell I added that option???

Probably was something related with USB clocks configuration. I'll modify this to make sure it's auto enabled if USB is enabled only.

[pwilkowski]

Yes that did the trick, almost
Now im getting errors from UGS

**** Connected to COM4 @ 115200 baud ****
An unexpected error was detected: (error:52) An unknown error has occurred
Grbl 1.5 [uCNC v1.5.3-pre '$' for help]
>>> $$
[Error] An error was detected while sending '$$': (error:52) An unknown error has occurred. Streaming has been paused.
**** The communicator has been paused ****
>>> $G
[Error] An error was detected while sending '$G': (error:3) Grbl '$' system command was not recognized or supported. Streaming has been paused.
[Error] Error while processing response <ok>: An unexpected command was completed by the controller.

It is worrying because i did not receive such errors when swapped to USB.

While i do receive some data on UART on VFD port tho:

Btw do you have some discord server?

[Paciente8159]

No I have no discord but creating one has crossed my mind several times and I might do that soon.

About the UGS error..retry connecting again. When settings are corrupted the first time and error is sent. You can try and connect with a normal terminal and send a $RST=* to reset everything and see if that solved the UGS error on next connect

[pwilkowski]

Unfortunately VFD does not work, I just tested it and I am getting debug from UART, even lights on converter lights up but VFD does not react, could it be im not powering the converter from 5V? Do you have some connection diagram how to properly connect it?

And I was not able to get rid of UGS errors

[pwilkowski]

We have a partial SUCCESS!

EDIT: disregard the image,

VFD does not start by itself, i still have to click FWD button, but i see on keypad that frequency changes

M3 S1 up to 50 does work
M3 S0 does not work
M5 does not work - this is probably crucial

[Paciente8159]

M3 S1 set 50???

Hum, that's odd.

I've looked at your UART sniffing but was not able to make sense of the data.

Lets do basics. This is how I tested the Huanyang. This will be a multi-step test

Let's see if the get max frequency command works or not

Connect your USB to serial to your VFD
Open Realterm
Set to display Hex [space]
go to send and send this (query the value of Function 12):
0x08 0x03 0x00 0x0c 0x00 0x00 0x85 0x50

what was the reply?
What is the value you have on F12?

[Paciente8159]

Unfortunately VFD does not work, I just tested it and I am getting debug from UART, even lights on converter lights up but VFD does not react, could it be im not powering the converter from 5V? Do you have some connection diagram how to properly connect it?

And I was not able to get rid of UGS errors

You are probably getting and error 52 that is STATUS_VFD_COMMUNICATION_FAILED

UGS gives this error on my bluepill but runs just fine after that.
I also think that µCNC might be sending an ok after $$ and UGS does not expect that that's why the error...but still works

[pwilkowski]

M3 S1 set 50???

no no, i just tested M3 SXX where XX was a value between 1 and 50

M3 S35 set frequency around 210 (out of 400).

When i did send 0x08 0x03 0x00 0x0c 0x00 0x00 0x85 0x50 F12 did not change and was 400

[Paciente8159]

The VFD did not reply with??

0x08 0x03 0x00 0x0c 0x9c 0x40 0xcrc high byte 0xcrc low byte

EDIT:

Let me explain. µCNC first needs to read your VFD F12 value.
The command 0x08 0x03 0x00 0x0c 0x00 0x00 0x85 0x50 is asking for the value of F12 (or it should if I read the manual right)

[pwilkowski]

Response was 08 03 00 F0 F2

I did set with keyboard, F12 = 100

[Paciente8159]

Response was 08 03 00 F0 F2

I did set with keyboard, F12 = 100

That does not seem right. The response from the VFD should be 8 bytes long

[pwilkowski]

and

did i misconfigured realterm?

[Paciente8159]

No but maybe I messed the command
Try this 0x08 0x03 0x00 0x0c 0x00 0x01 0x44 0x90

[pwilkowski]

Result was 08 03 02 03 E8 64 FB

[Paciente8159]

I think I've glued all the pieces but need to recheck. Powtran support is in #311
It's still lacking some verbose that I plan on add later

[pwilkowski]

Should i wait till you merge/test it or try it out?

[Paciente8159]

Let me re run the code on my side. I made several changes. I'll probably have it ready for you to test it tomorrow.

[Paciente8159]

I was actually able to run the tests sooner.
When you test it you will need to reconfigure the code for your setup, that is:

• setting bluepill pins DOUT27 and DIN27 with pull up
• configure VFD for 19200 and POWTRAN type
• select TOOL1 as vfd
• if you don't have ESTOP, DOOR, HOLD and RESUME, either comment them in the boardmap or enable DISABLE_ALL_CONTROLS.

You can also enable MODBUS verbose by adding #define ENABLE_MODBUS_VERBOSE for example on cnc_config.h or by adding the build flag -D ENABLE_MODBUS_VERBOSE on stm32.ini.
That will print the modbus sent messages and read replies... i just don't know if UGS will be okay with that.

MODBUS output seems to be sending things OK and with correct baudrate.

EDIT: Wait...that's not right. I got to check something.
Either my logic probe is funky or the message should be different. I got to try this with other tool but don't have it with me right now.

You might try it though. Just use the usb to serial and Realterm to confirm that the modbus out verbose is matching what you are getting in realterm, before connecting it to the VFD

[Paciente8159]

Seems ok. Either Sigrok or the probe I was using was showing some odd results. Give it a try and let me know.

[pwilkowski]

Checked it and it seems to work but

I still had to remove -D FRAMEWORK_CLOCKS_INIT otherwise UART to PC would not connect. Did you forget to remove it?

And if VFD isn't connected to bluepill i am getting errors in UGS,

[Paciente8159]

I still have to work a bit on that FRAMEWORK_CLOCKS_INIT option :-/

About the errors yes I think is expected. UGS does not recognize does errors as they are error that are beyond the scope of Grbl.

µCNC has a list of errors that are new. They are listed in interface/grbl_interface.h.
Nevertheless I will try to review the UGS interaction later.

I just finished working on a new modification to allow both UART and USB to work seamlessly. You will not need to choose the interface in the next version of µCNC.

[pwilkowski]

Now that i think about, with the amount of changes that are incoming and how fast you push new stuff, do you think it would be possible to implement uart bootloader?