Legacy Hardware and Apps
Schedules don't run

Hello!

I need your assistance for a problem that i have.
My DT500 that does not run the schedules. To demonstrate I made a simple program For example:
; BEGIN
; D
; RA5S
; T
; 1CV
; END
RESET

DT500 Respond:

DataTaker 0 Version 7:14
Initializing ... Done.

Date 18/06/2015

This should show in Detransfer every 5 seconds the current hour and the 1CV. But no. Just runs the command D, that i place before de RA5S. That's how i know that the program is running but not the schedule's.

I try with others programs more complex and it is the same thing.

Also i notice, that whenever i run manually the T command, the time is still the same. No changes.
Only when i do RESET command, time is update, but only on time.

I also run TEST and the result is:

TEST
Datataker 52 Ver 7.14
Vos (mV) 0.010
Vfo (V) 7.103
Fc (kHz) 12.274
CMRR(db) 108.0
Vos3(mV) 0.244
Tos 1.0005
Ios (nA) 0
Ibia(nA) 6
Ibat(mA) 15.5
Vbat (V) 6.8
Vos*(uV) -2
Vos+(uV) -1
Vos-(uV) -3
VosR(uV) 3
Vosd(uV) 1
Ics1(mA) 2.5652
Ics2(uA) 213.64
PASS

Can you help me, please?

Carlos

Hello! I need your assistance for a problem that i have. My DT500 that does not run the schedules. To demonstrate I made a simple program For example: ; BEGIN ; D ; RA5S ; T ; 1CV ; END RESET DT500 Respond: DataTaker 0 Version 7:14 Initializing ... Done. Date 18/06/2015 This should show in Detransfer every 5 seconds the current hour and the 1CV. But no. Just runs the command D, that i place before de RA5S. That's how i know that the program is running but not the schedule's. I try with others programs more complex and it is the same thing. Also i notice, that whenever i run manually the T command, the time is still the same. No changes. Only when i do RESET command, time is update, but only on time. I also run TEST and the result is: TEST Datataker 52 Ver 7.14 Vos (mV) 0.010 Vfo (V) 7.103 Fc (kHz) 12.274 CMRR(db) 108.0 Vos3(mV) 0.244 Tos 1.0005 Ios (nA) 0 Ibia(nA) 6 Ibat(mA) 15.5 Vbat (V) 6.8 Vos*(uV) -2 Vos+(uV) -1 Vos-(uV) -3 VosR(uV) 3 Vosd(uV) 1 Ics1(mA) 2.5652 Ics2(uA) 213.64 PASS Can you help me, please? Carlos

Hi Carlos,

Why did you put RESET at the end of your program?
RESET will cause the program to stop.

Best regards,
Rudy Gunawan

Hi Carlos, Why did you put RESET at the end of your program? RESET will cause the program to stop. Best regards, Rudy Gunawan

Hello!

Thank you for your reply!
The RESET it's a not part of the program,i put it mannualy after enter the program.
As you can see it does not have prefix ';'
This was a simple example just to show you the problem.

Thank you!

Hello! Thank you for your reply! The RESET it's a not part of the program,i put it mannualy after enter the program. As you can see it does not have prefix ';' This was a simple example just to show you the problem. Thank you!

Hi Skeighter,

It is true that dataTaker will not consider RESET as part of the program, but using it will cause the program to stop.
You will need to wait for a couple of seconds after the last END entry (indicates the end of program) for the program to build itself and run the logger.

Sending RESET will stop the program from running.

Best regards,
Rudy Gunawan

Hi Skeighter, It is true that dataTaker will not consider RESET as part of the program, but using it will cause the program to stop. You will need to wait for a couple of seconds after the last END entry (indicates the end of program) for the program to build itself and run the logger. Sending RESET will stop the program from running. Best regards, Rudy Gunawan

Hello

So good to find my exact problem in here. So sad to find no solution for it. smile

First of all, I would like to clarify Skeighter's posts, because I can clearly see a misunderstanding here.

The RESET command at the bottom of the command list is, as Skeighter described, not part of the program itself. Skeighter issued this command to reboot the datalogger after having written the commands into the card, and subsequently to run that program from the card.

Anyway, I believe this is a hardware issue, because I have already erased and rewritten the latest (7.14) firmware into the flash memory and the problem is still there.

The Time channel only changes after a reset/reboot, like Skeighter described. As well as the System Timers 1..4ST, don't change by themselves, only after a reset/reboot they get the new values from the RTC (real time clock), and after they are stuck with those values until we reboot it again. There is no triggering of time changing, although the time is indeed changing inside the RTC.

Now the problem is where? The RTC or the Zilog CPU? Or somewhere else completely? Maybe the full schematics (circuit) of that part of the logger could help to converge into the problematic area. Or if the developpers/experts of/in the logger care to reply with some wisdom, it would be greatly appreciated

Best regards,
Renato

Hello So good to find my exact problem in here. So sad to find no solution for it. :cry: First of all, I would like to clarify Skeighter's posts, because I can clearly see a misunderstanding here. The RESET command at the bottom of the command list is, as Skeighter described, not part of the program itself. Skeighter issued this command to reboot the datalogger after having written the commands into the card, and subsequently to run that program from the card. Anyway, I believe this is a hardware issue, because I have already erased and rewritten the latest (7.14) firmware into the flash memory and the problem is still there. The Time channel only changes after a reset/reboot, like Skeighter described. As well as the System Timers 1..4ST, don't change by themselves, only after a reset/reboot they get the new values from the RTC (real time clock), and after they are stuck with those values until we reboot it again. There is no triggering of time changing, although the time is indeed changing inside the RTC. Now the problem is where? The RTC or the Zilog CPU? Or somewhere else completely? Maybe the full schematics (circuit) of that part of the logger could help to converge into the problematic area. Or if the developpers/experts of/in the logger care to reply with some wisdom, it would be greatly appreciated Best regards, Renato

Hi Renato,

Date, time and 1ST...4ST should work on DT500.
5cba866cefb59

Could you send me your code for review?

Best regards,
Rudy Gunawan

Hi Renato, Date, time and 1ST...4ST should work on DT500. ![5cba866cefb59](serve/attachment&path=5cba866cefb59) Could you send me your code for review? Best regards, Rudy Gunawan

Hi Rudy,

Thank you for replying.

That's exactly the problem. If the schedules were working fine, I wouldn't be trying to figure out what's up with this DT500.

Datataker 0 Version 7.14
Initializing...Done.

BEGIN
BEGIN
/e
/e
RA1S
D
T
LOGON
END
T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

T
Time 12:44:44

D
Date 20/07/2015

D
Date 20/07/2015

RESET

Datataker 0 Version 7.14
Initializing...Done.

T
T
Time 12:55:18

T
T
Time 12:55:18

T
T
Time 12:55:18

T
T
Time 12:55:18

T
T
Time 12:55:18

RESET
RESET

Datataker 0 Version 7.14
Initializing...Done.

/e
/e
T
Time 13:09:01

T
Time 13:09:01

T
Time 13:09:01

T
Time 13:09:01

T
Time 13:09:01

T
Time 13:09:01

T
Time 13:09:01

BEGIN
RA1S
1..4ST
LOGON
END

The code above is using the schedules provided in your example, and using immediate schedules to show how the time channel is not being updated by the RTC. The time triggered schedule will not run, because it's a time triggered schedule. If the time is not changing to the logger, the interval is always 0S, therefore it never reaches the schedule interval (1S).
After setting the scehdules from your example, nothing happens.

Although the RTC is working and after a RESET the time channel gets the updated value from the RTC. It seems like the RTC is not triggering the logger into reading its new value every second, if that's the way it works. I don't know if it's the RTC that triggers the logger. I have been reading the documentation extensively, to try to get some hint on where the problem really is.

And, of course, if with this simple code the logger doesn't work, with the much more complex code that is used for weather (Temperature, relative humidity, radiation, rain) monitoring, it won't work at all. I think there is no point in putting that code up here because, obviously, the problem lies elsewhere completely as shown.

Best regards,
Renato

Hi Rudy, Thank you for replying. That's exactly the problem. If the schedules were working fine, I wouldn't be trying to figure out what's up with this DT500. Datataker 0 Version 7.14 Initializing...Done. BEGIN BEGIN /e /e RA1S D T LOGON END T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 T Time 12:44:44 D Date 20/07/2015 D Date 20/07/2015 RESET Datataker 0 Version 7.14 Initializing...Done. T T Time 12:55:18 T T Time 12:55:18 T T Time 12:55:18 T T Time 12:55:18 T T Time 12:55:18 RESET RESET Datataker 0 Version 7.14 Initializing...Done. /e /e T Time 13:09:01 T Time 13:09:01 T Time 13:09:01 T Time 13:09:01 T Time 13:09:01 T Time 13:09:01 T Time 13:09:01 BEGIN RA1S 1..4ST LOGON END The code above is using the schedules provided in your example, and using immediate schedules to show how the time channel is not being updated by the RTC. The time triggered schedule will not run, because it's a time triggered schedule. If the time is not changing to the logger, the interval is always 0S, therefore it never reaches the schedule interval (1S). After setting the scehdules from your example, nothing happens. Although the RTC is working and after a RESET the time channel gets the updated value from the RTC. It seems like the RTC is not triggering the logger into reading its new value every second, if that's the way it works. I don't know if it's the RTC that triggers the logger. I have been reading the documentation extensively, to try to get some hint on where the problem really is. And, of course, if with this simple code the logger doesn't work, with the much more complex code that is used for weather (Temperature, relative humidity, radiation, rain) monitoring, it won't work at all. I think there is no point in putting that code up here because, obviously, the problem lies elsewhere completely as shown. Best regards, Renato

Hi Renato,

I understand your problem now, although it is very rare RTC update failure does happen.
It seems this is the case on your logger, if DT500 can't update its time obviously no schedule can run.

Unfortunately the RTC chip has been obsolete a few years back, so I could not assist you on fixing this unit.

Best regards.
Rudy Gunawan

Hi Renato, I understand your problem now, although it is very rare RTC update failure does happen. It seems this is the case on your logger, if DT500 can't update its time obviously no schedule can run. Unfortunately the RTC chip has been obsolete a few years back, so I could not assist you on fixing this unit. Best regards. Rudy Gunawan

Hi Rudy

Excuse me for my late reply.

Thank you for your insight into this problem.

I'm not an easy quitter so, I have been reading more of the DT5** documentation and found out some other possible failure point that could be causing this.

5cba87543d4f4

Also the top (from the two installed) 82C54 on the board shows some light discoloration in one spot, plus the varnish has peeled out in that spot too. It could have failed somehow.

I know that the RTC, as well as these counters, are both obsolete components, but there are still places on the internet where they can be found. Maybe there are some new ICs compatible with these ones, I'm not sure.

Is there a way to test these counters, or any other special purpose IC (converters or other), for example from the BOOTSTRAP command line? I used the RP 78000 and RP70000 to try to get something, but I don't know what kind of values should I get from them. Here is the output:

BOOTSTRAP
Bootstrap mode V1.02 (FLASH)
Flash Manuf ID = 01, Device ID = A4
RP 78000
[PHYS]00078000:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078010:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078020:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078030:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078040:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078050:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078060:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~
[PHYS]00078070:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~

RP 70000
[PHYS]00070000:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070010:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070020:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070030:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070040:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070050:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070060:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~
[PHYS]00070070:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~

I am also curious about what the ADC X/Y counters are. I couldn't find any reference to them other than the one on that table. Could you enlighten me about those?

Best regards,
Renato

Hi Rudy Excuse me for my late reply. Thank you for your insight into this problem. I'm not an easy quitter so, I have been reading more of the DT5** documentation and found out some other possible failure point that could be causing this. ![5cba87543d4f4](serve/attachment&path=5cba87543d4f4) Also the top (from the two installed) 82C54 on the board shows some light discoloration in one spot, plus the varnish has peeled out in that spot too. It could have failed somehow. I know that the RTC, as well as these counters, are both obsolete components, but there are still places on the internet where they can be found. Maybe there are some new ICs compatible with these ones, I'm not sure. Is there a way to test these counters, or any other special purpose IC (converters or other), for example from the BOOTSTRAP command line? I used the RP 78000 and RP70000 to try to get something, but I don't know what kind of values should I get from them. Here is the output: BOOTSTRAP Bootstrap mode V1.02 (FLASH) Flash Manuf ID = 01, Device ID = A4 RP 78000 [PHYS]00078000:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078010:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078020:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078030:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078040:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078050:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078060:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ [PHYS]00078070:FB FF E1 7E FF 00 A0 7E FB FF E1 7E FF 00 A0 7E ...~...~...~...~ RP 70000 [PHYS]00070000:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070010:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070020:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070030:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070040:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070050:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070060:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ [PHYS]00070070:00 00 00 7E 00 00 00 7E 00 00 00 7E 00 00 00 7E ...~...~...~...~ I am also curious about what the ADC X/Y counters are. I couldn't find any reference to them other than the one on that table. Could you enlighten me about those? Best regards, Renato

Hi Renato,

Please check on RTC clock IC and Reference Clock IC to fix DT50.

82C54 discolouration might contribute to counter channel failure but not the entire unit.

Best regards,
Rudy Gunawan

Hi Renato, Please check on RTC clock IC and Reference Clock IC to fix DT50. 82C54 discolouration might contribute to counter channel failure but not the entire unit. Best regards, Rudy Gunawan

Hi Rudy,

Thank you.

Yes, I would like to fix this unit, with your help, of course. But I also understand the limitations of such fix, due to being a relatively old equipment.

Since I can see everything else seems to work just fine on the DT500 (the TEST result is PASS, it can read sensors with no problem), it is just this timing issue that has ruled the whole equipment useless, it would be a shame having to send it for recycling already.

I could find the RTC IC on the board. It is the DS1315S 336 component. Visually it looks fine. Would I need to test it with an oscilloscope? How can I tell if it has gone bad?
The Reference Clock IC, I am not sure what it is. Is it the Crystal Oscillator (C2KC55MS) for the RTC?

What I can not understand is that the clock does keep track of time, it just does not update the Time channel/variable unless on boot (after starting up or after a reset). Therefore I believe not the whole RTC would have failed. And also the System channels/variables for time (ST), also keep unchanged unless on boot, when they do get the values from the RTC. The T value can be changed and keeps its new value registered on the RTC, because on power off/power on it will show the time according to the change. It just does not change while the logger is running "normally".

Here are some photos of the DT500 board. Apologies for the bad webcam quality.

5cba885be1c97

5cba885ceee24

5cba8869e5f6c

Best regards,
Renato Casqueira

Hi Rudy, Thank you. Yes, I would like to fix this unit, with your help, of course. But I also understand the limitations of such fix, due to being a relatively old equipment. Since I can see everything else seems to work just fine on the DT500 (the TEST result is PASS, it can read sensors with no problem), it is just this timing issue that has ruled the whole equipment useless, it would be a shame having to send it for recycling already. I could find the RTC IC on the board. It is the DS1315S 336 component. Visually it looks fine. Would I need to test it with an oscilloscope? How can I tell if it has gone bad? The Reference Clock IC, I am not sure what it is. Is it the Crystal Oscillator (C2KC55MS) for the RTC? What I can not understand is that the clock does keep track of time, it just does not update the Time channel/variable unless on boot (after starting up or after a reset). Therefore I believe not the whole RTC would have failed. And also the System channels/variables for time (ST), also keep unchanged unless on boot, when they do get the values from the RTC. The T value can be changed and keeps its new value registered on the RTC, because on power off/power on it will show the time according to the change. It just does not change while the logger is running "normally". Here are some photos of the DT500 board. Apologies for the bad webcam quality. ![5cba885be1c97](serve/attachment&path=5cba885be1c97) ![5cba885ceee24](serve/attachment&path=5cba885ceee24) ![5cba8869e5f6c](serve/attachment&path=5cba8869e5f6c) Best regards, Renato Casqueira

Hi Renato,

I suspect oscillator failure. Please check U8 for oscillator and comparator chip U3A.

Best regards,
Rudy Gunawan

Hi Renato, I suspect oscillator failure. Please check U8 for oscillator and comparator chip U3A. Best regards, Rudy Gunawan
73
11
3
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft