We keep on getting an LCN suspect alarm when ever we connect the APP-NOde (tpn server ) to the LCN. We first thought it could be due to alot of requests being made by the TPN via the OPC Optimizer. After reducing the requests and extreme optimization, we still got the suspect alarm.

The app-node is the last node before there is a conversion from coaxial to optic fibre and the following node is around 2 km away. We keep getting the alarm on LCNA .A further analysis revealed that LCNA (optic fibre part) is 1 km longer than LCNB.

Any ideas why we keep getting this suspect alarm. Could it be from the optimizer or app-node

Any suggestions would be appreciated.

 

Both cables must have the same length.

 

Since the App-node is the last node before the long journey, could it be that the terminal's resistors need to be changed?

Also the errors we get are on the nodes after the long distance.

When you say the length should be the same, i understand that. But why wasn't there any errors and LCN suspect alarm when the app-node was offline--(not on the LCN)?

 

Run lcn diag - and see "net media" -reset time- try to connect LCN A and look on "media net" - you will see which node isn't on net.

Probably APP LCN card is not ok.

Arie

 

Having LCNA and LANB with different lengths might cause a problem. We have not been receiving an LCN alarm even with this difference.

As you suggested to check the LCN card. When i did, a small test a few days ago here is the sequence i did.

I connected the app-node (tpn server) to the LCn with no Clients connected to it and there was no error.

I started the OPC optimizer that is on TPN and there was no LCN suspect alarm.

The diagnosis to this point showed that the cable was ok

When i turned on ODH (client) an LCN suspect alarm showed after around 12 minutes. Just to get a better understanding, why didn't an alarm come up when we connected the TPN server (with no client). The alarm started coming when the client connected to the TPN server.

The reason i mentioned the location of the TPN server (the last node before it is connected via optic fiber to the neighbor node 2 km away) is because we had deltav connect (had a lot of request and data through it) in the same location and we got LCN alarms (but for LCNB not LCNA). Could there be a framing issue due to the difference in cable length.

Any suggestions are welcome.

 

There are many rules that need to be followed to have good communication. The resistors should be at the end of the LCN cables so on the last T.

The f.o. senders and receivers on both ends should be of the same version (they actually come in pairs).

Check clock source and clock source repeaters. If you only have K4 processors (like LCN/P boards), then clock source repeaters and not needed.

Grounding of the nodes should be OK.

 

green n yellow cable segments between nodes should have same length. Moreover, in LCN suspect troubleshooting, if LCNE is involved, my experience suggests to attack LCNE first.

If you have only one node i.e. the APP on the other side of the LCNE, and when you turn off the APP, then noise vanishes, I think your problem is solved. Replace LCNE with a fresh one and see. How often does LCN announce suspect? If possible, try isolating the LCNE and APP node and observe. LCNE is an old criminal in LCN performance.

This is because the LCNE introduces its own noise and further amplifies the noise on the LCN. Even the TPS readme has notes on LCN troubleshooting and best practices for LCN. Do read it. It will help a lot.

 

In the architecture the tps app-node is before LCNE. So basically the app-node is connected to LCNE then after around 2km of fiber optics another three nodes are connected via the other end LCNE. When the App-node(tps) is turned on the three nodes on the other side (after passing through two LCNE), start getting errors.

How is it when the app-node is turned on, the three nodes on the other side start getting errors.

Thanks

 

Dig in a little deep. Check system maintenance and system errors from Even history menu in system menu.

A. note, when did the cable go suspect and then look for the LCN errors exactly before/after the LCN suspect. Check which node is it which announces LCN error at this time. That node is initiating the noise on LCN. Further errors from different nodes may be reflections.

B. Check parsec value of APP, because as u say APP node causes cable suspect only when the client services are started (i.e. huge amount of data is pulled from LCN).

NEXT.... when cable goes to suspect, do not isolate APP. If your process allows, try to isolate the node on the other side of LCNE which reports MAX noise count.

Basically, try isolating the node which introduces noise.
VERY IMPORTANT: keep a track of all the trials and observations of your troubleshooting or else you will end up getting confused.

 

men change the lcnpm, is the problem