I experience this situation from time to time and there is no documented solution when the DT is operating in a remote monitoring situation.
What is the best and definitive way to prepare the DT to deal with this situation itself if it eventuates?
I want to avoid a hard reset though. That is problematic. Is there a "soft reset" option possible.

Hi ,

Can you please email dataTaker support service log from the logger where you had this issue?

We will try finding the reason for this cause and will let you know if there is any workaround.

Thanks
Regards
Lokesh

Thanks Lokesh.

I will come at this subject from another angle please Lokesh.
My question was not about attempting to identify any particular problem or fault find the logger, but rather a general question on moving our remote monitoring system using DT80M closer to mission critical on an "operational basis".

So the question I would like you to address please is not the reasons the DT80M might have hung [this can happen so we can all agree on that as a starting point] but importantly how I can set up to "recover" from a hang remotely and in an unattended operating environment.
This means that I need to set something up [probably mechanically via relay] that will be invoked in event of a hung logger. Once again I stress "the system is remote" with no human intervention possible.

You must have experienced this situation.
Have you any ideas please Lokesh and a hard reset is not what I want. Dropping the supply to logger can have unpredictable consequences and of course the first point that comes mind is some potential problems are possible with time and date issues on reboot.
What about a soft reset Lokesh? Can a pin be pulled to ground via relay that will maintain supply but reset the logger?

Lawrence

Hello flowtech,

I am having same problem in one of my DTs, you can check my post. I have also though in adding some kind of mechanical solution, i.e. the logger detects a hung -> set DSO 1 -> read DSI 1 -> reset/init/whatever. But I have not identified yet any variable capable of doing that.

Best regards.

Hello Contek.

Well you can forget your idea of setting some variable or I/O control Contek in the event of a "hung logger" because as soon as the logger "hangs" all activity [schedules; controls, etc cease to function]. That is the key characteristic of a "hung" logger. All CPU activity ceases.

Your solution can only then be one outside of the logger, but with the capability to "reset" the logger.

So your question really is: What are all of the the ways and methods available to "reset" the Datataker including both hard and soft methods?
Hope this helps you clarify the situation regarding "hung" devices in general Contek.

Lawrence

Hello flowtech,

As you can read in my post, I have had 2 kinds of hungs (only in one out of two DTs, the other is working perfectly with no hungs, however, it is assumable that it may happen for some reason as any electronic device).
The first one the comms were completely hung (both internet and Egarding system variables or digital I/O as mentioned before.
The second type of hung involves the whole system as you state.

For the first type, I have not found any programmable solution or mechanical either, as it seems the DT is totally unable to detect its comms are hung.

For the second type, the one you are discussing in here, one possible solution (assuming that you have one DSO free) would be to build a simple digital system outside the DT. This system would accomplish several Boolean states, controlled by a DSO running in the job. For instance, you could set a DSO=1 from the beginning of the job so that if it hungs and the DSO==0 (this would work assuming that, if the DT hungs it would reset its outputs but not tried yet) the external digital system would cut off and restore the DT power thus the system would reset (at the moment, resetting is the only way to restore the system I guess).

Anyway, I find this discussion very interesting as if we manage to find a solution it will be very useful for on field systems.
Regards.

Hi Contek and Lawrence,

dataTaker may crashed (hung) because software exception. It covers a wide area of causes, so determining a solution for one problem may not solve another.
You will need to send me service data report from those loggers to determine the cause of error:

• some errors come from the older version of firmware when you did specific things (i.e.: a complex calculation when waking from sleep), on this problem we have made some changes to the new version of firmware
• others may caused by multiple failure of rapid MODBUS/ SDI12 reading which filling up processor buffer, when the buffer is overloaded crash is inevitable, on this problem we can find solution to prevent reading failure.

There are many more that caused the logger to crash, more complex your program more tendency to have an error in your code which also lead into crash.

Second problem is related to Ethernet lock up, some related to internal setting while other related on how fast or how often you make a connection to the logger.
dataTaker has around 25 sockets, without any access from outside all of these socket will stay at listening mode.
When dEX is being accessed, your web browser may use up to 3 sockets at once, naturally these sockets will stay on waiting mode during this access.
If dataTaker does not detect any communication on these waiting sockets, they will be closed.

However things may not get well if you do multiple open close of your web browser or just refresh the page. The number of used sockets will increase and all of them are in waiting mode.
Because opening new sockets happens faster than closing them, at some point all sockets will be used and the logger will lock up itself.

Adding a conditional statement to reset the logger is one of the workaround, but it does not solve the root of cause.

For detailed solution, you may send an email about your problem in detail to dataTaker support email.

Best regards,
Rudy Gunawan

In my case, it hangs when nobody is accessing the DEX while other times it hangs suddenly while accessing DEX. I will send you the log file but there is nothing strange on it (no error logs, changes...)
By the way, I have programmed part of my config with the DEX config interface and the rest in my job. Now I get an annoying message everytime I log in DEX saying "Config found but it is not the actual config..." Is there anyway to remove this message?
best regards.

Hi Contek,

There is a workaround to remove the message.
If you copy paste your program as dEX configuration in Manual Channel, you will get a CONFIG job and no more dEX message "Config found....".
However you must be very careful with native schedule declaration against dEX schedule declaration.

Best regards,
Rudy Gunawan