After downgrading our firmware to 9.10.4890 per Datataker tech support recommendation our DT85 (series 3) is going through resets about every four days causing the loss of data during the reset.

In the event log the reset error is "Reset 9.10.4890 PLL/WDOG/DEBUG (c860400d)".

Currently we have two schedules running; one 15 sec and one 1 min. In the 15 sec. we read 12 analog and 4 modbus channels.
In the 1 minute schedule we read 189 modbus, 127 analog, and 7 serial values. There are arithmetic calculations done with about half of these values. Would the amount of tasks we are asking the logger to do be a source of the reset issue?

Additional info: BPS: 19200, FTP download frequency 4x/day.

If the solution is to download firmware version 9.16, please briefly describe how this fixes the issue we are encountering.

Any assistance would greatly appreciated.

Hi mtseitzler,

That error message indicates the logger run out listening socket and reset itself, this is part of watchdog feature.
You may disable watchdog feature by using PROFILE HTTP_SERVER ENABLE_WDG=NO

When you said, FTP download frequency is 4 x/ day, are you transferring data from dataTaker out via FTP transfer or accessing DT FTP server to download the data?
Upgrading to 9.16 gives will not solve the problem, 9.16 will gives you a new dEX interface.

Best regards,
Rudy Gunawan

Summary of the error is:
EVENT ,2014/11/05,05:47:31,0.753662,"No HTTP listener running: restarting"
EVENT ,2014/11/05,05:47:34,0.929077,"Reset 9.10.4890 PLL/WDOG/DEBUG (c860400d)"
EVENT ,2014/11/05,05:53:43,0.795532,"Beginning entry of job "HONDV23""
EVENT ,2014/11/05,05:53:53,0.562744,"HTTP Listener monitor started"
EVENT ,2014/11/05,05:53:57,0.735107,"Loaded job "HONDV23""

Does you solution regarding the watchdog parameter change still hold given the errors above?

Thanks.

Hi mtseitzler,

HTTP Listener is a watchdog which used to monitor TCP sockets usage. When all of the sockets are used, no more connection can be attempted, thus dataTaker use hard reset to clear up TCP sockets.

One of the issue that we have is related to socket release, somehow the socket ID get corrupted thus cannot be released. If watchdog is not used, there is nothing to monitor socket usage thus no more connection to the logger.

Best regards,
Rudy Gunawan

Hi Rudy,
So now we are not able to access the logger after disabling the watchdog.

Can you elaborate on what: "Please check any possible problem from all devices attempting to access dataTaker" means, i.e. what item should be checked that would cause the errors?

Thanks,
Matt

Hi Matt,

When external device gains an access to dEX, its web browser will used up to 3 sockets at once (depending to browser type).
If the network (assuming wireless network) is unstable then that web browser may increase the number of sockets for connection.
Same thing happen if the logger is being accessed by many PC and at the same time there is a rapid opening and closing the browser.
In that condition more sockets will be used and they will stay at waiting mode (waiting for incoming data).

Naturally sockets will be freed if no transaction takes place (i.e.: connection terminated), however if opening sockets happen faster than closing them or there is corrupt socket ID so it can't be released, dataTaker will run out of socket.

If watchdog active the logger will reset, but if the watchdog is disable you will not be able to gain access to the logger.

Sometimes when all the sockets are used, the Ethernet connection will be locked.
Could you explain to me how often do you access the logger? How many PCs in total?

Best regards,
Rudy Gunawan

Hi Rudy,
Currently we have one "PC" that is writing to our system every 15 seconds and every minute. It is using Modbus over TCP/IP and we have been receiving errors as follows:

Modbus RX <HOST: 02 10027f00020442c70000076a0210029700020442ba2e148533 (26)
INVALID RX MSG (calc CRC=d783)

Is this error related to the HTTP Listener error we are experiencing? It appears that this line of code is actually tow Modbus messages combined.

The subcontractor providing this information is going to buffer the Modbus to prevent this stacking in the future.

Thanks!
Matt

Hi Matt,

That message indicates CRC check error (sensor gives incorrect CRC code) detected by dataTaker.
It has nothing to do with HTTP listener because MODBUS reading use port 543 while most of problem (that related to Ethernet lock up) comes from port 80.

Could you email me your dataTaker service log?
Please email it to dataTaker support email.

Best regards,
Rudy Gunawan

Rudy,
Below is an excerpt from the latest DT85 event log.

EVENT ,2014/11/12,10:28:39,0.509887,"Beginning entry of job "HONDAV25""
EVENT ,2014/11/12,10:29:38,0.071899,"Created job "HONDAV25""
EVENT ,2014/11/13,00:47:33,0.553344,"Peripheral prepared to hard reset"
EVENT ,2014/11/13,00:47:35,0.902099,"No user accounts has been configured yet"
EVENT ,2014/11/13,00:47:35,0.965209,"Permissions controller started"
EVENT ,2014/11/13,00:47:37,0.022094,"Reset 9.16.5728 EXCEPTION (c8610007)"
EVENT ,2014/11/13,00:53:47,0.233520,"Beginning entry of job "HONDAV25""
EVENT ,2014/11/13,00:53:57,0.011108,"HTTP Listener monitor started"
EVENT ,2014/11/13,00:54:00,0.342285,"Loaded job "HONDAV25""
EVENT ,2014/11/13,08:14:27,0.903198,"Peripheral prepared to hard reset"
EVENT ,2014/11/13,08:14:30,0.245605,"No user accounts has been configured yet"
EVENT ,2014/11/13,08:14:30,0.308471,"Permissions controller started"
EVENT ,2014/11/13,08:14:31,0.276367,"Reset 9.16.5728 EXCEPTION (c8610007)"
EVENT ,2014/11/13,08:20:41,0.603759,"Beginning entry of job "HONDAV25""
EVENT ,2014/11/13,08:20:51,0.323364,"HTTP Listener monitor started"
EVENT ,2014/11/13,08:20:54,0.587280,"Loaded job "HONDAV25""
EVENT ,2014/11/15,06:36:53,0.580688,"Peripheral prepared to hard reset"
EVENT ,2014/11/15,06:36:55,0.921386,"No user accounts has been configured yet"
EVENT ,2014/11/15,06:36:55,0.985473,"Permissions controller started"
EVENT ,2014/11/15,06:36:56,0.971923,"Reset 9.16.5728 EXCEPTION (c8610007)"
EVENT ,2014/11/15,06:43:07,0.031738,"Beginning entry of job "HONDAV25""
EVENT ,2014/11/15,06:43:16,0.816406,"HTTP Listener monitor started"
EVENT ,2014/11/15,06:43:20,0.089233,"Loaded job "HONDAV25"

Please advise on what you think is occurring at this point.

Thanks,
Matt

Hi Gents,

did you manage to resolve your problem? We have a DT85 setup with pretty much similar number of modbus and analogue inputs, and calculations. The logger stops working after a few hours of operation. It stops logging and we cannot establish any connection to the interface via Ethernet or USB. It just sits there doing nothing until its reset (power off and back on).

Hi mpb,

It is possible FTP operation and logging happened at the same time and clogged the processor as FTP will try to read from database while logging will try to write to database.
Specially if it is involving a large number of data.

Could you try to halt one schedule while running the other and vice versa? or perhaps the FTP can be triggered at the end of reading schedule (with timely condition).

Best regards,
Rudy Gunawan

We have a similar issue with the logger stopping to respond to be read through Modbus TCP/IP.

The setup we are using a DT85 connected to 16 CEM channels – a total of 400 HV I/O (we are reading 4-20mA pressures transmitters over a 250Ohm resistor).
Product DT85-3 SN: 105590 / Firmware: 9.18.6291 – self diagnostic all pass
Event log shows:
EVENT ,2018/08/21,11:36:36,0.279174,"Beginning entry of job "SWEC""
EVENT ,2018/08/21,11:37:30,0.913330,"Created job "SWEC""
EVENT ,2018/09/05,08:13:27,0.045654,"Peripheral prepared to hard reset"
EVENT ,2018/09/05,08:13:30,0.354858,"Reset 9.18.6291 EXCEPTION (c8610007)"
EVENT ,2018/09/05,08:13:30,0.695312,"Beginning entry of job "SWEC""
EVENT ,2018/09/05,08:13:37,0.752075,"Loaded job "SWEC""
EVENT ,2018/09/17,18:18:22,0.707397,"Peripheral prepared to hard reset"
EVENT ,2018/09/17,18:18:26,0.079467,"Reset 9.18.6291 EXCEPTION (c8610007)"
EVENT ,2018/09/17,18:18:26,0.460449,"Beginning entry of job "SWEC""
EVENT ,2018/09/17,18:18:33,0.665405,"Loaded job "SWEC""

Job SWEC has 4 schedules SWEC_A; SWEC_B; SWEC_C and SWEC_D
No issues with logging
A sample schedules looks like this: 5Minute schedule
Begin “SWEC”
S2=0,10000,1000,5000
RC"SWEC_F14A"("b:",ALARMS:OV:100KB:W60,DATA:OV:25MB)5M
901V("PI-1414B-105_P1~PSI",=300CV,LM,S2,A,GL30V)
901+V("PI-1414B-106_P1~PSI",=301CV,LM,S2,A,GL30V)
And another 100 lines like this and the next schedule
RD"SWEC_F14B"("b:",ALARMS:OV:100KB:W60,DATA:OV:25MB)5M
1301V("PI-1414B-205_P5~PSI",=400CV,LM,S2,A,GL30V)
1301+V("PI-1414B-206_P5~PSI",=401CV,LM,S2,A,GL30V)
….
LOGONA
LOGONB
LOGONC
LOGOND
END

Error report show tehf ollosing error:
2018/09/17,18:18:26

An error occurred at ppp_interface.c:493
Task: timerThread

Current task : timerThread
Error location : 0002655C
Exception 200 at 0x000f1800
SRR1=00009032 DSISR=00000809 DAR=00000000 BAR=00000000 MSTAT=00000080
LR=000eb6b0 CR=24000022 CTR=00000048 XER=20000000
R00:07 0000002a 0415f718 00142da0 0013be5f 00000005 00000043 00000035 00000035
R08:15 00000036 00000000 041cfd90 f00d4321 00000000 040612ac 53535353 53535353
R16:23 53535353 53535353 53535353 53535353 53535353 53535353 53535353 53535353
R24:31 53535353 53535353 53535353 04060000 000527a4 04060000 04063d10 0415e1f0
Call stack: 0002655c 00095468 00093b10 000927c8 00063ab4 000ecb48 000ecadc ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

Behavior:
The system works great for 1 to 2 days than all of the sudden it stops communicating to the modbus master which reads the CV value about every 2 sec
Going to the data taker the IP address and everything is still there – once it resets it works again for about 1-2 days till it hangs back up.
please provide asstance - I also send an email to support and hope to get a response.

most sincerely christian Ondrusek

Hi mtseitzler and austriacus,

Can you enable network diagnostic (P56=32) from command windows and retrieve PCAP files for me?
PCAP files are located within DIAG folder, you can retrieve them using FTP access. Please make sure to disable network diagnostic (P56-0) after the test.

Best regards,
Rudy Gunawan