Hello I am having a issue “probably not a real issue but just the way ARsim works” where the ARsim clock after a simulation is started will progressively fall out of synch with windows time. I am utilizing MpAlarmX, MpAudit, and MpReport to manage Alarm and Audit lists and generate reports. All of that is functioning properly but all these libraries pull the information for timestamp automatically from the AR Clock. This is causing my alarm and audit reporting to show the incorrect time after the simulation has been running for over a hr and gets to the point.
I have combed through the Automation studio help trying to find any setting that could change this to no avail.
Things I have tried
Creating my own time structures and clock using astime. Wasn’t able to get it yet to keep time but rather just set a date and time, nor was I successful of at least pulling the time structure I had into the Time Stamp
This machine and production environment unfortunately does not have access to a NTP server and management doesn’t seem to motivated to install one even thought requiring contemporaneous time stamps on everything. I tried to be clever and create a NTP server on the local machine and get ARsim to talk to it threw the loopback and local IP to no Luck.
Now I’ve gone so far as to try and use a C++ program to link into the Windows API so I can poll the Windows clock every few minutes and forcibly update the ARclock to match. Only to run into the issues of Automation Studios GCC compiler to be very limited and plain garbage at anything more than printing hello world. It loves to give errors when compiling Visio Studio header files required to access the API which through figuring out additional build options got it down to 2 that wont go away.
I feel that there is something overly simple that I’m missing here and really shouldn’t have to come up with these crazy concoctions to just set the proper time for a alarm. I also don’t understand why there simply is no setting in the hardware configuration under physical view or why ARsim just doesn’t interface with the Clock on whatever computer its running on.
I’m not quite sure how ARSim syncs its system time (perhaps someone else knows and will reply). But you’re right that since it runs within Windows, it’s never going to be “realtime” in the same way that AR embedded is. How much of a discrepancy are you seeing over the course of an hour?
If you right-click on the traffic light icon in your taskbar and select ToggleView, you can bring up the ARSim settings window. The “Adjust time” page lets you speed up or slow down the simulation. You could check these settings and adjust if necessary:
If you need more precise timing than ARSim can provide, then I recommend using a real PLC as that will be easier to work with and can by synced with an NTP server.
What kind of tests are you running in simulation? If you want to stick with simulation there might be a way to log data in a more precise way than your current set-up.
Hello, We are using ARsim as a HMI platform for some of our machines and it talks to a Allen Bradly CompactLogix PLC through kepware. We were looking at an alternative to factory talk view with increased flexibility to meat certain needs. As a whole despite its steep learning curve it is a very flexible platform and we have liked it, and did deploy a satisfactory initial HMI application that’s currently running. However I didn’t notice the time stamp issue until after taking over the project personally after the lead engineer left and started to add features and make improvements.
It varies some but on average it seams to lose 3 to 5 minutes per hour.
Nothing that the HMI is doing is time critical except when a alarm comes in from the PLC and it triggers a event in Alarm X and grabs the AR clock. What I hope to find is a way to get the event trigger to grab another time source or find away to periodically update AR clock without hopefully breaking any of the other code when it does.
Also to add the alarm tags from the PLC are fed into MpAlarmXSet
But: I want to add that ARSim is not meant to be deployed to production and thus the drift is usually irrelevant, since testing if the PLC does the job based on what it /thinks/ the time is is still possible, even if it is faster or slower than the real clock.
I couldn’t find actual “do not do this” links, but rather it not being listed as “you can do this”:
Or from our conversational help:
“Hi may I use ARSim in production?” No, ARsim is not intended for use in production as it is a Windows-based simulation environment that is not real-time capable. It is designed for development and testing purposes only.
Therefore I also would like to recommend an actual PLC for your production environment.
