VFD Selection
We had a power outtage yesterday and it appears to have suffered an electronic lobotomy. Assuming I can't fix it, is there a particular brand/model that people are favoring these days?
Please Log in or Create an account to join the conversation.
Also, these widgets control them very nicely with the LinuxCNC hal component:
www.amazon.co.uk/gp/product/B082KKG55T
Please Log in or Create an account to join the conversation.
I've now configured the GT according to the HY_GT_VFD component man page.
Now I see the following command from halrun:
halcmd: loadusr -wn vfd hy_gt_vfd -d /dev/ttyUSB0 -S 1720 -F 60 -f10 -v
hy_gt_vfd: device='/dev/ttyUSB0', baud=38400, parity='N', bits=8, stopbits=1, address=1
[01][03][30][00][00][01][8B][0A]
Waiting for a confirmation...
<01><03><02><00><00><B8><44>
[01][03][30][02][00][01][2A][CA]
<With the verbose flag, the last three items repeat ad infinitum.>
Without verbose I see...
halcmd: loadusr -wn vfd hy_gt_vfd -d /dev/ttyUSB0 -S 1720 -F 60 -f10
hy_gt_vfd: device='/dev/ttyUSB0', baud=38400, parity='N', bits=8, stopbits=1, address=1
read_modbus_register: error reading freq-fb (register 0x3000): Connection timed out
read_modbus_register: error reading dc-bus-voltage (register 0x3002): Connection timed out
I'm not exactly sure what I should be seeing at this point but that doesn't look right. Also,
the man page has a note about modifying hardware but isn't clear about the symptoms if the VFD needs the modification or not. The SW position appears to match the description after the mod so I think I'm ok.
Advice?
Please Log in or Create an account to join the conversation.
Have you configured the VFD for modbus control and with the right parity / bits / speed etc?
I seem to remember that I needed to do some fiddling as either the LinuxCNC driver or the VFD baud settings seemed to not exactly match the docs.
Here is the contents of an email I sent to the LinuxCNC mailing list:
The hy_vfd docs say that the default comms type is 8N1, and suggests
setting the VFD register 165 to 3 (8N1 RTU)
The VFD setting advice seems correct, but hy_vfd actually seems to
default to 8E1:
halcmd: loadusr hy_vfd --debug
halcmd: hy_vfd: device='/dev/ttyS0', baud=19200, bits=8,
parity='even', stopbits=1, address=1, debug=1, PID=24472
Opening /dev/ttyS0 at 19200 bauds (even)
The Internet is of the opinion that the VFDs don't work with parity of
either type enabled. A test with P165 set to 4 (8E1) and the default
hy_vfd config, however, seems to indicate that this is not true,
though a number of comms timeout messages are seen (as they are, with
my setup, with 8N1 too).
I think that response lag is higher (and significant) with 8E1.
So, do we change the docs to suggest P165 = 4, or do we change hy_vfd
to match the docs?
Actually, step zero is probably to ensure that when --debug says
parity even that this is actually correct.
Please Log in or Create an account to join the conversation.
Definitely ttyUSB0. I had to mess with permissions to be able to access it but that's all. It appears/disappears when the stick is plugged in and removed.Is the USB adapter definitely ttyUSB0 ?
Have you configured the VFD for modbus control and with the right parity / bits / speed etc?
I set up the firmware following the steps as described:
www.linuxcnc.org/docs/html/man/man1/hy_gt_vfd.1.html
Interesting. The email seems to be about the HY series and component. Did you have the same communication issues with the GT series VFD and component?I seem to remember that I needed to do some fiddling as either the LinuxCNC driver or the VFD baud settings seemed to not exactly match the docs.
Here is the contents of an email I sent to the LinuxCNC mailing list:
<snip>
Please Log in or Create an account to join the conversation.
Interesting. The email seems to be about the HY series and component. Did you have the same communication issues with the GT series VFD and component?
I haven't used a GT version.
Please Log in or Create an account to join the conversation.