Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestions] Suggest UTC Now as standard Time Format, confused by logging times atm #639

Closed
RGrabichler opened this issue Sep 9, 2023 · 17 comments · May be fixed by #640
Closed

[Suggestions] Suggest UTC Now as standard Time Format, confused by logging times atm #639

RGrabichler opened this issue Sep 9, 2023 · 17 comments · May be fixed by #640
Assignees

Comments

@RGrabichler
Copy link
Collaborator

In the Issues #519 ]New-Feature] Extended Diagnostics in Blazor, i tinker around with the TcoMessages, i i noticed a TimeStamp Issue.

image
this is Timestamp logged in Console

image
this is the Timestamp in the Plc

image
this is my local Timestamp in Germany and Summertime

image
this is UTC

And this is a complete mess in my opinion.

I would suggest, to allways log in UTC, and everybody can display whatever he wants.

I only assume, the 15.50 timestamp comes from local Slovenia Time? UTC+2 ? In difference to Berlin +1 ?

So in my opinion, the Logger should use per default UtcNow, the Connector should use UtcNow, and
the Wpf or Blazor View can render whatever they want for the User, probably Utc with corresponding TimeZone.

@PTKu
Copy link
Member

PTKu commented Sep 9, 2023

There should not be a time difference between the time zones you mention.

@TomKovac?

@RGrabichler could you check that you call time synch in your program for the context? Something like this:
https://github.com/TcOpenGroup/tcopen-app-templates/blob/ec2b13f96b091538887fa9851f5fe3d3adfcdeec/templates/mts-s-template/t/src/x_template_x-xae/x_template_xPlc/Technology/Technology.TcPOU#L109C1-L109C29

@RGrabichler
Copy link
Collaborator Author

RGrabichler commented Sep 9, 2023

image
i call this here
image

this is the _rtc
image
But this is the logged message,
Timestamp in [ ] is my local Timezone Timestamp Utc+1, in the Payload it is Utc+3

@PTKu
Copy link
Member

PTKu commented Sep 9, 2023

You're right. It should be aligned... will have a look on Monday.

@PTKu
Copy link
Member

PTKu commented Sep 9, 2023

/cib

@github-actions
Copy link
Contributor

github-actions bot commented Sep 9, 2023

@PTKu
Copy link
Member

PTKu commented Sep 12, 2023

We are unable to reproduce.
@RGrabichler, what are the region settings of your PLC (time-zone)?

@RGrabichler
Copy link
Collaborator Author

for me it is UTC+1, Berlin Time.

@PTKu
Copy link
Member

PTKu commented Sep 12, 2023

Same as me! 😊
Where do you run your Blazor server? Is it on the PLC, or is it hosted elsewhere? It appears that there might be a difference in the environment settings between where you run your server and the PLC.

You can try running it with the second argument, specifying the AMS ID of your server as follows: app.RtcSynchronize(TRUE, 'YOUR_SERVER_AMS_ID', 60) (An empty string indicates that it will synchronize with the local system).

@RGrabichler
Copy link
Collaborator Author

ok, in this specific scenario, where i tinker with the Diagnosis Component, i use UmRT and blazor runs on local Dev Pc/
So presumably both run on UTC +1.

@PTKu
Copy link
Member

PTKu commented Sep 14, 2023

It looks like that might be an issue with UmRT.
Did you try:

You can try running it with the second argument, specifying the AMS ID of your server as follows: app.RtcSynchronize(TRUE, 'YOUR_SERVER_AMS_ID', 60) (An empty string indicates that it will synchronize with the local system).

?

@RGrabichler
Copy link
Collaborator Author

i tried, and i tried it with real hardware.
both have identical time settings
image
image
image
this is AMS ID from dev PC, were i run the Blazor App atm

@PTKu
Copy link
Member

PTKu commented Oct 3, 2023

@TomKovac any comment on this?

@RGrabichler sorry if you answered this question before, but what would be your correct local time in the example above?

@peterbarancek what time do we set to the TimeStamp in the messenger?

@peterbarancek
Copy link
Collaborator

"This is my output. I am running an app on my laptop. The time is synchronized with the PLC (as seen in the screenshot at the bottom right of the picture). It runs on .net48 and is a WPF application. In my opinion, the time difference might be due to using .net5 or Blazor..."

image image

@RGrabichler
Copy link
Collaborator Author

@TomKovac any comment on this?

@RGrabichler sorry if you answered this question before, but what would be your correct local time in the example above?

@peterbarancek what time do we set to the TimeStamp in the messenger?

in this case, 21.44 was the right time.

@RGrabichler
Copy link
Collaborator Author

i tried a bit
image
image
this is the ams ID from the PLC, manually changed the Clock to differ from real Time, to test it out.
image

This is my Dev PC
image
but this is not working, what am i doing wrong?
Time shows still Plc Time, even when i am setting AMS ID to Dev PC, where Blazor runs.

@PTKu
Copy link
Member

PTKu commented Oct 5, 2023

@RGrabichler, the update rate is currently set to 60 seconds. If needed, you can modify the second parameter to decrease this rate.

Regarding the original issue, we've pinpointed the cause of the time discrepancy. Connector.NET5 utilizes a newer ADS driver that considers the time zone. Given that the PLC time is designated as UTC, when a value is read from the controller, it's adjusted to local time.

Regrettably, we don't have a straightforward solution for this predicament at the moment. Addressing it would necessitate modifications in the Inxton connector. Please note that this connector is in its experimental phase and isn't officially supported for a .NET 5 target. While we don't have immediate plans, we may consider making the necessary adjustments in future major Inxton releases, especially those after the TwinCAT 4026 launch.

@RGrabichler
Copy link
Collaborator Author

ok, im fine with that and can implement a workaround with manually adding or subracting hours :X
thanks for the effort

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants