Competing interests of VFD and XHC-HB04 (with my own ignorance!)

After some trial and 'computer language" (wife's term) i got the xhc-hb04 running. Now I am trying to get the VFD spindle running with the a RS485-USB connector. The LinuxCNC Error messages are complaining about the xhc-hb04 pin existences.

Data:
LINUXCNC - 2.8.0-pre1-3732-g6ab2798
MESA 6i25 Board
MESA 7i76 Daughter Board (minor stepgen add due to 1st bay being dead)

Machine self-built 48x48x10 inches
(4) NEMA 34 Steppers
Huanyang hy02d223b VFD spindle
xhc-hb04 wireless
RS485 /USB connector (attempted both wirings)


Machine runs OK
XHC-HB04 worked OK prior to starting VFD implementation.
Spindle ran OK in Manual, before attempting the RS485 set-up changes

By removing the duplications, and moving some commands to custom.hal and commenting out some in custom_postgui the linuxcnc panel how shows. But the VFD does not respond to any command

I have done what the hy_vfd man page and the vfd instructions in several other locations suggest. From all indications, linuxcnc is recognizing the VFD, but for some reason I cannot get data to the VFD.

Are you sure you have your comms set up correctly in the VFD settings (baud rate, parity, slave address, RS485 enabled etc)?

I'm not sure if it makes a difference, but this line in your 48x48x10_Gantry_2018_06_14.hal file:


...in the examples I've seen usually is inserted in custom.hal. It certainly is in my case and it works fine on my machine. IME if Axis can't initiate comms to the VFD for whatever reason, it just carries on regardless and you end up with a spindle that you can't run and no reported errors as to why.

You can manually invoke the hy_vfd comms routines in a terminal window to check it will actually work. This post by Andypugh should get you going. Note that the commands he lists assumes that the default comms values are being used by your VFD (ie bits = 8, baud = 38400, parity = odd, stop bits = 1, slave address = 1) and that your USB-RS485 converter does actually appear at ttyUSB0. If not, modify the loadusr command with the appropriate switches and values as required (note, the '-g' switch Andy gives in his example didn't work for me and gave me an error if I used it. You can leave it out if you wish)

Sorry for the delay (-- visiting Relatives)

I am sure the settings are correct.
I have moved the loadusr statement back and forth several times with no difference.
USB0 is correct.


I read the other post you referred me to and made the same errors as the other person until I got what looks like the same result as the other fellow.



So now I know that the computer is talking to the VFD, but my program is not. Little has changed in the files other than repairing the issues you mentioned earlier. I have followed the code from the examples.

I don't own or have access to a decoder ring, I just copy the examples and play with what is there until something works.
I know very little python
I know even less structure of LinuxCNC
I realize you are doing this as a courtesy on your time, and I'd repay with my equal time if I could (need a dummy?)

So can you provide me with some part of that decoder ring to get me off dead zero! I have obviously missed the first classes of the LinuxCNC world and am trying to catch up.

Have you tried issuing the other suggested commands in the terminal window to verify you can manually start the spindle as well?

Edit: in your custom.hal file you have:

The # symbol is commenting-out the command that enables the hy_vfd comms to the spindle

Have you tried issuing the other suggested commands in the terminal window to verify you can manually start the spindle as well?


YES but with no results at the spindle.
the only feedback I see but don't quite understand is this


I have checked the settings from hy_vfd numerous times and they are set on the VFD and the program to the suggested values ( I have changed them back and forth to see if that did any difference

I have switched the twisted pair plus to minus and back - nothing

is there an output from the VFD to the computer that shows all the settings of the VFD other than pins? PD001 to PD250?
Something must be set incorrectly, but I've been unable to find it.

Here's a quick breakdown of what should be happening. The following lines of manually-entered text in a Terminal window should be:

...which manually starts the HAL module. Terminal should respond with:

...to signify it's ready to accept HAL codes and commands from the user. Then typing:

...tells HAL to load the included hy_vfd module with a default data bit length = 8, baudrate = 38400, parity = odd, stop bits = 1 and slave address = 1. These must match whatever settings you have in the Huanyang. If, for example your VFD is set for comms baudrate = 19200 and even parity, then the above command that needs to be issued should be modified to:

Note that communications has not yet been started with the VFD. All that's happened thus far is to initiate the hy_vfd HAL module with the intended communications settings. Then typing:

...is only used to verify the hy_vfd module has successfully loaded by listing the HAL input/output virtual pins available to use. Comms still hasn't started yet. If you can already get this far there's no reason to continue typing this command everytime you want to test the HAL module, nor does it need to be included in your custom.hal file. The next command:

...is what starts comms with the VFD. The correct reponse in Terminal should just be the next 'halcmd' prompt. At this point you appear to come up with errors that indicate that HAL can't talk to the VFD at all, hence the response:

So either:

1. The 'loadusr' command you are issuing doesn't include the necessary settings and switches to match your VFD settings
2. Your RS485 wiring and/or terminations are faulty
3. Your USB-to-RS485 converter is faulty
4. The RS485 interface on the VFD is faulty

FWIW, I have set my Huanyang VFD as the following:

• PD001 = 2 (Accept commands via RS485)
• PD002 = 2 (Accept drive frequency commands via RS485)
• PD163 = 1 (Set RS485 slave address to 1)
• PD164 = 1 (Set RS485 baud rate to 9600)
• PD165 = 3 (Set RS485 comms parameters to 8 bits, no parity, 1 stop bit)

Thus, the corresponding 'loadusr' command I need to issue to correctly initiate the hy_vfd HAL component is:

After that, all the other HAL commands Andy suggests in the post I linked to earlier should just work. If not then it's likely that either items 2, 3 or 4 in the above list are the culprits.

I have also seen reports floating around on the Net that indicate that some versions of the Huanyang VFD didn't ship with the RS485 chip soldered onto the PCB. If you have been unlucky enough to buy a VFD that falls into this category then unfortunately no amount of HAL commands are going to get the VFD working via RS485.

First, thanks for the extensive explanation.

Second, it appears that upon initiating the loadusr hy_vfd there is discussion with the VFD.
With the twisted pair in the wrong orientation I get.


When I changed the twisted pair I got a bit farther, but not far enough.


As you can see I did a show pin just prior to the hy_vfd.enable to show that the previous commands took in LinuxCNC
The Hyanyang manual provides no error message nor have I found any for LinuxCNC to explain (-12) and (-22).



Earlier I did a reset on the VFD (PD013 8) in case this unit had been used before (no real evidence) and not reset. I then set the numbers as

PD001 = 2 (Accept commands via RS485)
PD002 = 2 (Accept drive frequency commands via RS485)
PD163 = 1 (Set RS485 slave address to 1)
PD164 = 2 (Set RS485 baud rate to 19200)
PD165 = 3 (Set RS485 comms parameters to 8 bits, no parity, 1 stop bit)

It looks to me that we are at either 3 or 4 on your list.

Second, it appears that upon initiating the loadusr hy_vfd there is discussion with the VFD.
With the twisted pair in the wrong orientation I get.
File Attachment:
File Name: HY_comm_er...wist.txt
File Size:0 KB

That's pointing to a different problem.

...suggests that your USB-to-RS485 converter couldn't be found at ttyUSB0 when you called the 'loadusr...' command. Maybe it was unplugged slightly from the USB port? Maybe it hadn't had time to register on the USB bus when you typed the command? Maybe it was appearing at a different ttyUSBn location?

When I changed the twisted pair I got a bit farther, but not far enough.
File Attachment:
File Name: HY_comm_er...wist.txt
File Size:2 KB

Yep, that's the same error as I posted about just before - the hy_vfd component can't find anything to talk to at the other end of the RS485 data link after you issued 'setp hy_vfd.enable 1'.

The Hyanyang manual provides no error message nor have I found any for LinuxCNC to explain (-12) and (-22).

Yes, as much as I love LinuxCNC, at times the documentation can be a little confusing to wade through.

Error (-12) is comms timeout (nothing responding on the RS485 comms network, as per above).

Maybe I missed it, but I don't think I've seen error (-22) in your attached txt files?

It looks to me that we are at either 3 or 4 on your list.

It could still be a wiring swap-over (item 2). Your first test doesn't appear to have eliminated that as a possibility because LinuxCNC couldn't find the RS485 converter to begin with.

The little USB-to-RS485 converters are quite cheap (item 3). You can always buy a few to try out to eliminate it as a possibility.