Sign in to follow this  
Followers 0
abright52

Detecting a Comm Loss between PV+ and ControlLogix PLC

29 posts in this topic

We recently had a issue with a PV+ losing communication to the PLC, this caused as issue when the operator was pressing a momentary PB to send a jog signal to an ACS150 drive. The drive continued to jog when communication was lost, since the tag in the PLC was still a "1". An E-stop stopped the drive, but it resumed upon reset of the e-stop. The only cure was to press the same button again and release to set the tag to "0". So, I am in search of a way of detecting Comm Loss (Fault) of a PanelView+ 1500 and the ENBT/A module. The plan is to unlatch all Panelview PBs in the PLC when triggered by either of these Comm Loss events. Any recommendations? Slot 0: PLC: 1756-L61 ControlLogix5561 - Rev 16.21 Slot 1: ControlNet Module: 1756-CNB/E - Rev 11.1 Slot 2: Ethernet Module: 1756-ENBT/A - Rev 4.1 Thanks!

Share this post


Link to post
Share on other sites
Setup an DeviceWho message similar to the screen capture below. Don't worry about the actual reply data, just look for the ERR code and the ExERR to always be 0. Your path will be 1,2,2,123.123.123.123 where 123.123.123.123 is your PV+ IP Address Also, I have used this to solve the exact same problem, but you really need to solve the root problem of the PV+ locking up. Depending on your application this may not be the safest thing.

Share this post


Link to post
Share on other sites
So, just to confirm, when all is OK, .ERR and .EXERR will be 0? So I would trigger an unlatch of all buttons if either .ERR or .EXERR are greater than 0, correct? Thanks for the response. Replacing the ENBT module seemed to fix the problem, but we would like to add some code for prevention in the future.

Share this post


Link to post
Share on other sites
Yes, while not quite the same, below is how I was comparing the error codes. Also note that I am comparing the values from the destinations of the two MOV instructions that preceed the message and not the actual MSG error codes. The reason for this is that as soon as the message is reenabled, the ERR and EXERR codes will be cleared which would give you a false idea that communications had resumed. Doing it this way, the the destinations of the MOV instructions will not go to 0 until a successful message is completed. Like I said earlier, you should really evaluate the safety aspects of doing this EDIT - Ok, that last post was about as clear as mud. Here's the simple version, just pay close attention to the tag names and you should understand the need for the MOVs

Share this post


Link to post
Share on other sites
Alright, I think I see what you are getting at here. I will play around with this tomorrow and let you know if I have any more questions. Thanks, again.

Share this post


Link to post
Share on other sites
It is also a common practice with HMI controls, to require a false to true transition of the button, and unlatch it for other reasons as well. It can get complicated to detect comms losses, and it almost always requires a certain period of time to elapse. You may then also, want to unlatch your HMI pushbuttons when an e-stop is pressed for example and/or use a timer to limit the duration of the HMI command. Paul

Share this post


Link to post
Share on other sites
Let be crystal clear I understand what happened. 1, Operator Pressed Jog 2. Operaotr Released Jog and Drive Kept Jogging 3. Operator Pressed EM Stop and Drive Stopped 4. Operator Reset Em Stop and Drive restarted 5. Operator Again PRessed EMStop 6. You were called and determined that comms were lost. 7. You did something, you did not specify what to restore comms and the button although not pressed was still sending a 1 to the PLC. 8. You pressed and released the button and the tag reset to 0.

Share this post


Link to post
Share on other sites
1. Operator Pressed Momentary Button to Jog 2. Comms lost between PLC and PV - Errors shown on PV 3. Operator released Momentary Button, Drive Continued to Jog 4. Operator pressed E-Stop, Drive Stopped (E-Stop removes Drive Enable signal) 5. Reset E-stop, Drive restarted (Drive Enable signal was reset) 6. Operator restarted PLC, Drive stopped, since tag was set to zero. We were able to replicate this in-house by unplugging the ethernet cable from the back of the PV. The bit is stuck at 1, even after Comms are restored. You need to restart the PLC or press and release the same button to set it to 0. I added a run to unlatch all PV buttons on an e-stop for now, but I would like to detect that there is a problem before the operator needs to hit E-stop. This job is in France and it needs to be fool-proof. Thanks.

Share this post


Link to post
Share on other sites
Alright, here it is. I am trying to run it on a test setup and I keep getting an error on .ERR; it can be seen below. Everything is communicating as it should, but I am still getting an error. Any ideas? Edited by abright52

Share this post


Link to post
Share on other sites
Take the NEQs out of the first statement. Post screen captures of your message configuration

Share this post


Link to post
Share on other sites
Allen Bradley's Knowledgebase has some articles about the 'DeviceWho' service type. See TN 55301 and 55305

Share this post


Link to post
Share on other sites
I setup another Test PLC with a different PV+. Now I am getting a different error on both .ERR and .EXERR. I guess I need to test this on a production machine and see if I get similar errors.... I will have to wait until the next one is ready for test.

Share this post


Link to post
Share on other sites
Where's you destination tag?

Share this post


Link to post
Share on other sites
I guess that was one of the things I was wondering about. What does the destination tag need to be? What is it actually used for? It didn't seem like you were actually reading from the destination. I tried adding a DINT tag for a destination, but that didn't change anything. Thanks.

Share this post


Link to post
Share on other sites
An array made of SINT. Start with a 200 element array.

Share this post


Link to post
Share on other sites
Or if for some reason you actually want to read what it's returning...seems like I had to do this once for some reason...create a string only instead of pointing to the string such as MyString, poing to MyString.Data[0].

Share this post


Link to post
Share on other sites
It doesn't seem like it is even getting that far, nothing goes into the Destination. Do I need to add the PV+ to the I/O Configuration within Logix?

Share this post


Link to post
Share on other sites
You shouldn't and can't add the PV+ to the I/O configuration but your right, the "Error Processing Connection Related Service" doesn't seem right. It's been a while since I worked with a Panelview Plus. That seems more like it was able to establish a connection but the PV+ didn't know how to respond. Almost everything AB has can respond to that request except some of the older PLCs. Beginning to wonder if I have completely forgotten something in the path. Will you browse RsLinx, expand the PV+ as far as you can and do a screen capture?

Share this post


Link to post
Share on other sites
Here is what I am seeing in Linx.

Share this post


Link to post
Share on other sites
Ok I just got a message that what I'm trying may not be supported with newer firmwares. I'm just not sold on that yet... Try changing the path to Ethernet_Bridge,2,192.168.1.8,1,0

Share this post


Link to post
Share on other sites
Made the change, but unfortunately, it is still giving me the same error.

Share this post


Link to post
Share on other sites
You need a Destination tag so that the MSG instruction has a place to put the data it gets back from the device. I used a SINT[150] tag and got 134 bytes of data, which is the CIP identity (including the "PanelView Plus CE" text name string) of the PV+ terminal. Be sure that when you enter the destination tag you include the array subelement: "PVPlusID[0]" is the correct format. You could also use a Get Single Attribute and check for the Vendor ID or the Device Type to verify that the PV+ is still operating. While you are at it, call up your A-B rep and see if you can get the local manager to hear your opinion that the PV+ should have an EtherNet/IP implicit I/O connection like the Standard PanelView terminals did. The RSLinx Enterprise communication driver is pretty efficient, but for circumstances like this an I/O connection would be a superior mechanism. They exist for ControlNet, DeviceNet, and RIO, and there is no technical reason they can't exist for EtherNet/IP too.

Share this post


Link to post
Share on other sites
Thanks for jumping in there. I couldn't imagine this feature being removed. I talked to some of the developers a while ago and they said it was on the list. I think it would be a great improvement also

Share this post


Link to post
Share on other sites
For DeviceWho message configuration see tn 55301 and 55305

Share this post


Link to post
Share on other sites
Thanks for the additional information, I will play with it more this afternoon. Hopefully I can get it to work. I have already looked at those, as suggested previously. http://forums.mrplc.com/index.php?s=&s...ost&p=74307

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