RSLINX Dropping Tags Until Restart

Once a plc is taken off the network and then put back on usually after a day or so we see some tags in that plc come and go within the studio se display. We get the warning "communication error has been detected for 'topic\tag' and perhaps others. We are certain this is not a studio se issue because we had the same thing occuring when we were using intellution. Rockwell support suggested updating linx from 2.50 to 2.53 and installing a patch that was suppose to avoid hang ups and crashing of linx. I did this last Saturday and the problem still exists.

The exact steps during this issue are as follows:
1. L32e compactlogix controller running for days on end on the ethernet network.
2. Either the l32e gets disconnected from the network due to the coal mining unit advancing or when the unit moves off a conveyor belt.
3. L32e gets reconnected to the network either after the unit moves up or when the unit goes on a new conveyor belt. Normally the unit's plc is only disconnected for a couple of hours. This issue doesn't occur under that short of time. If for some reason it is off the network longer, say that the move on a Saturday night and we don't get the fiber hook up till Monday, then this is when we see the issue on the unit's plc. More often then not we tend to see this issue more with moving plc from old belts to new belts since there might be days to weeks between times it is taken off and put back on the network.
4. Once on the network, rslinx shows the l32e in the unkeyed state and this is when we start losing some but not all the tags we have setup in studio/intellution. I can go online with the processor using logix5000 just fine and seems like all is ok there. Like i said this is always with a l32e and is not always the same plc. We have 7 units and 25 of the plc cabinets we place at the belts.
5. To fix the issue until the next time it occurs, we shutdown and restart linx. The l32e then shows active instead of unkeyed and the tags stop coming and going.

Hopefully someone has seen this before and can tell me how to handle putting these back on the network without running into this issue or knowing a fix for linx. Because another issue arises once we shut linx down and restart. We have a 6 minute delay from the time it is shutdown to the time we start displaying tag values on studio displays. This use to not be that long. I say 6 minutes but I think it may be down to 4 the last time we restarted. This might have been helped out by me bumping up the overhead time slice to 50% in all the l32e at the belts since they are not controlling anything and are mainly used to get data from underground to the studio project outside.

Thanks for you help and sorry this was so long I just wanted to state everything i see that might be of help to you guys.

Just wanted to say I know exactly what you are talking about, and the only ROCKWELL solution I've found works, but is expensive.

Have a separate PC, running a separate licensed copy of RSLinx, for each PLC. That way, if the PLC goes loses power, so will the RSLinx box, and both will then restart when power is applied.

RSLinx has always dealt poorly with losing active connections, and it's getting worse with each new revision.

If you don't require a Rockwell product, just plain dump RSLinx for your communications driver, and use TopServer. It is about 10 times more stable, and has much more diagnostic ability built in. (also less expensive then Rockwell's offerring)

http://www.softwaretoolbox.com/store/item_pages/itempage_887.asp

Having a seperate pc for each plc is not an option since it would be extremely expensive and the fact that these are underground would not make it reasonable to even consider this option. There has to be some way to handle taking a plc off the network and putting it back on without this happening. Tech support has also suggested that it was a linx classic issue and that I should try to move everything over to enterprise. Is there anyone out there using enterprise with rsview studio se that has experienced the same thing with tags going into comm error once a plc is put back on the network?

I may have found the answer to why I get the delay when we restart linx. Rockwell tech note 23879 explains how microsoft's DCOM works. The way I read it is that once a remote client, which I am assuming means a plc, is disconnected or shut down DCOM goes into a ping state and tries to regain comms 3 times. Each of the retries may take 2-4 minutes to timeout. After the third try DCOM considers the connection dead and tells linx to release all of its objects. After this linx will clean up the groups and item after about 10 minutes. Please let me know if I am reading this correctly. I still haven't found a fix for linx losing some but not all tags once a plc is reconnected. As a side note the tech note above mentions disconnecting the client without taking its tags off scan. Where are they talking about taking the tags off scan? Is it in linx or are they talking about the direct references in the studio application?

This is the exact reason why no one should use RSlinx. and the factg that the performance just isnt there. I also know exactly what you are referring to. Try save yourself a headache and switch to a matrikon or kepware server

MAY Have found the solution

Due to other network issues we encountered last week, we have possible stumbled upon the reason why this odd occurence was happening. It ends up not being an issue with any rockwell software, instead it was a simple mistake made by our IT department. We have three routers to pass data from our underground network to the corporate network. 2 of the 3 routers' subnet mask were set at .252 and the other was set at .255 as well as all plcs, panelviews and managed switches on the underground network. Once the IT department changed the mask in the other 2 routers it not only fixed the issues we were having at that time but it seems to have took care of the issue that this post explains. We haven't had to restart linx one time since these changes were made and there have been plenty of times when a plc was taken off and put back on the network like before which previously caused some tags on these plcs to come and go in studio se. Hopefully this is the permanent fix.