Hi Guys,
I'm new here, I got myself sign-up last 2nd Jan. 2013.
I just want to get an expert opinion on one of the problem I encountered just recently.
We have a DeviceNet segment with 20 devices in it. 3 are spare (connected in the segment but not configured in DeltaV - i.e. DEV10, DEV14, DEV24). We were working on one device address 26. In diagnostics it shows “Bad Not Communicating” although the device is up and healthy. The first thing we did was change the device address to 30 (unused) in DeltaV without changing the address on the field device. After doing that we rescan the DeviceNet port in diagnostics and we were able to see an active device DEV26, which tells us that DeltaV is actually able to see the device. We were thinking that probably there is a configuration mismatch between the device and DeltaV so went ahead and changed the address in DeltaV back to 26. When we downloaded the device we lost the communication. Sadly, some part of the process got shutdown because of that.
I would really appreciate if anybody would spare a minute of their time to look at this.
Thanks a bunch,
mcprayer
What type of device is hooked up to the DeviceNet segment? We have used several AB stuff using there MCC's. I know with them you need the exact EDS file for it and make sure that on device is not setup for Autobaud that creates all kinds of trouble I spent 3 days trying to figure that one out had 25 devices on the segment and one of them was set to Autobaud. Are you sure there is no other device setup with that address? Just asking!
In reply to Bill Sayers:
Thanks for the time Bro. I appreciate it.
The devices we have on the network are all GE (i.e., MM200, AF-650 and Multilin 369). Out of the 20 devices (excluding spare), only two are not working. We got 3 spare devices connected to the network, all are detected properly by DeltaV (address 10, 14 and 24). The devices that are not working are address 26 and 25. I believe we have no problem with the addresses. We also checked the field device baud rate setting and it is manually set to 500Kbps (not Autobaud) which is the same setting in the DeltaV devicenet port. I'm still puzzled why the segment failed when we downloaded the device with address 26. We'll just wait until next plant maintenance and continue the troubleshooting. Thanks again.
In reply to mc_prayer:
With the device set to an address unused by DeltaV, it shows good status. Hence the byte count in and out may be wrong in DeltaV OR the EDS file may not match, but as I recall it, diagnostics shows bad only if byte count mismatches. That is, DeltaV is set up, say, for 4 bytes input, but device for 6. Press Alt+Prtscreen to record this status screen in diagnostics; paste into wordpad and print, or just write it ALL down. This screen will also give the device version, so that you can confirm the EDS file is a match. Only after this information has been collected, try to give the device an address in DeltaV and enable it, and re-download the EDS just to be certain you have one that matches what diagnostics reported. Be absolutely certain the configured byte count and actual bytes in/out match. Bear in mind, as I recall it, you can still communicate fine with the wrong EDS; you just can't view/configure the device's live parameters from DV. I would recommend always running with the correct EDS.
We got the device working.
We have this type of device all over the plant so we know we got the correct EDS file in DeltaV.
As we originally thought, and you are correct Frank, there was a configuration mismatch between the field device and DeltaV. DeltaV is configured for 11 input all 16 unsigned integer while the field device is set to user define config of 13 output unsigned integer. We took the 2 extra register out then reset the power of the comm module of the field device. DeltaV started reading data after that.
This doesn’t explain though why the DeviceNet Network fails when we downloaded that device when it still has the extra words configured. I understand that it will not communicate with DeltaV unless the configuration match but it should not cause a failure in the whole Network.