- LinuxCNC
- General LinuxCNC Questions
- Competing interests of VFD and XHC-HB04 (with my own ignorance!)
Competing interests of VFD and XHC-HB04 (with my own ignorance!)
- TRAUPMANN00
-
Topic Author
- Offline
- Junior Member
-
- Posts: 33
- Thank you received: 0
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
Please Log in or Create an account to join the conversation.
The important errors are
xhc-hb04.tcl: !!! <halui.spindle-manual-stop> target pin does not exist, continuing
xhc-hb04.tcl: !!! <probe-in> target pin does not exist, continuing
...
custom_postgui.hal:7: Pin 'pyvcp.spindle-at-speed' does not exist
The first two indicate that all is not ideal with the xhc setup but those are not causing the problem as far as I can see. The real problem seems to be the missing "pyvcp.spindle-at-speed" LED on the custom panel.
Looking at the [HAL] section
[HAL]
# TWOPASS = on
HALUI = halui
HALFILE = 48x48x10_Gantry.hal
HALFILE = custom.hal
# HALFILE = LIB:basic_sim.tcl
HALFILE = LIB:xhc-hb04.tcl
POSTGUI_HALFILE = postgui_call_list.hal
SHUTDOWN = shutdown.hal
POSTGUI_HALFILE = custom_postgui.hal
HALUI = halui
You have HALUI = halui twice. I think it should exist only once, but that probably doesn't cause a problem.
I am not sure if you can have two POSTGUI_HALFILE entries, though it does seem to be calling the second one (as that is where the error is being raised).
Please Log in or Create an account to join the conversation.
- TRAUPMANN00
-
Topic Author
- Offline
- Junior Member
-
- Posts: 33
- Thank you received: 0
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.
Please Log in or Create an account to join the conversation.
I'm not sure if it makes a difference, but this line in your 48x48x10_Gantry_2018_06_14.hal file:
loadusr -Wn vfd hy_vfd -n vfd -d /dev/ttyUSB0 -p none -r 19200
...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)
Please Log in or Create an account to join the conversation.
- TRAUPMANN00
-
Topic Author
- Offline
- Junior Member
-
- Posts: 33
- Thank you received: 0
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.
Please Log in or Create an account to join the conversation.
Edit: in your custom.hal file you have:
# setp vfd.enable 1
The # symbol is commenting-out the command that enables the hy_vfd comms to the spindle
Please Log in or Create an account to join the conversation.
- TRAUPMANN00
-
Topic Author
- Offline
- Junior Member
-
- Posts: 33
- Thank you received: 0
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.
Please Log in or Create an account to join the conversation.
halrun
...which manually starts the HAL module. Terminal should respond with:
halcmd
...to signify it's ready to accept HAL codes and commands from the user. Then typing:
loadusr -W hy_vfd -d /dev/ttyUSB0
...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:
loadusr -W hy_vfd -d /dev/ttyUSB0 -p even -r 19200
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:
show pin
...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:
setp hy_vfd.enable 1
...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:
halcmd: WAIT_DATA(): comms time out
ERROR Communication time out (-12)
error reading setup from VFD, retrying
So either:
- The 'loadusr' command you are issuing doesn't include the necessary settings and switches to match your VFD settings
- Your RS485 wiring and/or terminations are faulty
- Your USB-to-RS485 converter is faulty
- 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:
loadusr -W hy_vfd -d /dev/ttyUSB0 -p none -r 9600
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.
Please Log in or Create an account to join the conversation.
- TRAUPMANN00
-
Topic Author
- Offline
- Junior Member
-
- Posts: 33
- Thank you received: 0
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.
Please Log in or Create an account to join the conversation.
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.
ERROR Can't open the device /dev/ttyUSB0 (errno 5)
hy_vfd: ERROR: couldn't open serial device
...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.
Please Log in or Create an account to join the conversation.
- LinuxCNC
- General LinuxCNC Questions
- Competing interests of VFD and XHC-HB04 (with my own ignorance!)