Process Events in Freelance 2016 SP1
Dear Sir,
I am using FREELANCE 2016 SP1. In Operation stations, when I am recently went to PROCESS Events screen, I found that Events are logging without any order(Time stampings). Attached image of my process events screen for your reference. At the bottom of the image you can see that Events logged are in disorder(Time Stampings). I am unable to find the root cause for this problem. Please help me in sort out this issue. Thanks in Advance.

I am using FREELANCE 2016 SP1. In Operation stations, when I am recently went to PROCESS Events screen, I found that Events are logging without any order(Time stampings). Attached image of my process events screen for your reference. At the bottom of the image you can see that Events logged are in disorder(Time Stampings). I am unable to find the root cause for this problem. Please help me in sort out this issue. Thanks in Advance.

Voted best answer
You are talking about Event logs, not the Alarm Page, right? In your picture I see one alarm (the third from the bottom), that does not fit to the time order. That can happen, if a process station disconnects and later reconnects with an operator station.
This has to do with how new events are sorted into the log file. Due to bus arbitration the events coming from different controllers might not be received in the correct time sequence. Therefore every second (if new events have been received), the last 200 entries in the log file are sorted. That takes care of the arbitration delays and normally you would not see an older alarm among newer alarms.
In the special case of process station disconnecting and later reconnecting the process station will -on reconnecting- send all current events again. That feature makes sure, that even if you bring a new Operator console into the plant (or replace a broken Operator station PC with a new one) it will get all current alarms even those that where created before it was connected.
So through this reconnection process of a controller, the Operator Station can get alarms that are older than the last alarms in its event log file. Within one second it will sort the last 200 alarms in the log file. So the oldest alarm from the reconnected controller gets shifted to the correct place within those 200 entries. But it could be, that the alarm just outside those 200 is still newer than the oldest alarm in those sorted 200 entries and then we have a situation like in your picture.
This has to do with how new events are sorted into the log file. Due to bus arbitration the events coming from different controllers might not be received in the correct time sequence. Therefore every second (if new events have been received), the last 200 entries in the log file are sorted. That takes care of the arbitration delays and normally you would not see an older alarm among newer alarms.
In the special case of process station disconnecting and later reconnecting the process station will -on reconnecting- send all current events again. That feature makes sure, that even if you bring a new Operator console into the plant (or replace a broken Operator station PC with a new one) it will get all current alarms even those that where created before it was connected.
So through this reconnection process of a controller, the Operator Station can get alarms that are older than the last alarms in its event log file. Within one second it will sort the last 200 alarms in the log file. So the oldest alarm from the reconnected controller gets shifted to the correct place within those 200 entries. But it could be, that the alarm just outside those 200 is still newer than the oldest alarm in those sorted 200 entries and then we have a situation like in your picture.
Add new comment