RTC accurancy problem on SAMBA

[Spyros73]

Hello, I am using SAMBA PLC (4.3 and 7.0 as well) for historic car rallies, in order to calculate ideal distance based on time and a given average speed.

I have noticed that the RTC has a strange behaviour. I syncronize my PLC RTC with an accurate digital clock, and after a few minutes, I can notice already, a small difference (e.g. 3/10 of a second). But after a while, the two clocks are syncronized again.

I tried also the following. I used the SB 15, which comes true 10 times per sec, and I increase a ML15 every time SB 15 is true.

In parallel, I created a bit (MB6) which comes true, every time the RTC seconds change. Based on it, I increase ML10 by 10 this time.

I compare those 2 values every second. If everything was ok, the difference of these values should always be 0, or at least something fix, but in fact I see that this difference is changing, from 0 to 5 (means max difference 0,5 sec)

Why this occurs, and is there anyway to avoid it? In fact I need an accurate RTC, which will always be synchronized with the rally organization clock.

 

Thank you in advance

 

 

 

[Flex727]

I've never had to deal with the kind of clock accuracy you're needing here so this is interesting. I can't imagine that SB 15 would be based on anything but the RTC, so in theory they should be exactly the same. However, I would ask what is your Scan Time (SI 0)? You must keep in mind that the PLC communicates with the outside world only once per PLC scan. A lot can happen during that scan. You might be able to overcome this to some extent by using interrupts and immediate reads and writes.

Also, in my experience, the built-in PLC clock is not usually an extremely accurate clock. They drift pretty rapidly.

[Joe Tauser]

The PLC clock is usually accurate to a minute a month.  It should not drift as much as you are noticing.

You did not state your frame of reference for observing time.  Is it on the PLC screen, or are you communicating with the PLC?  Serial or Ethernet?

At the end of the day, the PLC clock can be counted on to 0.01 second.  If you need better than this you need another device.

Post your code so we can see what you're trying to do with synchronization.

Joe T.

[Spyros73]

Thank you both, for your reply.

Monthly drift of RTC is as you say (~1 sec per day), and this is ok for me, but this is not my problem.

I have attached a simple software, where you can see what I mean.

I am using 3 counters. MI13 increases by 10 when SB13 is true, MI15 increases by 1 when SB15 is true. MB 19 is their difference, calculated when SB13 is true. MI19 stays constant which sound very logical.

 

I am also using MI17 which increases by 10, every time SI30 (seconds of RTC) change, and then I also calculate the difference between, MI17 and MI15, and save it on MI21. In this case, if you follow the software for a few minutes, you will notice that the MI21 is not stable, but little by little changes, and in a certain moment, it returns to its initial value (kind of auto correction of the clock indication).

 

Please have a look and let me have your comments

For my application, is crucial to know that the time I see on the screen is really the one saved on the RTC.

test clocks.vlp

[Flex727]

Why are you trying to write to SI 0?

[Spyros73]

Oh sorry, just ignore it, I wanted to try if I can force the scantime. ( I can do this in schneider PLC)

Anyway, for your info, on my normal software which is much bigger, the scan time is 4 ms

[Flex727]

Just a data point for you:

I didn't have a Samba readily available so I downloaded into a V700. My scan time is less than 1ms. You are correct that there is some variation exhibited with MI 19 & MI 21. I am seeing MI 19 sitting at 4 with no variation and MI 21 is ranging from -3 to 4. MI 19 seems stable and MI 21 seems to jump suddenly to a new value after sitting at a value for some length of time.

Based on your code, I would expect MI 19 to be 0-9 (depending on where the RTC is at power up), and indeed I see it at a rock solid value that is different each time I reset the PLC. I would have to give some thought to MI 21 to understand why it seems to be jumpy.

By the way, I deleted the Store to SI 0 before testing on my V700.

[Flex727]

I've let this run for hours now. MI 19 hasn't budged (though it changes at each reset), but MI 21 still bounces around randomly.

[Ausman]

Hi all,

just quickly looking at this and it is something I've done way in the past when I was young and heavily involved in club motorsport.  I had an inductive on a non-driven wheel giving me distance info into my system, which I'm assuming you have involved as well.  I don't have a Samba to run your ladder on, so can only comment on what I see.   2 things quickly:

1).  I found many placements in your ladder which I would be separating out, or alternatively combining into one rung.  eg 3 , 5.  I have times where this has solved an issue that shouldn't happen, but does.  There might be scan sequence issues.

2).  Have you thought of using the time based  interrupt, like I posted here:

It could be worth experimenting with this and comparing it to the RTC over time, as it will give you much more accuracy having things down to much smaller time intervals. You  may even be able to convert it into your own "RTC", rather than the inbuilt version.

However, I have always assumed with Unitronics gear, (and am happy to be told otherwise) that the RTC and the time based SBs are independent.   I have thought that the RTC is from a dedicated chip, and the SBs are from the system's time base.  For that reason there can be discrepancy over time, and I take trouble to create separate controls if I need to relate things to real time, or a virtual time count.

cheers,

Aus

[Spyros73]

Hi all, thanks for your response.

Here some comments from my side.

To Flex727: This is exactly the behaviour I have also noticed. Although, the MI21 does not really changes randomly. If you notice, it has a max value e.g 8, and decreases litle by litle till to reach a min value (5 less), and then returns again to its max value. So it look to me like an internal control of the RTC, which every time sees that it has lost 5/10 of a second, it adds 5/10. In fact, in my operational software, we had realy noticed this, just by watching on the clock. We were adjusting it, according to an external watch, and now and then we could see some differences .

To Ausman: Yes indeed on my operational software I am using also two conductive sensors, coupled on wheels, and connected to VFC on the plc, in order to measure the driven distance. As we are talking about regularity rallies, it's essential to compare theoretical distance (based on given average and time), with really driven distance.

The sample software I downloaded, was just to show the problem I noticed.

I will have a look on your post later today, If I understand well, you propose to create my own RTC, based on the SB??

 

Regards

[Flex727]

Since the PLC RTC is being synchronized with an external clock, why not create your own SBs based on the RTC? Run a 10 or 100ms timer that indexes a counter that gets reset by the RTC seconds.

[Spyros73]

This is what I originally tried to do. If you see my demo software, I have used a MB (I think MB6) which comes true every time SI30 changes. And here is where the problem occurs, that even if I syncronize the RTC with a clock, after a while, you can see that the seconds have drift a little bit, so SI30 is not channging anymore syncronized with my clock. And the strange thing is that after a few minutes, it adds half a second, and then they are syncronized again, and so on. The problem is that in those competitions everything has to do with accurancy, and we have achieved such a good one (less than 0,5 sec), so that drift starts being significant.

[Ausman]

17 hours ago, Spyros73 said:

you propose to create my own RTC, based on the SB??

Yes, but only after doing some trials on the innate accuracy of the method. Like I said, in theory it is accurate and will work ok, it's meant to be a precise 2.5 or 1.25.  If it is ok through extended testing, you would set it up so that you can easily match it to the master and go from there.  I'm wondering whether the error you currently get is due to the firmware not reading the RTC info every scan?  Alex?  Saragini?

cheers,

Aus

[Spyros73]

I started working on making my own clock, based on the SB of 1/10, but then I thought that this can not work out, because every time I switch off power (and this can easily happen during a rally, as in many cars when engine starter runs, voltage drop is significant, and plc goes off for 1-2 seconds), then the SB are not counting and my clock will stay behind. I could of course automatically syncronize my clock with the RTC every time the plc goes on, but in this case, I will finally transfer the RTC error to my clock.

Should I expect any official reply from Unitronics, or I have to send an e-mail??

Thanks

[Flex727]

It seems to me that you could account for the reset of the PLC with the proper math at startup. SB 2 is handy to execute some instructions on the first PLC cycle only.

Unitronics personnel often browse these boards, but I recommend emailing support@unitronics.com if you want to be sure you get some immediate help.

[Ausman]

Hi again,

vehicles are notoriously noisy electrical environments, so I had always assumed that you were running a buck/boost with heavy filtration as the power supply, and protecting the PLC with shielding in an appropriate box.  It would be an easy thing to also have this configured as a UPS, with it's own very small battery done appropriately into the main system so that it only connects once the engine is running and stable. 

As an aside, I once had a very stable computer system go absolutely haywire at the crucial 24 hour team relay circuit race I had built a dedicated laps monitoring program for.  It worked fine during extensive testing, but once at the track, in the tower 15m from the nearest approach point, certain vehicles would play havoc with it.  Ended up having to move it into an underground room much further away for the race duration...very annoying!!  But we are talking an Amiga 500.  Ahhh...how times change!

cheers,

Aus

[Ausman]

Hey Cara, do I get a prize for being the Lucky 1000th post on this forum?

Ha Ha,  Aus.

[Joe Tauser]

5 hours ago, Ausman said:

Hey Cara, do I get a prize for being the Lucky 1000th post on this forum?

 

 

Calorie free.  Enjoy!

Joe T.