Are you looking at the modbus library that comes with RT/DSC? If you want Ethernet/IP advice, your best location to post is the Industrial Communication forums. There's generally a better audience for that protocol there.
I have not used Modbus over TCP/IP before, but I have done it with RS-485 serial ports to other brands of both AC and DC motor drives. I used the modbus library available through MODBUS Library for LabVIEW.
As natastfw pointed out, if you have the DSC module in your LabVIEW suite, there is a Modbus library under one of the palettes. Data Communication, I believe. It is new and I just found out about it in the last couple weeks. Quick glance it looks good, but I haven't had an opportunity to use that one yet to be able to comment further on it.
I have done LabVIEW projects with the ACSM1 drives via Modbus/TCP. Works well. Modbus protocol with ABB drives allows direct access to any drive parameter in addition to the mapped ones. Ethernet/IP parameters have to be mapped, and hence are limited. Not all values are in their native scaling when they come over Modbus, so you will have to watch out for that.
As the previous posters pointed out, there are a couple of VI libraries available. LabVIEW 2014 added Modbus VI's with the DSC and LabVIEW Real-Time. The others you would have to get and add in yourself.
Another option is to use LabVIEW I/O Servers; as long as you have DSC or Real-Time, you can create Modbus I/O Servers as library items and deploy to a target. You don't get as much direct control in this way (and may run into difficulties if you need them to be field-configurable and do not have DSC) and use bound network shared variables, but they are very fast and easy to setup and I have yet to have any issues with using them in my applications.
As for using an Ethernet switch to connect multiple devices, I have used this approach many times to simultaneously connect and control numerous PC's, real-time controllers, and drives without issue. I would not expect there to be any problems unless you have extenuating circumstances. In fact, if you only have one network interface on your device at the moment, I would recommend against adding a second, as this would mean that you / your controller would have to be extra aware of which interface everything is assigned to go through.
Can someone help figure out what to send uasing ni modbus library to make this thing run! I've RTFM!!! several days already. it is not the most intuitive communication protocol. I should of stuck with serial.
Basicly there are control words that need ot be sent like 1150 then 1151 to ready the device and start it. And thats what you would send using serial. but then you dig deaper and the module has address locations that are 400001 for control. and maybe you send 1150 1151 to that address using laview? cant get that to do anything. Then i noticed that from other posts you drop the 4 and you subtract 1 so 400001 = 0. so i tried address 0 then sending 1150 1151 to the ACS355.....nothing. Well if you look at 301 you can see the commands you sent to the device. thing is i send 1150 1151 and i get a HEX number at 301 that is not = to 1150 or 1151, i tihnk i got sometihng like 201 or 221 in hex... then i thought hilo byte order backwards. switched that on the controller and same outcome.
I have only done this with the ACSM1 using Transparent 32, which would be different for you. You should be able to just send 1150 or 1151 to the control word, and the speed reference using the ABB drives profile. The control word will be at register 0(really 40001), but if you are using a modbus function from the library, it will really add 40001 behind the scenes. You must also be sure that the drive is setup correctly to be controlled via the fieldbus adapter. If you have a VI or DriveWindow Light file, please post if you can.
here is snipit to show how simple it should be. what am i doing wrong? do i not use holding registers to send the control word? I've tried with only 1150 only 1151 combination in sequence since i've read you should have sent stop/ready before start.
Need to figure this out this week. it's what i expected to be the difficult part of the project since i'm not familar with modbus. but it should really be simple if labview has amodbus library for it already.
I saw the Drive Windows Light somewhere. I will have to find it and try it out. (could always use wireshark to figure out how all the network packets are sent if it works and reverse engineer the calls, bypassing modbus api )
I can request basic model information from the device. Using the NI modbus examples there is a modbus function to retrieve information from the device. All this comes back so i know i have basic comunication working between the PC, FENA-01 and the ACS355.
And the drive has a front panel that i can watch the data comming in. looks like parameter 301 is modbus data. but it never matches what i send through the modbus api. So i really dont know what the api is doing behind the scenes. I would like to understand how the low level works a little better. so maybe some more light reading.
c80f0f1006