Emerson Exchange 365

• Not Answered

DeltaV Communication via VIM

Hi,

we have some issues between an ABB DCS communicating with a VIM card via mapping table. From time to time (~1x day) we are getting comm failures. The scan rate for the module is 200 ms. Within the module there is an OND block that initiates the alarm if the Heartbeat has not changed within 5 sec.

I am trying to find out where the problem is. The VIM diagnostic registers have been setup and data is collected continuously. The attached picture shows a snapshot of about 15 h. It looks like the events fall into the area where poll queue and free buffer numbers go from 0 to 100%, otherwise the queue is pretty low and the free memory is high.

What do these numbers actually mean? And, how could this condition be improved? I am assuming the events are related and there is increased network traffic.

I can supply more details of our system.

Thanks

ThomasG

• 1 Nov 2015 6:02 PM
• Cancel

7 Replies

• frederg

  

  • 7 Nov 2015 3:09 PM

  A suggestion is to increase the RPI

  • Cancel
• bilal761

  

  • 17 Nov 2015 7:04 PM

  Hi,
  
  We are also experiencing same thing on one of our site. Ironically, it is also ABB PLC we are communicating with, which controlling Ball Mill GMD. I have noticed if you put the transmit delay on port>Properties>Advanced to 500ms, it improves the situation.
  
  One quick question, how did you record the statistics data from port diagnostics such as Percent Avail Buffers and Poll Queue? I can't seem to find them when I want to set them for trending using external reference.
  
  Thanks.

  • Cancel
• bilal761

  

  • 17 Nov 2015 7:11 PM

  Data Poll Queue = Number of messages waiting to be sent to DeltaV

  • Cancel
• HECTOR H. TORRES

  

  • 18 Nov 2015 2:04 AM

  Hola, we have seen the same issue. We are pulling data from a PLC and from some VSD's. We are gathering around 130 registers in total of 16 datasets. As someone suggested you should decrease the traffic to the VIM by increasing your RPI (Requested Package Interval); this is, evaluate if the actual execution has to be as fast, if not increase RPI. It just takes one single change in any given register inside a dataset to trigger an update the entire dataset from the VIM to the PLC or DeltaV. If you are combining registers that need to be fast with registers that could be executed at a lower rate consider breaking that up and create "logical" groups by RPI/module execution rate.
  
  I was trying to plot the Percent Available Buffers? how did you make it? I am using DeltaV version 12.3.1 and using Sx controllers. I cannot see those diagnostic parameters inside the controller nor the port.
  
  Héctor

  • Cancel
• ThomasG

  

  • 20 Nov 2015 7:53 PM

  In reply to bilal761:

  Created diagnostic data set in the VIM (device data type: 6), build module to read in all available data, historized data
  There is a user manual from Mynah which explains all the registers: "Modbus TCP Master/Slave Driver for DeltaV Virtual I/O Module"

  • Cancel
• ThomasG

  

  • 20 Nov 2015 8:03 PM

  In reply to ThomasG:

  Found one possible reason for the intermittent com problems. Sometimes when the feed rate of the mill is changed we got com faults. There is lots of traffic between different controllers in different areas at this time. Also the controllers are loaded quite heavily. This doesn't account for every event though.
  
  Thanks

  • Cancel
• WSoon

  

  • 26 Jun 2020 3:28 PM

  In reply to ThomasG:

  Hi Thomas,
  
  Did you manage to fix the issue?
  
  We are experiencing very similar issue to your case. We have Siemens PLCs and smart transmitters communicating over Modbus TCP using Vim2.
  In PHV, there are random events of Output transfer failure or input transfer failure depending on the dataset that is failing. We see a pattern here that these random failures recovers after 5-6 seconds causing soft modules referencing these failed registers to trigger module_alm. We thought this might be faulty card however, this scenario is happening across 4 different vim cards and the devices do not experience the disconnection at the same time.
  
  The port settings in explorer are default (retry count = 1, message timeout = 1000 and transmit delay = 0).
  
  Thanks!

  • Cancel