Peer-to-Peer - how do YOU do it?

Thanks Mary,
These clocks drift quickly and we need at least .01 accuracy. After using the Time Sync function we are off a second or two in a a few minutes, (some fast some slow) I have been using Opto 22 for about 30 years and used to make my own controller before Cyrano came out. I had better control over time then. I can add external clocks to each R1 but at that point I might as well not use the R1. Of course I also wonder how accurate the time sync function is. From some testing I have done it seems to be within a ms or two.
I guess I would just like to ask for hundredths since midnight be considered as a future feature. I do a lot of work for the Government and we need to know what time it is.
Thanks

Wow, 30 years!? Thanks, Norm, for being such a long-time OptoUser!

I’m still a little confused here on what you mean by “within a ms or two” for your test values, vs. “off a second or two in a few minutes…”, and I’m also not sure how this fits in with the rest of your logic – the timing of which could also vary depending on how many and what charts you’re running, etc.

However, there IS a 100ths of seconds value in the mem map, which you can read from your strategy.
Specifically at address F035 0000 (as seen here in the mem map protocol guide, form 1465):


and in PAC Manager:


Here’s how you might read/parse this in your strategy:

// Read date/time from mem map, format: "2015-01-09 14:36:48.96"
nResult = ReadStrFromIoUnitMemMap( 22, MyMemMap, 0xF0350000, sMemMapDateTime );


// that 22 character date/time could be parsed a few different ways, here's one way:
GetSubstring( sMemMapDateTime, 11, 2, sHours ); 
GetSubstring( sMemMapDateTime, 14, 2, sMinutes ); 
GetSubstring( sMemMapDateTime, 17, 2, sSeconds ); 
GetSubstring( sMemMapDateTime, 20, 2, sMilliseconds ); 
sMilliseconds = sMilliseconds + "0"; // since we read just hundreds of a second


nMSSinceMidnight = StringToInt32(sMilliseconds) + (StringToInt32(sSeconds) * 1000) + // that's all the seconds & parts of them
  ( StringToInt32(sMinutes) * 60 ) * 1000 + // there's the minutes converted to milliseconds
  ( StringToInt32(sHours) * 60 * 60 ) * 1000; // there's the hours to minutes to seconds to milliseconds

I’m not sure you’d even need to do all that parsing. Depending on your setup, you might have a “master” R1 that’s occasionally calling the NTP commands also do that ReadStrFromIoUnitMemMap above, then do the corresponding write to all other R1s.

The write would look like this:

nResult = WriteStrToIoUnitMemMap( YourMemMap, 0xF0350000, sMemMapdateTime );

Do you see what I mean? Would that help?

-OptoMary

Hi Mary,
Sorry for confusion. I already use that mm location. The only reason i started asking about ms since midnight is because earlier in this thread Ben mentioned he had used it. Recently he clarified that it was not ms since midnight but ms since reset or power up. Until he made that clarification I thought it was an undocumented feature that would have been handy.
To further explain what I mean about “a few ms off” try this simple test. Set up 2 R1 controllers. Trigger the NTP sync on both of them at approximately the same time. Now, in theory, they should both have the same time of day assuming that the sync function is fairly accurate. In other words, did it set to the second, .1, .01, .0001, etc…? Now trigger an event that makes both of the R1’s record the time in F035 0000 to their LOCAL memory map. Now look at those locations. You should see that both times are within a couple of ms of each other. This is the only way I have of knowing that the NTP Sync did have good resolution (without talking to a developer or seeing the code). Now wait 20-30 minutes and repeat writing to the mm without doing the NTP sync. You will see the drift becomes significant when trying to stay within .01sec
If your project simply wants to know how long a measured event is then using ms since midnight allows you to simply subtract start from finish. Easy, no parsing, (except an extra step to make sure we did not roll over midnight). Now think in terms of the power grid, or a water system where start and stop might come from different locations (R1’s).
Id be happy to discuss this with you further, call anytime, I am in your system under EDCS.

Yes, when I started buying Opto 22 you were still in Huntington Beach and Temecula was a farm town.

I thought I would chime in on this thread even though it is an older one because I have some unique Peer to Peer solutions that I have implemented.
I have to read/write values between controllers and custom PC based software written in Visual Studio. I first started using ModbusTCP using the ModbusTCP integration kit. This worked fine until the amount of data that I needed to share became somewhat large. Some of the controllers are remote and communicate via the internet and cellular data connections. This adds a lot of delay between a request and a response. ModbusTCP can only request 62 (32bit) registers per call. The delay for multiple calls was unacceptable so I implemented a UDP (although it can be done with TCP) connection that reads and writes scratchpad memory tables between the controllers and the PC (using MMP.NET functions). I implemented a simple and very similar to the Modbus protocol to send selective data back to the controllers and using a block of 2K of scratch pad memory for the data. So I am able to read and write all of the data in one function call and significantly reduce the delay time.