Data Highway Fault when assemble edits

brucechase

Member
Join Date
Sep 2004
Location
Augusta GA
Posts
721
I posted this question on another PLC site and no one could help me out. I am hoping someone here can give me some insight. This problem has been going on for 5 years and I'm getting a little frustrated.

I currently have most of my AB SLC 5/04 going to a contrologix gateway on different DH+ channels. I don't pass much data through (several strings for barcodes and a couple of words for status bits). My DH+ is running at 57.6K and there are only 2 nodes (SLC 5/04) on each highway with a total of 7 different highways. The plc at node 1 never has any problems but on the one on node 2, whenever I do an online edit and assemble them, the communication faults and the processor drops offline. There is no fault on the processor, just the comm light turns red and I am no longer on line. I have changed the DH card in the gateway and put in a total of 4 different processor, with the latest being a few months ago (this was the latest firmware available). My RSlogix 500 is currently 5.50 but it has happened even when I was on 3.2. I tried different node number and reran the blue hose actually changing which processor the was first in the network. This happens whenever I connect directly to the front programming port of the processor or if I connect over my network (both wirelessly and hardwired) through the gateway. I will NOT happen if I connect serially though. As another note, I have a total of 7 channels on the DH+ and only 2 of the channels (on different cards) exhibit the problem. These are different machines and don't communicate to each other at all.

The latest AB GTS tech (I know they aren't called that anymore) had version 6.2 and he had the same problem. We actually put a sniffer on the DH+ network and whenever we did the edit, we saw the data turn to garbage, but we could not determine where it was being initiated from. He said that the PC on the other end of the gateway which collects the data was causing the problem by polling the network too fast, but the other processor on the highway is being polled at the same rate and has NEVER exhibited this problem.

Does anyone have any ideas? Thanks for at least "listening" to my problem.

BGC
 
Thanks, I've seen that and tried the SVC (service communication) command in several different locations since it needed to be in the "middle" of the entire logic (according to AB). That did not help at all. Also tried the latest versions of firmware in the processor to no avail. I also set bit S:2/15 to 0 during initialization but that did not help. I'm still not sure where to go from here.

I am impressed that you got back to me so fast though and that you found that so fast. Several years ago when I called AB, it took the tech 2 days to send that document to me.

BGC
 
SSSSSSHHHH!!!! I ran into a similar problem a year back and remembered where I had found the document. Thankfully it had solved my problem. there was another document referring to a maximum rate of communications. However I am not sure if it will apply in your case. Still looking into it.
 
Have you tried to isolate the problem, something like this:?

1) Disconnect the fault prone machine from the network and try to reproduce fault by editing through the programming port. If it faults, the problem is local to the machine/program. Basically, try the machine/program with the simplest communication architecture. (Make up a simple two-node cable if you need to). If it won't fault,

2) Disconnect from controlLogix and try again. If not

3) Starting with the fully intact network, partially isolate the fault-prone machine by disconnecting other nodes one at-a-time, and then try to induce the fault. You might try disconnecting the PCs first.

Hopefully, this will allow you to narrow your focus.

Good luck.
 
I had a similar problem with online editing 5/04 s through a contrologix gatway to 3 dh+ networks where most of the the time everything was ok but on one of the dh+ networks occasionally when I tried to online edit the edit failed and the processor dropped off the network.The only way to reset this was to cycle power on the proccesor.I though it was a problem with too much traffic on the dh+ and tried to get round it by rationalising the messaging.But still the problem occasionally popped up.I ended up doing all my editing through port 0.
 
Is the common factor here is that you are doing the online edits via a 1756-DHRIO module?

Certainly something odd is happening because there are 1,000's of 5/04's out there that do not exhibit this behaviour. So I guess my question at this stage is: "What am I doing that is different?"

I do know that earlier versions of the DHRIO module had some issues with heavily loaded networks and lots of traffic, but I was never directly involved with one of these and I cannot recollect any details.
 
PhilipW - No, I don't believe the common factor is the DHRIO module since it happens when I'm plugged into the front programming port. I wish I knew what was different since I have many other networks that don't exhibit this problem. I really don't have a lot of traffic and only 2 nodes.

Rob allan - I'm glad there is another person in this world who has seen this problem. Sometimes I feel like I'm dreaming this stuff up. I still only edit through port 0, but since I have the gateway and now a wireless network, I can do all my edits wirelessly. Since this one processor controls 1000's of feet of conveyor, that capability is awesome when doing changes. If I have to stay on channel 0, it is a big hinderance.

Jamesau - I like the way you think. Since I can only perform this at certain times (I can't be off network without causing major problems to part tracking), I have tried this during our Christmas and July shutdowns. Unfortunately, that is the busiest time for me (16-20 hrs/day) as it is the only time to do major modifications. When disconnected at the processor, edits are no problem. When disconnected from the CLX, edits are no problem. The other end on the gateway is the ethernet network. I have not (can not?) disconnect the PC from the ethernet and try it. I will look into it though.

My big question is why does the network traffic turn to garbage when I do the assembling of edits. What in the system tells the PC that there is an edit going on (I know the answer to this is NOTHING as there is no broadcast information about editing from the SLC). And since the polling rate is the same as other processors on this node and other nodes, why is it just this one? I will have to find someone here who knows how to change the polling rate on this system and try it. I'm not that familiar with it right now (Another thing on my "man I really want to learn how to do that" list). I don't know if it can be changed while we are online, but if not, I guess it is something to add to my Christmas work list.

Thanks to everyone for all the help. If anyone else has any ideas, I would love to hear them.

BGC
 
I have a similar problem here at my plant....
I have to go plug straight into the processor for edits(although everything stays running here). It seems that only the processors that have rsview talking to them are affected. I've even had to go offline from the office when I was monitoring some data, because the rsview application buttons wouldn't respond to the operator control until I stopped communicating with the processor.
I've never been motivated enough to figure our why.... I just accepted it as a limitation and moved on.
 
I have this same problem. I’m trying to find a solution.

I’ve just installed a ControLogix processor with a DHRIO/D on the rack. There is a SLC 504 that is using the MSG instruction to the ControLogix processor. The MSG instruction rung is enabled at all times. The following rung is the standard DN or ER bit unlatching the EN bit. DH+ is 57.6k.


If I try to do an online edit with the 504 over the DH+ network on channel 1, I get the same communication fault (red led on DH+ on front of 504). The only way to reset is to cycle the power on the 504. I can do online edits from channel 0 (RS-232) via a laptop with no problem.

I’ve had no problems doing online edits BEFORE the Contrologix - DHRIO/D stuff was on the network.


I will try the SVC instruction, but I will have to wait until there is no production to test this solution to see if it actually works.

Also, I occasionally get an error with the MSG instruction that doesn’t reset it self. It is 37H (Message timed out in local processor). The only way to reset is to cycle power on the 504. This is very annoying and disrupts production.
 
brucechase said
PhilipW - No, I don't believe the common factor is the DHRIO module since it happens when I'm plugged into the front programming port. I wish I knew what was different since I have many other networks that don't exhibit this problem. I really don't have a lot of traffic and only 2 nodes.

Just because your PC is plugged into the mini-din port on the 5/04, doesn't change the fact that there is still a 1756-DHRIO module on the same network, unless it is shut down or unplugged. I work with DH+, PLC5s and SLC5/04s all the time and have never had any problems like this that caused a processor fault. (I have been kicked offline and had RSLogix faults plenty of times). I don't have any 1756-DHRIO modules. The DHRIO thing looks like a suspect to me too... Remember all the firmware problems AB had with the 1756-ENET? JMHO Paul C.
 
Message number?

How many message instructions do you have going through the DHRIO card? I ran into a problem of trying to send too many BTR,BTW and MSG on one channel. I believe that the limit is 32 per channel or card. I had to split the network and add another DHRIO card. Problem solved. This might not have anything to do with your problem, just FYI. My tech support didn't have any idea that could happen. It wouldn't take down the network, only make it seem as though a PLC was having strange problems.
 
Thanks for the replies.

There are two MSG instructions, each with 2 16 bit words. The 504 has 32K memory, using 7k with 25k left.

I asked a coworker to try the SVC instruction somewhere in the middle of the program. It didnt work, Trying an online edit causes a comm failure and the DH+ LED goes red.

I then asked him to disconnect the DH+ plug from the DHRIO/D and try an online edit. And then what a surprise, he was able to do an online edit with the 504.

It appears there is a problem with the DHRIO/D. I guess it is time to return the DHRIO/D to AB and go with Ethernet for the MSG between the two processors (1756-ENBT in the Contrologix and a 1761-Net-ENI on the 504). I know there is a bottle neck with the 1761-Net-ENI, but I think I can live with it.

Thanks for the replies.
Darrell
 
Before you go too far, my AB rep. (on Friday afternoon) said there was an undocumented feature with the contrologix DHRIO cards that require a firmware upgrade. Even though he said that it didn't specifically address this issue, he felt it had something to do with the communications. The upgrade has only been out a couple of months he said. I will contact him to try it later.

By the way Darrell, is the only thing you are doing is messaging between the 2 processors or do you have a computer doing data collection from the contrologix? I only have a contrologix gateway - no processor and still exhibit the same problem. I have since found it on multilple cards and multiple processors, but not every one.
 

Similar Topics

I have ran into something this morning I have never seen before. I took over a problem from the 3rd shift guys. We have a line with 9 AB Slick 500...
Replies
5
Views
2,708
Hey everyone! I am trying to set up some messaging between two of our older PLC's, having difficulty getting the configuration nailed. I've made...
Replies
2
Views
1,273
I seek the wisdom of the old men on the mountain. I am working with an old data highway network while upgrading from PLC 5 to 5000. In order...
Replies
9
Views
3,946
Does anyone have the setup disk or drivers for sst 5136 data highway card? if so can you point me in the right direction. Thanks
Replies
1
Views
1,763
We have a customer who has a PLC5/25 controller that uses interfaces to a Fischer-Provox system using a 1785-KA on the PLC5 end and a 1771-KX1 on...
Replies
4
Views
1,639
Back
Top Bottom