MX-RTC anomaly

[benb2000]

I have an MX-RTC installed onto a T100MD-888+. I have set the date and time manually.

I am running Trilogi 4.3 under DOS with a r47 version CPU.

During the online monitoring operation, and not all the time, the clock will revert to 1/1/1998,.

If I power down / and repower the unit, the date and time will be restored to the correct date and time.

Any thoughts as to this behavior?

Is there a proper procedure in setting the clock?

I have had the best success in downloading the program, then setting the clock, using manual mode.

This is my third T100MD-888+ operating with the same hardware and program, the MX-RTC seems to have less stability than the first unit.

Is there something I'm missing in getting the Date/Time to be correct all the time?

[support]

On the r47 CPU, if it discover an MX-RTC module installed, it will attempt to synchronize its software RTC value with the MX-RTC hardware every hour. I am wondering if it is this particular unit of MX-RTC that is not working too well when queried by the PLC. (i.e. if it doesn't provide correct data when queried by the CPU then the CPU will think that the MX-RTC is absent and revert the clock back to 0:0:0 and 1/1/1998).

Please contact your dealer or email sales@tri-plc.com to arrange for a replacement MX-RTC and let us know if that resolves the issue. We will like to receive from you the problematic MX-RTC unit to conduct further testing.

[benb2000]

I have had this phenomena happen on two T100MD-888+ with two different MX-RTC's.

The PLC is used in an application using an optical encoder to drive HSC1 and HSC2 . I am measuring position as well as velocity.In order to test my completed system, I feed a quadrature signal into the unit, and have the following code at 1st.Scan

SETSYSTEM 4,2 'set HSC2 encoder decoding to best for jitter
HSCDEF 2,2,2000000' set count to run Cust Fcn#2 at 27343 feet

' this is 128 ppr = to 1.75 ft
' set counter HSC[2] as a bi-directional quadrature encoder counter
HSCDEF 1,2,2147483647' set upper number to (2^31)-1 bits
'set counter HSC[1] as a pulse counter, no matter what direction
setlcd 0,1, chr$(12) ' hide cursor
J=0 'Used in Rod Rate Measurement using Rung Timing
SETBAUD 1, 4 ' SET COMM1 TO 19200, 8 , N, 1

Custom Function #2 is

' ZERO ENCODER COUNTER  SAVE DATA IN BATTERY BACKED MEMORY
IF HSCPV[2]=0  THEN GOTO @40 'Set Value of Encoder Counter to 0
ENDIF
IF V=0 THEN V=1
ENDIF
IF V>=3960 THEN V=1 ' LIMIT OF DATA FILE IN GROUPS OF 4, 4*990=3960
ENDIF
'AT 990 JOBS WILL START RECORDING OF DATA STARTING OVER AT DM[1]
DM[V]=DATE[2] ' MONTH
DM[V+1]=DATE[3] ' DAY
DM[V+2]=DATE[1] ' YEAR
DM[V+3]=HSCPV[1]*10/2399 ' SCALE IN WHOLE METERS
X=DM[3999] 'LOAD OLD TOTAL LOWER 16 BITS
SETHIGH16  X,DM[3998] 'LOAD OLD TOTAL UPPER 16 BITS
X=X+DM[V+3] 'ADD CURRENT CHAIN TRAVEL IN METERS
DM[3998]=GETHIGH16(X) 'WRITE UPPER 16 BITS OF TOTAL METERS TRAVELED
DM[3999]=X ' WRITE LOWER 16 BITS OF TOTAL METERS TRAVELED
DM[3995]=DATE[2] 'CURRENT MONTH FOR LAST TOTAL WRITTEN
DM[3996]=DATE[3] 'CURRENT DATE FOR LAST TOTAL WRITTEN
DM[3997]=DATE[1] 'CURRENT YEAR FOR LAST TOTAL WRITTEN
V=V+4

@40
HSCPV[2]=0  'Set Value of Encoder Counter to 0
HSCPV[1]=0  'Set Value of Encoder Counter to 0

If I leave the unit running continuously 24/7, typically I will see 10 resets per day, but when I return in the morning, the date has reverted to 1/1/1998. I have also had this happen when using On-line monitoring, where one instance it is displaying the correct date, then reverts to 1/1/1998.

Recently, I have run the system for 10 to 15 minutes each day, then removed power. The time and date settings are correct upon repowering the system. So the RTC is functioning properly when not powered.

Is there anything in my code that would lead to this date change?

Could it be a socket/MX-RTC pin  problem? If the PLC interrogates the MX-RTC every hour, is the communication specific to a particular pin or pins?

Do you have a recommended way of holding the MX-RTC in the socket, so that it won't come out? It slips in and out of the socket easily.

Your assistance is appreciated.

[support]

In the firmware r47 the CPU checks the MX-RTC every hour of the clock instead of just at 0:00:00 and synchronizes its RTC value with that of MX-RTC. The purpose was to get better accuracy than the software based RTC. However, it seems some some of the MX-RTC do not always respond properly when queried by the CPU and when that happens, the CPU thought that the MX-RTC is not present and hence reset the time to factory default time.  However, actually the MX-RTC is still running and when you power cycle the PLC the CPU again reads the MX-RTC data accurately and set the clock properly.

At the moment we are still trying to find out if the problem is specific to some MX-RTC modules or if there is a need to fix the firmware to take care of this problem. In 2-3 weeks time we should have a clearer picture and will take appropriate action to replace either the MX-RTC or the CPU of affected units.

[benb2000]

Thankyou for your efforts.

[benb2000]

I ran two tests on the T100MD-888+ with MX-RTC installed. My system uses the HSC function with an optical encoder.

The first test was to power the unit, running the program without feeding it any encoder signals. The system was left 24/7 for two days and the clock operated correctly, changing at midnight to increment time and date, as well as being powered down, and back up with the correct time and date. ( Not a Low Temp rated CPU )

The second test, (done twice, once with the CPU that was shipped, and once with the low temp CPU) was with a signal generator running a simulated optical encoder input, as with the code above. The first day with the regular CPU clock incremented correctly, the second day the Low temp CPU arrived and was installed, Left overnight the clock reverted to 1/1/1998.

Powering the unit down, then back up again, 2 minutes later, produced a date of 8/9/1998 ( today being 8/19/2004 )

Conclusion, the reading of the clock, being interrupt driven, has an interaction with the HSC functionality

Both CPU's were r47 code.

If there are any tests that should be run, let me know.

I need to get this resolved.

This is my third T100MD-888+, the forth is on my desk, I believe the first unit I used ( which didnot have thid problem, I left it running with the simulator for close to a month ) had the r45 Code. Is it opossible to buy CPU's with the r45 code?

Your assistance is appreciated

[support]

We now found out if the CPU is interrupted during the read from MX-RTC then the data read is incorrect and that is the reason why the clock get reset to "no MX-RTC" default state. Prior to firmware r47 the MX-RTC is only read once during power on and 0:00:00 once a day therefore the interrupt issue never become apparent. We will be releasing a new firmware revision to address this problem shortly. Please email to support@tri-plc.com to arrange for a schedule for CPU swap.

[benb2000]

Looking forward to the upgraded Firmware.

Are the CPU's Flashable to reprogram them, or they OTP types?

In my application I have to use Low Temp rated devices that are a at premium prices.

Thankyou for the assistance

[support]

Unfortunately the CPU are not reflashable. We will need to send new CPU to your distributor and you will need to return the old CPU to us. Please arrange with your distributor for the required quantity of CPUs that you need.

[benb2000]

I have just received r48 Low temp CPU's to replace the r47's that I have. I will test these over the next week, to see if the RTC remains correct, and does not revert to 1/1/1998.

For curiosity sake, what changes were made to fix the problem?

Are there any other changes made, or added functions, for the r48 revision?

Your assistance is appreciated.

[support]

The main problem was that the system interrupt was not turned OFF during read cycle from MX-RTC and the interrupted read process resulted in garbage data being returned to CPU. It then concludes that no MX-RTC is present and reset the clock to factory default. This has been fixed in r48.

r48 also support changing of its own ID by SETSYSTEM 8, n where n is the new ID.  The current version of TRILOGI only compile this statement if n is a constant but changes is being made so that newer version (5.32) to be released later will compile the statement if n is a variable.

[benb2000]

Thankyou for you fine efforts,

3 days running, and no problems.

Good work.

All I need now is a faster CPU ( scan times of 0.05 sec. ), more memory, and 12 bit A/D. Other than that, this is a very good product.

Thanks again for the fix, in r48.

[support]

Thank you for the feedback. We are glad all works out well!