DeviceNet DTAMs to 1756-DNB disappearing in RSLinx

[BW2218]

I am running into some trouble trying to get some old Allen Bradley DTAMs to communicate with a ControlLogix 1756-DNB module. I am hoping someone more experienced with this equipment can point me in the right direction.

Background:
Original system consisted of two SLC500 chassis each with its own SLC 5/05 processor (1747-L553) and 1747-SDN scanner module. Each of the original scanner modules were connected to separate networks but the number of nodes and their address assignments were such that they could have been connected together into one network. It is assumed that they split the line into two due to memory limitations of the processor and the desire to use I:x.xx and O:x.xx vs M file addressing for the discrete I/O. However, the DTAMs did use M file addressing for the DNet mapping.

Current System:
The SLC500 systems were replaced with a ControlLogix 1756-L55 (FW 16.23) / 1756-DNB (Series B FW 7.1) system. The two networks were combined into a single network. The two extra terminating resistors were removed and the network cabling was rerouted to balance the power and number of nodes on each side of the network trunk line. The system consists of 11 1794-ADN Flex I/O adapters, 13 SMC EX240-SDN2 adapters, and 12 2707-M232P3D DTAM Micro units (FRN 1.00 Aug 29 1996) in addition to the scanner module. All of the Flex I/O and SMC nodes communicate properly. The network has been fully checked and tested for media problems and none have been found.

Current Problem:
I am trying to get the DTAMs to communicate with the ControlLogix processor via the DNet bridge. The problem that I am seeing is that the DTAMs will appear in RSLinx for a brief amount of time and then drop communication such that they show the infamous red X. Whether or not a particular DTAM shows up at all is dependent upon whether or not RSLinx catches it up and running while browsing during that brief period when it is communicating. The DTAM messages indicate that it is doing a duplicate node address check which it seemingly passes (no error displayed), then it waits for a master connection, then waits for an I/O connection, then displays the main startup screen for maybe 1-3 sec before dropping communication on the network and displaying the "Waiting for Master Connection" message until powered off or reset again.

The DTAMs are configured for 10 words IN and 10 words OUT so I mapped each one to 5 DINTs IN and 5 DINTs OUT. In run mode, the scanner reports an error code of 78 for each DTAM node indicating that the node doesn't exist even though it is physically connected and powered up. All of them show up in RSLinx briefly and the network media has been gone over multiple times, so I am inclined to believe that the problem is software / configuration related. Since the nodes are not "staying put" on the network, I can't upload their parameter configuration in RSNetworx in order to download the information to the scanner. They all show up in RSNetworx if I set it for continuous browse and cycle power to the network, causing them all to reboot at once. This indicates to me that they are being seen on the network. If I then try to open the properties dialog, I get an "... identity communications error (8000000A)" message since they are no longer on the network by the time I try to open the dialog. The manuals I have are geared more towards the DTAMs which use a serial interface direct to the processor rather than DNet. I have a document update for the DNet version but it hasn't been much help and doesn't seem to give a clearly defined path for configuring these in RSNetworx. I have downloaded and installed what claims to be the latest EDS file for these from the Rockwell website but that hasn't resolved the issue.

Anyone with experience in this area have any ideas of other things to try?

 

[Ken Roach]

Do you have access to a protocol analyzer ?

What I'm curious about is whether the I/O connections are being established and then dropped, or if they are never being established in the first place.

Do you ever see an Error 72 for the DTAMs ? The 1756-DNB's status tables should let you trap the actual status codes for each node. Error 72 would indicate that the connections are being established and then being broken, rather than never being established at all.

Do you have an idea of how many packets per second are on the network ? Do you have the ability to increase the inter-scan delay ?

My guess is that the DTAMs, which run a very early DeviceNet chipset and firmware stack (remember that DeviceNet was introduced at Automation Fair 1995 !), are essentially having trouble dealing with a very busy network.

 

[BW2218]

Do you have access to a protocol analyzer ?

Short answer: No and I probably wouldn't know what to do with one.

What I'm curious about is whether the I/O connections are being established and then dropped, or if they are never being established in the first place.

Based on observing the DTAM messages during powerup, it would appear that it establishes some type of connection with the scanner but then drops the connection. I say this because if I don't have the node in the scan list, it hangs at the "Waiting for Master Connection" message. If I configure it in the scan list, it will go past this message to the "Waiting for I/O Connection" message and then displays the first screen. After a couple of seconds, it then goes back to the "Waiting for Master Connection" message and stays there.

Do you ever see an Error 72 for the DTAMs ? The 1756-DNB's status tables should let you trap the actual status codes for each node. Error 72 would indicate that the connections are being established and then being broken, rather than never being established at all.

I took your suggestion and added a simple rung that would trap an error 72. I have an EQU instruction looking to see if Local:3:S.DeviceStatus[13] equals 16#48 (decimal 72) and if so, it moves Local:3:S.DeviceStatus[13] into a DINT tag called Node13_Status. It is initialized at 0 so it will stay there unless at some point the error code equals 72. I then reset the module a couple of times and even cycled power and never saw a value of 72 in Node13_Status. It remains at 0.

Do you have an idea of how many packets per second are on the network ? Do you have the ability to increase the inter-scan delay ?

My guess is that the DTAMs, which run a very early DeviceNet chipset and firmware stack (remember that DeviceNet was introduced at Automation Fair 1995 !), are essentially having trouble dealing with a very busy network.

No, I haven't found anyway to see how busy the network is with traffic. I tried reducing down to just the one DTAM in the main console with the scanner but that didn't work either. I have increased the interscan delay to 100ms and cycled power but that didn't help either. I'm leaning towards trying a firmware upgrade for the DTAM if I can locate some newer firmware.

 

[Ken Roach]

It's been a while since I was hands-on with a 1756-DNB, but check carefully to see how it displays status bytes. I have a faded recollection that the code might be "0x72" hex, rather than "72" decimal.

There might be something subtle in how the 1756-DNB creates Polled connections versus how the first-generation 1771-SDN and 1747-SDN modules did. You would really need to get a protocol analyzer onto the network to capture what's going on at a low level to find out.

 

[BW2218]

It's been a while since I was hands-on with a 1756-DNB, but check carefully to see how it displays status bytes. I have a faded recollection that the code might be "0x72" hex, rather than "72" decimal.

There might be something subtle in how the 1756-DNB creates Polled connections versus how the first-generation 1771-SDN and 1747-SDN modules did. You would really need to get a protocol analyzer onto the network to capture what's going on at a low level to find out.

I appreciate the help. We may be able to find someone who can help us in that area if we continue down that path. My boss just suggested a little while ago that we consider getting rid of the individual DTAMs and just doing all of the operator interface from a PanelView at the main console. The only possible disadvantage there is operator convenience but that may be the quickest way for us to make progress. If we weren't overbudget, we'd probably replace them all with some PanelView Components but that cost money we don't have at the moment.

 

[OkiePC]

I 2nd the boss suggestion. And, you could replace the DTAMs with a cheap HMI on a different type of network and avoid having them on the same busy DeviceNET network. Does your Logix5000 platform have an ethernet module in it already?

Paul

 

[BW2218]

I 2nd the boss suggestion. And, you could replace the DTAMs with a cheap HMI on a different type of network and avoid having them on the same busy DeviceNET network. Does your Logix5000 platform have an ethernet module in it already?

We are getting pushback from the engineer that is responsible for this line. This line is the part testing portion of a larger line. It basically consists of 12 identical test chambers that have to undergo a periodic calibration procedure. This is typically done locally using a handful of function key based controls on the DTAM. The single PanelView option would probably work ok during normal operation but it would be a pain for him to do his calibration procedure alone. We would also lose the alarm / fault reporting at the local per chamber level.

Yes, the Logix chassis has a 1756-ENBT. As mentioned previously, I suggested replacing the DTAMs with EtherNet PanelView Components as an option but we just don't have the budget to do that at this point. It is being considered as a "down the road" project we could do on a chamber by chamber basis. We would probably swap out the Flex I/O DNet adapaters for EtherNet I/P at the same time.

It's been a while since I was hands-on with a 1756-DNB, but check carefully to see how it displays status bytes. I have a faded recollection that the code might be "0x72" hex, rather than "72" decimal.

There might be something subtle in how the 1756-DNB creates Polled connections versus how the first-generation 1771-SDN and 1747-SDN modules did. You would really need to get a protocol analyzer onto the network to capture what's going on at a low level to find out.

I doublechecked and error code 72 / 78 are the decimal equivalents. They are 48 and 4E respectively in hex.

Update:
We are now trying to do a partial revert to the old system. Basically, we are trying to leave the discrete I/O communicating with the Logix processor via the DNB module since that is working and the Logix has already been programmed with the new logic. To get the DTAMs working, we put one of the SLC 5/05 processors and one SDN module in a 4 slot chassis. We then hooked it into the ENet / DNet and powered it up temporarily. Since the SDN was already configured for the second half of the network nodes, those DTAMs appeared to be working when we cycled power and let them all reset. However, I had to reconfigure the SDN's scanlist since it was conflicting with the DNB with respect to the Flex I/O and SMC nodes. After doing that, we are now seeing the DTAMs toggle between "Waiting for I/O Connection" and the main screen. I'm also unable to send a screen number to the DTAM via the M0 file and get it to change screens. Yes, I turned on the enable bit after I realized I didn't have the SDN running but that didn't seem to change anything.

I also have an EDS issue now with one of the DTAMs. The firmware was upgraded to version 2 using the upgrade operating system function in DPS. However, that DTAM now shows up as an unrecognized device in RSLinx and RSNetworx. I haven't been able to find an EDS for a DTAM that is newer than 1.00. Anybody know where I could find one or how I might be able to create one?

If we can figure out how to get this working, we may solve our DNB problem along the way and not have to resort back to the SDN for the DTAMs. Even if we do have to use the SDN, we are hoping to make it a slave to the DNB and have it just be a go between. Since the DTAMs don't have anything that is time critical, we think this will work okay, even if it is a little hokey.

 

[BW2218]

Finally, the sweet taste of success. As I expected, we would eventually resolve the DNB issue once we figured out the new problem we were having with the SDN. As it turns out, I didn't consider that I needed to adjust the expected byte size in the I/O parameters dialog for the DTAMs when adding them to the scan list. I'm used to most devices being added with the defaults from the EDS file. In the case of the DTAMs, I needed to adjust them to 20 bytes in and out to reflect the fact that they were configured in software for 10 words in and out. This solved the problem with the SDN which we then translated to the DNB. We are now running everything from ControlLogix through the DNB module and removed the temporary SLC 5/05 and SDN chassis. Thanks for the help.

 

[JeffKiper]

Where are you located at in INDIANA? I have a DeviceNet detective, & a netmeter.

 

[Ken Roach]

Thank you for the update !

I'm very surprised that you never saw a status code 77 (I/O Size Mismatch) at the 1756-DNB for the DTAM nodes.

This is where the old firmware for the DTAMs might have been contributing to the problem if it doesn't correctly refuse a connection request of the incorrect size.

To paraphrase, the connection establishment process goes like this:

Scanner: "Hey, DTAM, how about a Polled I/O connection ?"
DTAM: "Sure, scanner, what sizes did you have in mind"

Scanner: "Ten bytes Produced and ten bytes Consumed would be great."
DTAM: "Okay ! Is a timeout multiplier of four good for you ?" (secretly: "I really wanted twenty bytes. He never asks about my needs.")

Scanner: "That's great. Are you an Allen-Bradley device ?"
DTAM: "Vendor Code #1, all the way !"

Scanner: "And you're an HMI device, right ?"
DTAM: "Yes, I am."

Scanner: "Here's some output data"
DTAM: "And here's some input data"

Scanner: "Here's some output data"
DTAM: "And here's some input data"

Scanner: "By the way, what size is your input and output connection ?"
DTAM: "Twenty bytes Produced and twenty bytes Consumed" (secretly: "See ! I knew he cared.")

Scanner: "Hey, I gotta get up early for work tomorrow. Here, call yourself a cab."

DTAM: "Hello ? Hey ! Where did you go ? Helloooo ?"

DTAM: "Why can't I meet a nice Ethernet scanner? Mom always told me that DNBs won't stick around."

 

[JeffKiper]

Ken you have way to much time on your hands.

 

[Ken Roach]

You should hear my Object State Conflict, sung to the tune of "Confrontation" from Les Miz.