Peculiar Persist File

[trevorhurd]

The Installation. Windows Vista.

I have four devices operating from four channels.

WaterFlow01

TankLevel01

ValveOpen01

ValvePos01

WaterFlow01 in on it's own data line being a MODBUS DigiRail 4C pulse counter counting from a pulse output water meter.

TankLevel01 and ValvePos01 are 4-20ma inputs into DigiRail 2A. They provide information of the water tank level and the position of a water valve that feeds the tank.

ValveOpen01 is a 0-10V signal out to the water valve to activate it into the required position and is controlled via a Brainchild MBIO-8VIS MODBUS unit.

The Fault.

The program crashed when the TankLevel01 sensor went faulty.

Having changed the TankLevel01 sensor the program still crashed when ever I tried to run it.

After a lot of experimenting I found that if I destroyed the Persist file and took out the timing for TankLevel01. (I.E. set at 0) The program would run and create a new Persist file.

If I then introduce the timing for TankLevel01. The program will crash.

If I then try to run the program without the TankLevel01 timing. The program will crash.

If I then delete the TankLevel01.data from the Persist file. The program will run.

If I then reintroduce the timing for the TankLevel01 sensor. The program will crash. Add infinitum.

I hope you are getting the picture.

If I now change the name of the TankLevel01 sensor from TankLevel01 to TankLevel01new.

The program will run.

Having now determined this I have found a way round. But, and it's a big BUT.

A. It is going to take me some time to go through all the sequences, graphs and tables etc.

B. Is there any guarantee that this will not happen again?

I have checked the PC processor speed and memory etc. and it's not even breaking a sweat.

Any advice would be appreciated.

Regards,

Trevor Hurd

[AzeoTech]

So the if you have a persist file named TankLevel01 the program will crash? It sounds like disk corruption. What I'd do get it to crash again, then instead of deleting the TankLevel01 persist file, rename it to "corrupt" or something. Then restart DAQFactory and it should create a new persist file and should work ok.

Simply deleting the persist file frees up the corrupted part of the disk for another file and its possible that when DAQFactory recreates the file, its simply recreating it on top of that same corrupted sector. By renaming the file, you've made it so no other file can use that corrupt sector.

[trevorhurd]

There could be some accuracy in what you are saying.

However, I feel that there is still something strange going on.

I visited the site today and put the timing in for the TankLevel01. The program crashed.

I renamed the Persist file as PersistA. The program ran OK.

Now here is what I can't understand.

I disconnect the 4-20 ma coming from the sensor at the MODBUS unit. The program crashes.

I restart the program. It crashes.

I rename the Persist file PersistB. The program runs OK.

I reconnect the 4-20 ma signal from the sensor.The program crashes.

Add infinitum.

Carried on until I reached PersistJ.

I tried the same routine with WaterFlow01 and ValvePos01 without any problems.

I swapped the MODBUS unit (Novus Digirail A). Same thing happens.

None of it makes sense to me.

[AzeoTech]

OK, try this (starting from a document that works):

1) turn of the persist (set the persist value to 0) and see if it works

2) rename your channel and get it to start reading (set timing to non-zero). Apply your signal. Does it work?

3) if not, change the Channel # of that channel to some other value and set the timing to 0, create another channel that matches what the original sensor channel # was with the same name.

My guess now is that it has nothing to do with persist, but is actually script you have elsewhere. If #1 fixes it, then we'll go back to the persist file as the culprit, if not, then that's not the issue. If #2 works, then more than likely you have script somewhere that is referencing the channel and doing something (infinite loop? blown stack?) when the value is in a reasonable realm (i.e. sensor connectored) that crashes DAQFactory. If #3 works, then the script is likely in the Event of the original channel.