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.
Well I ended up going with just pulling the date and time from the PLC into a array and sending it up to the HMI through OPC UA. Then I’m using that data to update the ARSIM RTC clock by loading the data into rtc_settime once a second. This keeps the timestamps accurate and it doesn’t seam to affect the simulated CPU Cycle.
I get that using ARSIM isn’t the preferred way but my company has 2 requirements. One: PLC’s must be Rockwell Allen Bradly and Two: HMI/IPC displays must run a windows OS. When quoted by a B&R sales rep and the integration engineer on the Change Your View package 3 years ago. They said that the ARSIM package would work fine as just a HMI package for what we needed and it has. Largely I haven’t had any large issues out side of the date and time and it functions well. I know there was another option on the table to use a VM of the AR runtime and a VM of windows and share information through Hypervisor but that was ruled out at the time because of cost.
It may not be my ideal or a elegant solution but the time and date is fixed and things are running well again.
Thank you for sharing your solution, and I’m glad you figured something out! This is great information to have on the Community.
ARSim is powerful but its biggest downside is that timing is not as accurate as it would be on a real PLC. Your use case of just HMI functions with no machine control code is a good example where it can be useful on a machine since those functions are not time critical anyway.
That’s a good option and for a very similar use case talking to an Allen Bradley controller we ended up setting the ARsim time every minute to the OpcUa server clock, otherwise yes ARsim just runs away and causes all sorts of errors.
If you do you use SetTime make sure you also set to option to not enter the function call into the logger
