Huanyang VFD RS485 / Modbus

[scotta]

I recently received my Huanyang VFD from linearmotionbearings2008 and was quite impressed with the quality of the drive compared to the first Xin Ye drive which went bang.

I am trying to get the RS485 / Modbus communications going and up to now have not had a lot of success.

VFD Settings:
PD001 = 2 (run commands to comm port)
PD002 = 2 (operating freq to comm port)
PD163 = 1 (slave address 1)
PD164 = 1 (baud rate to 9600 b/s)
PD165 = 3 (8N1 for RTU mode)

Hardware:
USB to RS232 / RS485 converter

The RS485 converter has four terminatls Vcc, GRD, A and B. I have connected the A and B terminals to RS-, RS+ respectively. I was not certain about the ground requirements and left this unconnected to start.

My first attempt was to use Spindle Talker, which gave some run time errors even with the VB6 runtime libraries installed.

I have Realterm Software with the additional spy functionality so was able to monitor the serial data on the port. Spindle Talker did not seem to send the full string, just the first three sets of data.

So, I am now using Realterm and manually entering the command string.

The comms seem to be working as I get a 00 response from the drive when sending data, and odd data when turning the drive on and off. However when I send a data string such as 01 02 03 00 0B B8 7F 0C I still get a 00 response??

I'm hoping that someone who has got the comms working can double check my setting and maybe give me some pointers.

Thanks in advance

Scott

[TOTALLYRC]

It is possible that this drive is not fully Modbus compliant. Peter Homman is the guru of Modbus and may be able to help.
Mike

[pbeamtn]

Modbus should only require 2 wires. You do need to make sure you have "+" and "-" connected properly on both sides. Unfortunately, without more documentation, it is impossible to determine whether "A" is "+" or not. Having the wires reversed will invert the data, and communication will not work. If you don't know for certain how "A" and "B" match with "+" and "-", you could reverse the wires and see if you get something more reasonable.

I use the program Modscan to troubleshoot Modbus stuff. I think you can still download it here:

http://www.win-tech.com/html/modbus.htm#MODSCAN

It is an ancient program and the free version is time limited, but it will allow you to poll some registers and see if you are getting reasonable data.

RTU is time sensitive, so you really can't type it in manually. Data packets can be variable length, so the protocol uses silence on the line to determine when a packet is complete. I'm not sure if you are typing things byte by byte in Realterm, but that won't work. Using something like Modscan will compile the packet with the proper CRC and timing and send it out on the line.

[scotta]

Thanks for the relpys, I have confirmed that A and B go to RS- and RS+ as when swapped I get no response from the drive at all, all is silent.

I'm using Realterm to send out the full data string (pre entered) and the data that I am sending is what is published in the manual and what others have been talking to the drive.

Thanks for the link to the Modscan, I'll give it a go.

Thanks

Scott

[scotta]

I have been banging my head against a brick wall with this for the last week or so, have done a lot of googling and learnt a hell of a lot about RS485 and modbus at the same time.

And a big lesson learned - don't beleive everything you read! Make you own measurements and checks.

Today was the turning point when I borrowed a USB osilloscope and actually started seeing the data transmission. And the simple solution - SWAP TWO WIRES!!!

The labelling of the RS- and RS+ terminals on the drive and the A and B terminals on the USB converter are not as expected.

Matching the potential of the terminals (relative to ground) was the key, ignoring the labelling. A [+5V] --> RS+ [+5V], B [0V] --> RS- [0V] and Ground -> ACM. The comms still work with the 120ohm termination resistor as well. And SpindleTalker also works as it is no longer receiving the 00 response (which was not coming out of the drive but the converter itself)

[analogman]

Scott are you going to be driving this from Mach3? Will you be able to drive it directly or require some layer of software in between?

[scotta]

I'm a linux guy, so will be using EMC2. This will be the next step but with the non-standard function codes of the VFD this will be a challenge...


Scott

[henrikw]

Scotta, any luck getting it to work?

[michel pet]

any news jet??

[scotta]

I think the Huanyang engineers were off drinking coffee when the Modbus standard was being handed around. Anyhow, I have been doing heaps of research on how to drive the VFD with EMC2.

I started with ClassicLadder but due to the non standard function codes and data length descriptor this was going to be a lot of work. A big thanks to Jayson from the Mechmate forum who sent me his working ClassicLadder binary. My main problem with modifing the ClassicLadder was that if a compliant Modbus device was also to be used on the same system then the ClassicLadder modbus routines would be so twisted that it would make it unusable.

The solution that I am now progressing is to make a user space hal component. This is slow progress as I work for myself and the day to day hum drum of making money to live gets in the way. To date I have a hal component that loads and exposes the VFD control and status registers as pins.

As far as the modbus side goes, I started with the latest version libmodbus and attempted a hack, the only drama being is that libmodbus has been so well developed to be Modbus Standard compliant is that is is pretty locked up with only a few publically accessable routines to connect to.

I went digging and found libmodbus version 0.0.1 and now have rewritten this to use the Huanyang structure, and am just getting into the debugging stage now.

If there are any gurus out there that are exsperts in parsing xml config files in Linux, I am thinking of using a xml file to pass all the config data to the component rather that command line options. This will be more flexible and should allow any / all of the drive parameters to be configured during startup. A handy thing if the VFD is used to drive different motors on different machines, eg a router and a mill or lathe. At start up all of the motor parameters ( poles, frequency, base rpm etc could be configured by the serial connection). A little ambitious maybe.

First to get things talking with EMC2.

Scott

[Matty Zee]

Hey Scott, maybe you should contact Jayson from the Mechmate forum. He has successfully got EMC2 to talk to his HuanyangVFD. See here
For those using Mach3, i have written a plugin to talk to the Huanyang VFD. I will post it on the Mach3 forum and a few days. Its being beta tested at the moment.

Cheers
Matt

[scotta]

Matt,

Jayson was kind enough to give me his working ClassicLadder file but this is not the nicest way of getting things working as it nobbles the standard Modbus.

The hal component I'm working on is kinda like a plug in for Mach (except that it needs to be complied as a kernal module). This will allow other standard modbus equipment to used the ClassicLadder interface.

Going to be slow going as work is heating up with silly season.

Scott