Help with Modbus serial writing to a VFD

[aidanBeans]

Hi,

I am trying to control a Kinco FV100-2T-0007G VFD through LabVIEW over Modbus. I have it connected via an RS485 USB cable.

I'm new to Modbus and having some trouble figuring out how to "translate" control commands and parameters into Modbus messages. The VFD's manual lists the Modbus RTU frame format, the register addresses in hexadecimal, and the bits for each parameters on the VFD in binary (attached as images). I'm confused how I should be inputting these numbers into a LabVIEW VI using the NI Modbus API.

I've attempted to write a test VI, but I can't try it without knowing how to address the register and how to encode the command. It likely has mistakes as well, which I would appreciate any feedback on.

Can anyone explain how I can translate my commands into a Modbus frame, and how I can sent that frame using LabVIEW?

Thanks in advance

[tst]

A few notes:

1. The Modbus VIs already implement the Modbus protocol, so you don't have to handle that.
   1. It's highly unlikely that they implement all of the Modbus functions listed in that table, as some of them are not standard and some of those that are, are rarely used. That said, you might not need all of them for the functionality you want. For example, calling the Write Holding Register VI will probably execute the function you showed in your particular example (it's function 6, write holding registers, which is not explicitly stated in the document, but is likely).
   2. If you do need some custom ones, you would probably need to edit the library, which would be a mess and I'm not sure if you can even do (it might be locked), so I would start by checking if you need any of the non-standard functions.
2. Note that if it's RS485, you need the hardware on the computer side to support that (for example, by using a USB-RS485 adapter).
3. Note that you also need to know what Modbus ID has been configured for the device and wire it into the first VI.
4. You might also need to configure the device specifically to use Modbus RTU or Modbus ASCII and match that on the LV side.
5. Assuming all that is correct and you're calling the Write Holding Register VI, then your example should work. You would need to supply the correct address (0x3200, which is 12,800 in decimal). Note that off by one error are common here, because sometime things are treated by register number (starts from 1) and sometimes they are treated by address (starts from 0) and there isn't always consistency.
6. You will also need to set the correct value for this register. The table tells you what each of the 16 bits does.

[aidanBeans]

Hey, thanks for the reply! With your advice I was able to get my test script to turn on or off the VFD! New VI is attached below.

However, it throws an error upon closing the connection:

Error 56: "The network operation exceeded the user-specified or system time limit". Screenshot below.

I presume this has something to do with the timing of the communication, do I need to add a delay somewhere? This error seems to stop me from making successive register writes, as if I loop the register write block, it will only send a command once.

Thoughts? Thanks!

[tst]

Using error 56 to signify the timeout is a bit weird, because that's a network timeout error and you're using serial, but I guess whoever wrote the library decided that was the best option.

If you look at the error you can see it doesn't happen when closing the connection, but inside the Read ADU Packet VI, which makes sense. It means that the code tried to read X bytes from the serial connection, but Y ms passed without getting all of those bytes.

If you dig into the code (the password is "bestbus", which you can find by searching online), you can eventually find that it waits until there are bytes waiting at the port and once that's stable it tries to read them and it calculates the timeout (in the create serial master VI) based on the baud rate and what it expects is the max packet size. I'm guessing that part works, so it's possible the device isn't answering to a command it's supposed to answer to or that maybe there is something wrong with your cable/setup. I would suggest using commands which are guaranteed to return data and debugging what you're getting back.

[aidanBeans · Accepted solution]

Thanks again.

I was using a full-duplex RS485-to-USB like this, shorted to act as a half-duplex cable. I switched to a half-duplex adapter and the error seems to have disappeared!

Attached is my working control VI for anyone in the future.