Why replay history data from NI-DAQ buffer?

[Jim_S]

Hello Steve,

I was reading over this discussion forum and you stated that your customer is running this application on a Win XP machine with the following setting: Turn off monitor NEVER, turn off hard disk NEVER, and system standby NEVER. In XP, you can allow the computer to turn off the USB port to conserve power. In bottom of this link, it describes where this setting is located. Is this turned on?

I agree that it is strange that it is repeating the last 100 seconds. If these settings are set correctly, we could try upgrading the driver to see if this problem persists. Along with this, we would need to try to reproduce this on another machine. Have you been able to reproduce this problem on another machine? Can the customer test this code on a different machine to see if this still persists?

[CoastalMaineBird]

Can the customer test this code on a different machine to see if this still persists?

--- It has happened several times on each of several different machines.

Have you been able to reproduce this problem on another machine?

--- Me, I have not been able to reproduce it.

I will check out the turn-off-USB feature and see if it's set to turn off or not.

[CoastalMaineBird]

New information:

Six separate test cells, each with host computer, PXI chassis, cDAQ chassis.

All six are running NI-DAQmx 8.9.0f4.  All have shown the issue in the past.

The PUT-USB-TO-SLEEP option was ON on all cells.  It was turned OFF on three of them last week. All devices were similarly set to NOT go to sleep.

The TIME-BETWEEN-SAMPLES display was NOT effective - people woke the machines without paying attention to it.

One of these cells had SCREENSAVER set to NONE, but it has still showed this issue.

Of SIX cells over the last weekend, FIVE showed the issue on Monday morning.  The other one was actually used for tests on Saturday and Sunday, so it wasn't idle as long.

The machine without a screen saver was closely observed Monday morning:

1...The mouse had been parked on the main screen, not the TCM screen. (TCM is the program which exhibits this problem - it runs on a separate monitor attached to the host computer).  It can run on a separate machine, but in this case it's not.

As far as we know it was not disturbed from Friday afternoon til Monday morning.

That eliminates the possibility of the mouse oscillating between cells and flooding the program with MOUSE ENTER events.

2... The TCM screen was "frozen", i.e. not changing values.  With 45+ channels active, a few should normally be bouncing around a bit. Not so.

3... The rapid display updates did NOT occur until the user CLICKED on the TCM screen, which opened the floodgates.

4... From that click, until the display settled down and acted normally, was a period of approximately 18 minutes.

------

If there was a backlog of 1000 samples, it would seem that they could be disposed of in WAY less time than 1080 seconds (18 min).  Even given that real data started coming in at 10 Hz, that's only one backlog sample per second being processed.  I know the program is capable of better operation than that.

Not sure what any of this means...