Emerson Exchange 365

• Not Answered

DeltaV HMI over VIM2 EtherNet/IP

All,

I encountered something very strange last week when I was on-site at our customer's facility as I was commissioning the system.   There was 2 issues that I can't wrap my head around:

1.) Everytime I upload the new VIM configurations and export the FHX file to be imported into the controller, it would stop the E300s and other devices connected to the VIM.  I would have to download the new configure, then stop the device and start it again.  This poses a serious problem if the motor is critical to the process.  Anyway setting to have only the updated devices stop and keep current actives devices run at current state?

2.) When there is a communication loss between the VIM and E300,  the DeltaV HMI dynamo shows the motors as Running (in terms of colors) but in reality, the physical E300 are not running if communication is lost (say someone pulled the RJ45).  In other words, I have the RUN status feeding back into a DC1 block and the DeltaV logic holds the value of the motor as running.  Is there some type of feedback that will tell the DeltaV system what is the current state of E300 when there is a loss of communication?  

We have a S-Series controller with VIM2 card.  All our motors where either PF 755 or E300 connected via EtherNet/IP. 

JPC1080

• 22 Apr 2019 7:05 PM
• Cancel

3 Replies

• Andre Dicaire

  

  • 22 Apr 2019 8:24 PM

  Is the VIM emulating Modbus Serial cards or DeviceNet cards. You have a choice depending on the version of driver you've loaded.
  
  A loss of communication should result in a Bad Status on the dataset or the Device Signals. They may hold last value, but the status should be BAD.
  
  There a many different ways engineers have configured Ethernet data into the DeltaV Controller via the VIM. Pre-v12, landing modules were used to bring in Modbus datasets and parse out the data into parameters used by the modules. In this scenario, the status seen by the module is filtered by the Landing Module and one has to evaluate how status was handled. In v12 and beyond, license changes allow one to reference datasets directly without DST penalty and so landing modules can be avoided. However, if you have packed bits into integers to avoid some licensing, you may still have landing modules.
  
  With E300, I would expect you've used the Class 1 messaging with instance attributes. If mapped as a deviceNet card, up to 16 signals can be created and referenced in the modules for the price of one DST license. These should have Status associated based on the health of the device, and should be BAD if not communicating.
  
  Then, there is the matter of how the actual modules are configured to indicate a loss of communication or reflect an unknown state. The DC block PV is what is shown in the HMI. This is based on the state mask and connected inputs. If there are no inputs, the PV will follow the SP. If the PV is set by a Condition block, which reads a landing module or a direct signal or dataset, it may be "stuck" on because there is not action on error. You have to look at the module's configuration. At least, the default Dynamos look at the DC/PV_D. if the dynamo is custom, who knows. Start by ensuring the HMI and Control Module function block agree.
  
  As for the first item, I'll leave that for someone else to comment on.

  Andre Dicaire

  • Cancel
• JPC1080

  

  • 22 Apr 2019 8:42 PM

  In reply to Andre Dicaire:

  Andre,
  
  Thank you for the explanation. Class 1 Messaging I/O was used. You are correct in that the data was brought back with landing module. The E300 has a status dataset (32UINT) that is brought back and is split into 2 sets of 16 BFO. E300 really doesn't have a run status bit (at least I don't see any, if anyone know which parameter, please do tell!), so the "Current Present" (bit3) was used to indicate a Running status (assuming no amp when not running). This bit3 was then used as an internal reference input parameter going into the DC/F_IN_D1 of the DC block. The DC block's DC/F_OUT_D1 also has an internal output reference that goes to a landing module to send a RUN command bit to the E300. This is how the DeltaV HMI dynamo is connected to the color. I just don't see where there are other status feedback bit for me to tie into the DC block.

  • Cancel
• Andre Dicaire

  

  • 23 Apr 2019 1:12 AM

  In reply to JPC1080:

  The landing module needs to proceed status of the dataset connection. This is deltav Status. When not communicating the device status is unavailable.
  
  The external reference in the landing module has .CV and .ST. You can also read the device OInteg. Do not use the card OInteg as this is bad if one device is not communicating.
  
  Error handling is often not considered and it looks like in your case lost of comms is not being detected by the module/DC block and so PV is not reflecting bad status.
  
  I would start by observing the diagnostics and io references to find the desired indication of lost comms. If the landing module is using parameters without status, you could change them to be with status and have the leading module evaluate communication health and explicitly set .ST to bad when the conditions are indicated.
  
  Then in the controls module you know when ST is bad it is due to comm issue.

  Andre Dicaire

  • Cancel