Sign in to follow this  
Followers 0
Ken Roach

Controllogix Prosoft Module

6 posts in this topic

Welcome to the Forum, Doug ! Your post ended up in the "Product Reviews" section so it won't get a lot of traffic. I recommend re-posting in the main PLCs and Supporting Devices section in the Allen-Bradley division (since it's the most active and the Prosoft module is related to the A-B controller). I haven't used these two specific devices but I've used the MVI56-MNET and done a lot of Ethernet troubleshooting. There are several variations of the Prosoft MVI56-MNET; there's the MVI56 versus MVI56E Enhanced platform, the Standard versus Multi-Client versions, and the Standard versus Reduced Data Block versions. Which exact one do you have ? Are you able to get just one device working, but a large number of them fails, or are you unable to get even one running ?

Share this post


Link to post
Share on other sites
Hi Ken, First, thanks for the advice on re-posting. The Prosoft module that I have is the MVI56-MNETR. The module is in a remote rack on Controlnet. We are attempting to communicate to and from the Square D MCC TeSys-T modules. We also have an Altivar 71 drive as well. As I had stated, we can use a modbus slave simulator to prove out the Prosoft module and we see the data on our Wonderware HMI screens, but when we try to read or write from the same Modbus registers in the TeSys-T units, we cannot see any values in the tags on the Allen-Bradley side, nor can we see any data in the command word that we write to in the TeSys module when we enter a value in the Controllogix tag. However, on the other hand, we can access the TeSys using Square D's software and see the values in the registers that we are trying to access, so we know they exist, but never make it to the Prosoft module. This holds true for all of the Sq. D devices. (They are identical, but have unique IP addresses.) Any ideas that you might have would be greatly appreciated. I will also repost in the A-B section. Regards, Doug

Share this post


Link to post
Share on other sites
I have a project where we are trying to communicate to 30+ Sq. D TeSys T modules via TCP. We have an Allen-Bradley Controllogix with a Prosoft MVI56-MNETR module that converts A-B TCP to Modbus TCP. While I can communicate using a Modbus slave simulator without incident, we cannot read from or write to the Square D TeSys T. We can also see the Square D side of things using their PowerSuite software, so we know that there are values in the registers that we need to send/receive data to/from. Has anyone had any experience with the TeSys and/or Prosoft modules? Any suggestions?

Share this post


Link to post
Share on other sites
Sounds like the Square D stuff isn't compatible with Modbus TCP. The Peosoft module is apparently working as evidenced by your test with a slave emulator

Share this post


Link to post
Share on other sites
Michael, The whole reason behind installing the Prosoft module was because Square D Talks Modbus TCP. I suspect that there is an issue with either the Square D setup or the way that the packets are delivered to the Prosoft module. BTW, Square D tech support was able to verify my offline configuration for the TeSys-T. However, you must be online to access the majority of the parameters in the TeSys-T and i was not at the install site when I spoke with them. I am looking for someone who may have had the opportun ity to work with the teSys or has extensive Modbus TCP experience or Prosoft MNETR experience. Thanks for your input.

Share this post


Link to post
Share on other sites
Doug, The MVI56E-MNET module should be able to communicate with any device that supports Modbus TCP/IP protocol. A couple of things to check. 1) In the configuration for the Modbus commands section, what Device Address are you using. With the MNET module, a FC 3 with a Device Address of 0 will issue a poll for Modbus address 40,001 in the slave device. So you will want to make sure that the FC and Device Address fields are configured accordingly. 2) If you are using a FC (function code) of 3, have you tried a 4? Sometimes you are using the wrong function code for the application. 3) If you monitor the Command Error code, are you getting any errors for those commands? 4) Lastly, if you have the ability to obtain a Wireshark capture of the communications between the Square D software and the device, ProSoft will be able to take a look at this and see how the software is polling for data. They may be using Encapsulated Modbus (also supported by the MVI56E-MNET module) instead of the standard Modbus TCP/IP (MBAP). ProSoft has a training video on this product on their website. It is a step-by-step tutorial on the product. It sounds like you have progressed beyond this, but it might give you some ideas of what could have been missed. http://www.prosoft-technology.com/training/mvi56emnet.php And lastly, if you have any questions I'm sure ProSoft support could give you a couple more ideas. But if you have the ability to get a Wireshark capture, this would certainly allow them to make suggestions based on the software that is working currently.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0