A somewhat strange behavior for cronpakbusnew

Archive Weather Display Problems
1

I have a Campbell Scientific 3000 running since about Sept 2020. I’m not sure if any (many?) people use this, but the device is very flexible and I can hook different sensors to it.

It has been my most dependable system. Initially I had troubles with Windows 10 booting after and update and while WD would start, Cronpakbusnew would start and either quit in 2 seconds, or just sit there with the display area on the bottom blank. If I started it manually, the window would indicate a connection, and then show a new line of data every second. It would run months unless a Win10 update got through.

I was running WD version 135, stable for several months. then I began to have trouble with cronpackbusnew not getting new data from the CS3000. The panel on the bottom was just blank, and the WD was displaying the frozen data. Restart usually fixed things well.

Now I have had WD continue to run, but after variable periods of time, it will quit. I don’t have any other applications running on this computer. I updated to version 140 recently, and now I notice a previously unseen behavior on the cronpackbusnew.

After I get it started and running, the display screen on the bottom with show an update every second, then show a blank screen for two cycles (two seconds) then show two more updates, one per second, then two seconds of blank again. When there is a valid output stream, those data are reflected properly on the WD screen.

I’ve looked at the cpu load and it is low, along with all sorts of memory in reserve, 16 gigs total. The task manager windows show nothing maxed out, so there seems to be little OS overhead that I wondered if the system were busy handling other tasks, but there seems to be plenty of capacity, and this same computer ran for months without a problem.

Does anyone have a thought as to why the cronpakbusnew is not retrieving data each second as it used to? I have rebooted the CR3000 several times to no avail. I’ve not added nor changed sensors, and am running that system with a CampSci Short Cut created compilation with the latest version from them.

Any hints or thoughts? This system had been my favorite one, with great stability so I must have changed something, or one of the Windows updates made changes, but I cannot figure out what.
Thanks Dale

2

Hi Dale,

Sorry to hear your cronpakbusnew seems to not run properly.
Mine is running flawless with the CS CR1000.
Did you check the connect screen in CS and choose the public data table which is updating every second OK?
To rule out the source is updating wrong/the fault is on the source side/Datalogger side.

With the kindest regards.

This is how i have set it up in WD:



3

Well, first of all I think I’ve stopped blushing.

In a nutshell, the problem was caused after a very brief power outage.

I have two computers running cronpakbusnew, one the regular computer that is my most reliable, and another which is a test or fiddle around computer.

Both were able to run things perfectly, after I got done adjusting. On the test computer I stopped that process, and let the regular computer run, busily and faithfully getting the data table from the Campbell Scientific C3000 every second.

After the power hiccough and both computers rebooted, the test one had been used to also trial a 45 second delayed start of WD with the first start attaching to an RMYoung 28600, and the second start, delayed, attaching to the Campbell Scientific. It came on, powered up and after the delay started.

Now I had two cronpakbusnew programs trying to get a data table from the C3000, and eventually there would be some collision, which accounted for two out of four failures, and eventually it seemed to have enough collisions that it just stopped.

It was entirely my fault and I was scratching my head as to what settings or such I may have changed, when it was another computer trying to access the C3000 simultaneously. I now have removed the second delayed start and all is fine.

I am not sure if the C3000 is fast enough to service two different inquiries at the same time, but I am anticipating since I do a time synch on both computers four times a day, that their request for accessing the table might occur so close together that the collision is encountered, whereas if the one computer was off a 1/2 second or so, it might be able to grab that data table and have enough time to wait for the other request.

For now I don’t care, and just have to remember to take the ‘test’ computer out of the system when I’m done playing.

I doubt many will find this of help, but it may, and it just shows how very odd things can creep into causing a problem when all else looks OK.