I noticed that the start and end time is calculated from the computer running the project. The current time acquired from the gateway isn't synced up and that could explain why the time isn't in the range. I dont see how this could work if the computer running the client isn't exactly synced up with the computer running the gateway. Could I make this a client event and would everything now be derived from the computer running the client so the times would actually sync up automatically?
I dont see any errors. What I do notice is I have the start, end, and current times being sent to the logger to confirm formats, etc. I noticed the current time which uses the same system.date.now function within the gateway script itself is off by minutes from the start time which is derived from the memory tag which resides on the backend gateway.
This system has a frontend backend setup with the frontend housing the visuals and using a remote tag provider to connect to the backend. Would moving this gateway script to the backend gateway sync things up? Would making this a client event script instead sync things up since it would be using the client info instead of the gateway info?
Undoubtedly. Either that you need to have a time master to synchronize the times on the servers. Personally I would recommend doing that as there are other things that are undoubtedly being effected by the time difference and you just haven't noticed it. (e.g. If you have database records being inserted by the different gateways).
1 Like
I put the same gateway timer event script in as a client timer event script and it worked! I did notice that if I press the alarm reset which sets the time and the bit turns on and I close the client the bit does not turn off until I reopen a client again. In this case the reset will only be on/active for 3 to 4 seconds just to get to the plc. Its possible someone could close the client within the time its on but not likely.
So if I did create the same gateway script but on the backend gateway and run a client on the frontend the times would all be coming from the same place and not from two different places. If I understand correctly putting it on the backend would work because the times being populated from the memory tag and from the current time within the gateway script would be synced up?
If the times are ultimately coming from the same source then they would be synced up correctly.
An option to avoid this problem would be to call a gateway message handler to set that timestamp instead of writing the memory tag from the client. The gateway message handler would call system.date.now() itself and write that to the memory tag.
1 Like
So the button press on the frontend gateway running the vision client would send a message to the backend gateway housing the tag providers to the plc?...or do I have that backwards. I would put the gateway timer script on the backend and then upon button press from the frontend gateway it would send a message to the backend gateway to go ahead and access the current time from the backend?
I'll admit I am not very proficient with message handlers so trying to understand. Thanks.
I tried putting the same script on the backend gateway and just changed the tags so instead of accessing the remote tag provider its accessing the actual tag from the original tag provider and for some reason still coming up with timing issue.
I would use the loggers to write to the logs what the values of the times are so you can see what is failing and why.
As far as I can tell the script should work, especially if everything is on the same gateway.
Yes, or just "to the gateway" if you aren't using separate UI and I/O gateways. To avoid clock skews, the gateway that is running the regular timer event to control this boolean should be the one to capture now() to write to the memory tag.
I do have a frontend backend setup. Think I found an easier solution. Keep the gateway event on the frontend and set the memory timestamp based on the system.gateway.currentTimeAndDate instead of using system.date.now(). Will test now.
Those are the same thing under the hood.
Edit: Is there any reason you don't want to add the remoteServers keyword argument to the call to system.util.sendMessage() in the Vision client?
You are correct. Same result. Understand why now.
So high level guidance on where to put things for messagehandler:
I put in a system.util.sendMessage in the script for the button on the frontend vision project. I then create a message on the frontend gateway that will take the message from the frontend system.util.sendMessage to write the timestamp to the tag?
No, make the message handler in the backend gateway. Same place as the timer event that actually controls the bit. So the timestamp placed in the memory tag is coming from the same environment that will be checking the memory tag against its own now().
No message handler in the frontend gateway. The sendMessage() in the button's action performed script specifies the backend project name, backend message handler, and the backend gateway name (in the remoteServers argument).
Ah I see. So the sendMessage on the button press on the frontend gateway client is setting the timestamp to the frontend gateway time when the button is pressed. Then the messagehandler on the backend will simply be taking the timestamp sent over from the frontend and set that time to the memory timestamp on the backend.
No, the sendMessage, is telling the backend gateway that the button has been pressed and to record the start time, then the timer script is looking at the start time that is set from the backend gateway. Not possible then for the times to be "skewed" as they have the same source.
The frontend does nothing but send a message to the backend.
1 Like
The message is handed directly to the backend. So the backend's clock is the time that goes into the memory tag.
Ok....think I have it now...again...haha. So the button press on the frontend is just a call to the backend to set the memory tag timestamp. It won't have any payload associated with it. The backend houses the message which will say to set the memory timestamp to system.date.now() which is the time from the backend gateway.
I guess I still don't understand why the system.date.now() call on the frontend gateway timer script would be getting the time from the backend gateway when the client is residing on the frontend gateway.
@pturmel
Message handler works where I sent message via frontend gateway to write current backend gateway time to backend memory timestamp. I did have to relocate the gateway timer script to the backend otherwise I ran into the gateway time issue. I would have liked to keep things within the frontend gateway project side but I guess I would not be able to do that. Thanks for the help!
There's some major confusion here:
-
You sometimes talk about the "front end" as if it is a gateway, and sometimes as if you mean the Vision client. Where I've used the term, "front end" is a gateway using a remote tag provider to work with a "back end", also a gateway. The Vision client isn't a "front end", it is a Client.
-
system.date.now()gets the current UTC milliseconds from whatever computer is running that code. It needs to be the same computer as the one that runs the fast timer event. If it runs in the Vision client, it gets that computer's time. If it runs in a front end gateway, it gets the front end's time. If it runs in the back end message handler, it gets the backend's current time. Wherever the PLC driver lives is the gateway that should be runningsystem.date.now(). (Both in the message handler and in the fast timer event.)
3 Likes