time information and block length mismatch

[M_Kallin]

This seems to be a regular problem.

But I couldn't solve it out of the others cases in the forum.

I get the Error when I try to run the program:
"The time information or block length of the input channels do not match..."

The program complains at my Signal Switch named "Signal Switc" (see pic). I'm using V.11.

The thing is that the problem comes and goes. I tuned the program/system with measurement setup 2000 Hz and block length 1.

All worked fine till I copied the program to a server and then uses the file at another PC, from the server.

Usually I get it to work when I change the block length and then back again. But it's just a quickfix.

I tried to redraw all wires (worked for another file) and replaced modules with new ones.

The control signal is from dasylab blocks and the signals to switch are from a NI USB-6501 .

I use a time delay module to be able to run the parallel flow. So they want collide in time.

Now I got headache... please help

[TomRizzo]

Just to make sure that all the signal are in sync, replace the module with a digital display, and clik on all green lines.  Make sure that all the signals have the same frequency and block size.

Also, the delay module can cause problems some time at experiment start and need some adjusting to make it work.

[CJ_Butler__DASYLab_Pro]

Unfortunately, I can't look at the worksheet without have your tasks from NI MAX.

I believe that it is a concern that you are sampling at 2000 samples/second with a block size of one. We recommend that you use a 10:1 ratio for sample rate to block size. anything larger than that is likely to cause performance problems, data underrun or data overrun, and, possibly, internal timing problems. 

Does the same setup run at 10 samples/second? If it does, start increasing the sample rate until it fails. If not, let us know, and we can dig into it more deeply.

Have you contacted your reseller? 

[M_Kallin]

Thanks for your fast replies.

I will try does tips on monday and come back. 🙂

As you can see I always use the "sync by input" option so they should be synced?

No I haven't contacted the reseller regarding these problems.

I suppose that it wouldn't be a problem to run the files from a server?

Thanks

/Martin

[CJ_Butler__DASYLab_Pro]

What do you mean by running from a server?

If the worksheet files (*.dsb) are on a server file share, then you have no problem. DASYLab loads the file into memory and runs completely in memory. It needs access to the DASYLab folders that are located on your computer for the INI files and to save last.dsb at Measurement start.

DASYLab should NOT be installed on a server and run from a server location. That is not supported, and likely to have problems. It is designed to be installed on a single computer, and relies on resources on that computer, including drivers and other libraries. 

[TomRizzo]

Also, if you are storing data on a server location, it is recomended to make that location available ofline, if not and the are network problem you will loose all the data

[M_Kallin]

Now I have experimented with the program: 
The parameters of Sampling rate and Block size in the Measurement Setup together with the Average filter parameters in my module "Reduction".

To have in mind is that the parameters do affect my measurement with time delays and larger steps of the ramping.

The results are more or less good. I will explain where we are now:

The Error:

When I mixture with the parameters it works more or less good. I even tried a ratio between Block size to Sampling rate of 1:3 but still got the error some times.

Some values works better then others but I couldn't find a mix that always works.
I'm not sure but it seems to work little better when I start it from Full screen display mode.

I guess that the ratio is more important for the green lines before the Signal Switch (than the ratio of Measurement Setup)?

With my earlier tuned parameters (2kHz, 1Block, 40Blocks for average filter) I had Block length 1 and Frequency 50 Hz for all lines in to the Signal Switch.

By a List module I could see that it collected different amount of data before the error appears, but almost always it stops in the beginning (~0,5 to 1,5s from start).

Don't know how you mean I could adjust the delay, but I tried with changing the duration to Block instead of Seconds without success.

There is no debug future in Daisylab?

The function and the problem:

With the program I ramp the current for my hardware, a power supply unit, from 18 - 115 mA.

At the same time I read my digital input from my hardware, a NI USB card.

Together it is a measurement system where time delays will affect the measurement.

I will receive a signal from a predicted port of the digital input, when I receive the signal I stop the ramping signal to the power supply. Then I read the current at the time from the power supply.

The critical time is the between, from I get the input signal till I have stopped the output signal to the power supply.

Of course I also need good resolution of the output (0,0001A / 0,1mA).
That together with the limitations from the system I could tune/optimize the accuracy of the measurement by the slope of the ramp from Generator module "Current Ramp".

(The purpose of the Average filter is only to reduce data and processor time.)

I attach my configurations from NI in two formats. If it could help you to try the program?

[M_Kallin]

Hi

Could a slow computer or a busy CPU affect DASYLab to this problem?

/Martin

[hw70]

The generator module "current ramp" uses the timebase "Driver".

"Driver" timebases configuration is 2000 Hz sample rate, and block size 1.

In your worksheet that's the root of all evil, i think.

Using a block size of 1 needs a sample rate at maximal 100 Hz, or less (less is better).

If you need 2000 hz sample rate, you have to increase the block size.

[M_Kallin]

I tried to configure driver timebase with 100 Hz and block size 1. Also tried lower frequencies than that.

Tried larger block sizes.

But never get rid of the problem.. It's like 50/50 if it works or not.

The average module does increase the chances to run the program without error.

Tried with another computer, but still got the problem.

Could it be better to put some parts into Black Boxes?

Thinking of deleting the program module by module, to see where/when the problem disappear..