I understand that there are different registers to be used depending on what you are trying to read/write but what confuses me is that every single parameter memory address starts with a 4, even for coils. Does this mean that I have to use a "Read input Registers" block every time I want to send/receive data to/from the VFD? If I understand correctly, function code 4 corresponds to reading input registers. What I don't understand is why every single Parameter in the Durapulse manual starts with a 4. What if I want to read/write a single coil? Even those parameters start with a 4.
**Parameter P9.04 for example has either "00" or "01" as options for its parameter settings, so why does the address start with a 4?**
Why do you think it is considered a "coil"? Even if it is a boolean type of parameters with only two choices, either a 00 or a 01, you could still treat it has a Holding register and write 0 or 1 to it meaning false or true.
In reality, it really doesn't matter what that first number is because it gets dropped anyway. Only the command itself determines whether you are sending boolean or "coil" data, or numeric, holding register data. From what I've seen, (but I have seen so many different modbus parameter lists to be sure), is that you can't have a 00001 and a 40001 coil and holding register address simultaneously. At least the installations I've seen, the address part of the number has been seqjential even though it may be a coil address (0) input register address(3 prefix) or holding register (4 prefix).
Ultimately, the best way to know what is right and wrong is to just try it and experiment until you find out what works.
I think Automation Directs documentation puts the 4 in the register for your Modbus function 4 read registers. I am not sure the Dura pulse VFD supports read and write coils. I know it treats read inputs and registers the same but I think you can only write to registers. https://cdn.automationdirect.com/static/manuals/gs
Look at pages 5-70 to 5-75 in the manual that Dave linked to.
All of the addresses begin with 4 which mean Holding Registers, even those registers that are marked read only. That means you use function code 3. Look at page 5-75 and it shows that function codes 3 6 and 16 are the valid codes typically sent to the drive.
If you also notice, you'll see something I pointed out before in another message. Take the decimal register, drop the 4, and subtract 1. Convert that new decimal value to hexadecimal. Now you have the value shown in the hexadecimal column and that is what you use when entering the command. That hex value also correlates with the menu and parameter number. So hex 0705 means menu 7 parameter 5, or 7.05. Hex 0A02 means menu 10, parameter 2.
Thank you for your help Dave and RavensFan,
I understand that I need to change the VFD communication protocol settings from its default setting.
These are the options l am given in the manual (I plan on using setting "03");
If I understand correctly, In order to use this setting I had to go into Device Manager and change the stop bits (for my USB-RS485 adapter) from "1" to "2". This should theoretically work right?
Theoretically, that would work.
1. The device manager settings are what is default for a serial port. You change them there and now it works. But what if you install on another PC? Will whoever does that remember to change the settings on that PC? Or what if you get a new serial port number assigned on this PC (moving a USB adapter will often do that). Will you remember to go to "Com4" and change the setting like you are for the com port you are configuring now?
2. VISA settings in Measurement and Automation Explorer I believe can override device manager. So you might need to change it there instead.
3. Ultimately, your VI can and often will override those settings depending on how you program it. I don't remember which of the Modbus libraries you are using at the moment, but if they have the initialization subVI, that will usually set the serial port parameters. So it may work alright now, or you might have to modify the parameters in your VI to be the right number of stop and parity bits. I believe when I used the INIT subVI for one of the older libraries (black and white icons), the INIT assumed some standard stop bits and parity, but it didn't match my device. So I didn't use the libraries INIT and just used the VISA serial configure and set the parameters explicitly with that. Now I know the libraries didn't upset anything, and I don't care what Windows Device Manager or MAX were set to.
The one thing I'm not sure about with the newer Modbus libraries is that they seem to use LVOOP, and you might be required to use their version of init or create to get things working.
Opening up MB Serial Init for the older library I use, I see that for RTU mode, it is hard coded for 8 data bits, 1 stop bit, and you can choose your own parity. That means only mode 4 or 5 would work for you without setting the parameters yourself or modifying that subVI. (For ASCII mode, it is set for 7 data, 1 stop bit, choose your parity) So only modes 1 or 2 would work for ASCII mode.
(I really think leaving stop bits off the connector panel in that subVI was a bad decision or design mistake by the creators of that library.)
Now the other two modbus libraries, the one with the purple header, and the one that is white but colorful icon, they don't seem to expose stop bits at all. And I don't think you'd be able to modify them your self because the VISA reference wire gets privatized within the object classes.
In the end, you'll probably be better off if you use option 4 or 5 and use either even or odd parity. They have 1 stop bit which is what all the libraries want to use.
I always use the default values for the serial port and change programmatically the serial parameters in my labview vi. using the serial visa configure port. You can make the port number selectable at runtime if using a usb to serial convertor. I also use the GS-EDRV100 Ethernet to serial convector. This allows you to change from Modbus-rtu to Modbus Ethernet. About $200
Hello RavensFan (and Dave),
I attempted creating a couple block diagrams and running them. I was receiving error status 56, so I went into NI-Max and changed the VISA settings for the USB-RS485 adapter and validated it. I ran my program after doing this and I no longer received an error.
The motor I am trying to run however, had no response to the program I had made. I then decided to try and use the VISA configure serial port but I noticed a broken wire when trying to connect that to my existing block diagram.
Shown below are a couple block diagrams I have tried (and below those is the broken wire I get when trying to use VISA configure serial port);
Perhaps there is an issue with the input data or address (maybe the reference frequency data?) that I use when writing a register? Shown below are pictures of each parameter used in the block diagram and their functions which I pulled from the manual.
**Parameters P4.00 and P3.00 were required to be modified in order to use Parameters P9.26 and P9.27**
Perhaps there are more settings I need to change in NI-MAX?
I was curious as to if it would be a good idea to make sure my USB-RS485 is working by using the "VISA Test Panel" located in NI-MAX.
I opened up the test panel and didn't really understand what I was doing though. Clicking around I did notice an "Invalid property value" for attribute "Is Port Connected". I don't really know what this means but shown below is a picture. That was the only attribute that was in red font.
You set the drive com settings (Group 9) from the keypad on the durapulse drive first. These have to be configured before trying to communicate to the drive. After setting parameters ensure you power cycle drive.
Dave is correct.
I was busy answering your questions about how to set the parameters, and about parity and all that. I missed the key logical point that you CAN'T use Modbus commands to tell the drive how to communicate it Modbus!. It would be like me saying to you "I'm going to give you call so you can tell me your phone number to call you at."
For your broken wire, look at context help. You are connecting a VISA reference to a VI that is looking for a LVOOP object as its input. Notice how your other ones you have the Create Modbus VI that takes the VISA reference and creates the object wire that is used down stream in all those other subVI's. Now you "might" be able to put the VISA Configure ahead of the Create Modbus on the upper two. But there is almost no reason to do it because the Create Modbus is setting most of the serial parameters inside of it overriding anything you would have set in the VISA Configure subVI.