Emerson Exchange 365

• Not Answered

AB drives NetIO timeout. What could be the issue?

Hi,

We have 10 drive on our VIM network using the EthernetIP drivers, split between two VIM's (on the same subnet). Occasionally we are dropping the drives, not all at the same time and at random, for a very short time.

In Diagnose, the only issue that comes up is a Status = Error Response on one part of one channel. the VFD's on this port fault out the most. The other curious thing is, we also have smart overload relays on the same VIM network, but never experience any issues with them.

So two questions:

1) Can anyone shed light and/or share experience with the Error Response issues?

2) Are there know issues with integrating AB VFD's with DeltaV and is there a work-around for these issues? 

Thanks all.

Roman

• 11 Jun 2018 3:01 PM
• Cancel

9 Replies

• fairchdm

  

  • 11 Jun 2018 3:20 PM

  Roman,

   

  We have nine AB 755 VFD’s, on a VIM, in our process and I’ve never seen your error.

  My first thought would be the “heartbeat” communications time is at or near the very limit of what each drive requires.

  A small network lag and the drive times out.

   

  We pulse the heartbeat once a second to ensure the drive communications stays active.

  It’s been awhile, but if I remember right it’s a register in the AB drive N45:1.

   

  I’d have to go back to the manual to verify that.

   

  Best of luck,

   

  Dennis Fairchild

  ICE Lead

  McClain Power Plant

   

   

  • Cancel
• Roman

  

  • 11 Jun 2018 7:31 PM

  In reply to fairchdm:

  Hey Dennis,
  
  What type of drives are you using? I've check the manual for the PowerFlex 755 series drives and couldn't find a hearbeat register. I always thought that implicit comms on EIP keep the ports open indefinitely.
  
  Thanks for your reply.

  • Cancel
• fairchdm

  

  • 11 Jun 2018 9:07 PM

  Roman,

   

  I had to go back and dig up my book and look at the module in the DCS. 

   

  We are running Powerflex 755 drives.  The manual I’m looking at is the AB “Embedded Ethernet/IP Adapter”, Appendix C-8.

  What I was calling the “heatbeat” is actually the read/write delay timer, register N42:3. 

  I write the value to N42:3 from the DeltaV to 30 seconds, at every module scan.

  N42:3 has to be set between 1 – 32767.  If the delay time between network communications is exceeded register N:45 will stop talking.

   

  After maintenance on our drives we sometimes have to “manually wake them up” to reestablish communications with the VIM network.

  Maybe network traffic/collisions is slowing your data transfer down and allowing your drives to randomly fault out.

  VIM1 data transfer has lots of collisions, by its design.  I’ve watched a data port on my VIM network switch show collisions for almost 10 seconds.

  Not sure if this is your error, but it’s worth a look. 

   

  Stay safe,

  Dennis

   

   

   

  • Cancel
• JoseCarias

  

  • 12 Jun 2018 3:35 PM

  Roman:

   

  I would like to check with on the following items

   

  Are you using Class 1 or Class 3? What are the timeouts  values? Are you using Manage Switches? If you are using manual switches we could easily get the root cause setting up a drive with mirror port and also other session on the VIM/EIOC depending of your case.

   

  Do you have the ODVA driver?

   

  Best Regards

   

  Jose​ Carias | Project Manager II

  Control Southern Inc. | 3850 Lakefield Drive | Suwanee | Georgia | 30024

  T: - | M: 770-243-0619 | F: 770-623-3663

  Jose.Carias@controlsouthern.com

   

  • Cancel
• Roman

  

  • 12 Jun 2018 8:02 PM

  In reply to JoseCarias:

  Jose,
  
  We're using Class 1 (implicit) comms on VIM2 with ODVA Ethernet/IP drivers (version 1.3.17). Although we are using managed switches, no management strategy is applied (i.e., no vlans, routing, or anything else).
  
  I don't have the actual ODVA driver - I'm assuming that's something that is loaded by MYNAH.
  
  Thanks all.

  • Cancel
• Ashwini Venugopal

  

  • 26 May 2021 10:15 PM

  In reply to fairchdm:

  Dennis/All,
  
  I was going through this thread to get some answers to similar issues I am currently running into. we are using the EIOC to talk to smc flex drives using Class assembly instances/ implicit msg. Every so often, like every week or 10 days one of these drives will lose comms and display Fault 32 at the drive end. After reset, communication is back up till the next drop. I previously had this setup to with PCCC explicit messages and was using the control timeout to be written to . Reading through this my first thought it to set up control timeout writes to N42:3 like I did prev. how does your VIM talk to powerflex - class 1 or 3? thanks in advance
  
  Ashwini

  • Cancel
• fairchdm

  

  • 4 Jun 2021 6:30 PM

  In reply to Ashwini Venugopal:

  Ashwini,
  
  Sorry for the delay in response. I just noticed your email.
  
  For the AB 755 drives I am communicating through the Mynah VIM1 card to DeltaV.
  All of the VIM Device Connections to the AB 755 Powerflex drives use the UCMM Message Type with DF1 enabled.
  The VIM is connected to a loop network to interface with all of the AB Powerflex drives in the process.
  
  I'm sure you know this already, but I checked the SMC Manual and Fault 32 is "Check Comm Adapter with SMC"
  Are you using the AB 20-COMM-E communication card in the SMC?
  Are you using Port #2? (Default Comm port)
  Did you double check the Comm Enable Mask? Parameter 87
  Did you double check the settings with the AB Ethernet/IP Manual?
  (e.g. literature.rockwellautomation.com/.../20comm-um010_-en-p.pdf)
  
  What is the value you are writing to N42:3? I write 30 second with every module scan.
  What are your time-out delays? In the EIOC and the Drive?
  
  Is there a network switch in between the EIOC and your SMC drives?
  Could you set up a span port on the switch and monitor network traffic with Wireshark to check for errors?
  
  Best of luck.
  Dennis

  • Cancel
• Ashwini Venugopal

  

  • 14 Jun 2021 4:20 PM

  In reply to fairchdm:

  Dennis,
  
  thanks for your response, much appreciated. I just saw this: i use the implicit messaging protocol to talk from eioc to end device. more details about setup below...
  1. I do have a 20-comm-e adapter communication card to the SMC
  2. not sure if its port #2 but the default comm port is used. i'll double check if its #2
  3. will double check if parameter 87 is enabled.
  4. i checked the settings with manual, talked w rockwell few times. I believe we are good w settings
  5. noticed that you write to N42:3. i used to previously but removed this timer. the devices are run for many days before tripping. shuld this timer be written to frequently like a watchdog?
  6. eioc timeouts after 3 seconds. there are no timeout delays at the drive end. how would we check or set this up, please advise? i would need ateast 4 second delay as EIOC redundancy has a lag time of 4 s in case of active controller failure.
  7. there is a network switch i can tap into.
  
  thanks again,
  Ashwini

  • Cancel
• fairchdm

  

  • 7 Jul 2021 7:19 PM

  In reply to Ashwini Venugopal:

  Ashwini,
  
  Sorry for the delay in reply.
  Have you re-enabled the N42:3 write function? Per the AB manual it is required to enable the communications to the drive.
  For the EIOC are you getting any errors in DeltaV? DV Diagnostic show anything? I'm not using an EIOC so I can't offer any advice for that configuration.
  
  Depending on the network switch manufacturer, you should be able to configure a SPAN port to view the Ethernet traffic between the EIOC and the drive.
  Here's an example for Cisco switches.
  community.cisco.com/.../3132032
  
  Once you configure the SPAN port you will need to install Wireshark on PC to view / record the data between the devices.
  www.wireshark.org/download.html
  
  There are instructions on the Wireshark site for how to configure and monitor your network traffic.
  
  Best of Luck.
  Dennis

  • Cancel