Emerson Exchange 365

• Not Answered

Preventing DeviceNet download blip when adding a new device with SYSSTAT

I just got back from Emerson Exchange in Minneapolis. I went to the DeltaV 'Meet the Experts' session and asked if there was a way to prevent our DeviceNet networks from failing when we add a new device to the network. One of the 'experts' told me that he has seen it done with the sysstat function. I think he said he used the function to detect a download and then held the output for 30 seconds?

Does anyone have any experience using this function and might be able to get me started?

Thanks!

• DeviceNet DeltaV SYSSTAT

Craig Waldschmitt

• 9 Oct 2017 1:51 PM
• Cancel

6 Replies

• Matt Forbis

  

  • 9 Oct 2017 3:00 PM

  I was the "expert" who said that.  We are using modules based on the PCSD library, particularly the MLSSD class.  Here is an example of code we have in our modules to help ride through the download on the port.  It doesn't work 100% of the time, but definately cuts down on problems.  The biggest area we notice that is in the field start stop logic where the bad status on the Discrete inputs cause the logic to execute when the field button was not pressed.  In the Field Start Stop composite, we added the following logic at the top.  This basically will count up for x number of scans after a download of anything that affects the controller.  

  

  In addition, another we change to the module was to change the top level PV_D away from an internal reference to just a named set.  Inside an action block in the module, we have this code.

  

  This code will hold the last PV for x scans so that devices referencing this module don't fail immediately on a bad status.  If you don't have the local start stop composite, you might have to change this code to work in your case.

  I also know in some cases, based on how you add the device to the segment, and when you enable IO polling on the device, it helps ride through bumps better than other scenarios.  I believe it's best to add the device place hold with IO scanning disabled, then download the port.  After that, then you can enable IO polling and download the individual device. 

  Hopefully this helps, but if not, feel free to reply back and I'll see if I can provide some more information.

  Thanks,

  Matt

  • Cancel
• Craig Waldschmitt

  

  • 9 Oct 2017 3:20 PM

  In reply to Matt Forbis:

  Wow Matt thanks for the great reply! This will definitely get me started. Thanks for your help!

  • Cancel
• Tinh Phan

  

  • 9 Oct 2017 6:37 PM

  In reply to Matt Forbis:

  Hi Craig,
  Just a note to self. As Matt indicated, his solution does not work 100% of the time. I believe this is due to the physical layer of DeviceNet where these devices needing power to power up and the response request from master slave communication. When the device gets it's address and actually communicate to the master, there an inrush current from the devicenet device which will cause your segment to go down. This inrush current causes hugh amount of noise to the communication which causes an overload. Most of the time, this is cause by devices that don't meet ODVA physical layer requirement.
  Some suggestions to limit this issue:
  1) Something to think about is when you look at putting on a devicenet device to the segment, Make sure that device has pass the ODVA certification.
  All the devices I run into this problem, are mostly the one that have not been approved.
  2) Segment architecture, Correct cabling used, grounding and terminators properly placed. This will induce noise into your segment and a download will cuase it to go down since the devices can't get it's package through.
  3) The DeviceNet card are to the latest fw. There was a fw update that reduces this issue.
  4) Use a "devicenet detective 2" diagnostic tool. It will gives you a good indication of which device causing this issue and how your segment is opperating. Definitely recommend this tool.
  
  Sometime we think the cause is the download, it is actually is due to one of the devices or segment design issue.
  
  All the Best
  Tinh

  • Cancel
• TreyB

  

  • 9 Oct 2017 6:37 PM

  In reply to Matt Forbis:

  Matt,
  My question is in regards to the actual network. It is fine to use logic to make the module basically not "see" the disruption of the network.. However, do the actual devices in the field that are part of the physical network have any disruption? This would relate to the way the controller downloads the configuration. Rather, how the configuration is downloaded to the controller. Is the device net card able to maintain the network. When downloading ASI networks for instance.. you will have a loss of communications to the physical network and the devices will go to their electrical fail safe position.
  
  Thanks

  • Cancel
• Matt Forbis

  

  • 10 Oct 2017 1:44 PM

  In reply to TreyB:

  I do not believe there is a way to control how the devicenet download behaves on the network. You are correct that it will usually cause a disruption on the network when downloading the whole port to add or remove a device. Usually there are options in the devices that can be set up to control what this behavior is.

  • Cancel
• Rachelle McWright

  

  • 11 Oct 2017 3:21 PM

  
  
  
  
  
  
  
  Awesome example of problem-solving here and proof that the expertise from the Emerson Global Users Exchange is available 365 days-a-year in the  #EE365 community!

  Best Regards,

  Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

  • Cancel