Delaying ALL activity in DFExpress for LabJack U3

[ekanderson]

I want to delay ALL data collection from a LJ U3 without doing a U3 reset until SysTime is a certain value

As far as I can determine, I'm in a Catch22 situation WITHOUT doing a LJ reset.

Starting DFexpress (even with a waituntil in AutoStart seq.) immediately starts LJ data acquisition. Thought about having a sequence do System.SafeMode =1, but the way I read the doc on that, it will stop the sequence you are running, thus never being able to leave safe mode from within the seq.

The reason that I don't want to do the LJ reset, as I've mentioned, is that I want to retain 2 of the counter's values.

Checked DF help for stop, start, etc. Nothing seems applicable.

LJ help only has "Stop" in data streaming section, which I am not doing.

Also thought about starting a startup *.ctl and have it load the data collection *.ctl, but as far as I could determine, that isn't possible.

It isn't clear (too me) whether DF could chain/shell to a DOS *.bat file such as

DaqFactoryExpress.exe mydata.ctl

The way I read the shell doc, it creates a concurrent process and what I need would be and exit and restart of DF.

[AzeoTech]

Hmm, well you might be able to use ShellExecute() as you described, and then just do system.quit() to quit the first instance.

However, if you want to have acquisition not start on document load you either need to not use Channels at all and poll from a sequence, or set the Channel timings to 0, and then in your script change them to whatever value you want and do channel.restart() at the time you want acquisition to start.

[ekanderson]

Finally got spare machine setup with spare LJ.

minimum channel timing is 6 seconds to maximum of 360 seconds for a count channel. Some with averaging, others with none. Total "duration" (seconds X # to average) for all channels evaluates to 360 seconds

ran pseudo code

start time =floor etc systime +360

while systime <start time

channel.restart()

delay(5)

endwhile

All channels collected data.

From the results it appears that channel.restart() doesn't restart under my conditions. Doc is not clear, but would assume the channel has to be "dirty", i.e., have a parameter changed since last *.restart for above to work.

I'll attempt the same approach with a LJ reset call instead of "channel.restart()" and see what happens.

If that doesn't work, I'll try your brute force method, which should work.

ek

[ekanderson]

I am about at my wits end here.

It appears that channel.restart(), immediately restarts ALL channels, whether any param was changed or not.

AND any code in a channel's event window is executed IMMEDIATELY after channel.restart whether its time to do so or not.

AZEOTECH AND/OR LABJACK should implement as an option, a way to NOT start a $%^Y%(*&) thing until told to WITHIN a autostart sequence. I've been fighting this off and on for a week, and am still not there.

The only way I've been able to get a good start at 6minute +- several seconds intervals is to watch computer clock and CPU activity and double click the *.ctl file at about 4 +- 3 seconds before the 6 minute interval.

That's on the fast machine. On the slow machine, haven't had much luck getting within 5 seconds.

Loading the file in safe mode and leaving safe mode on a time interval is a laugh. Channels way out of sync.

Side note:

DF ERROR C1000 evidently also applies to accessing an undeclare variable!, Add "Channel, VARIABLE, or function not found" to msg.

??????? WHAT does DFExpress do IMMEDIATELY upon loading a *.ctl file that access a LJ U3??????

Things it hasn't done.

1. Does not do a LJ reset

2. Does not clear LJ counters

Things it probably does.

1 . Resets LJ long settling to false

I think I've vented my spleen for now.

[AzeoTech]

DAQFactory is designed to be easy to use. But anything that is easy to use cannot have a lot of flexibility, otherwise it becomes complex and less easy to use. We provide channels, conversions, logging sets and the like to make it easy to use and offer some flexibility in these, but we cannot possibly cover every thing that everyone wants without making 100's of properties pages, which would then be confusing and no longer easy to use.

So, we offer scripting, which, as 60 years of computer history has shown, is the most flexible way to tell a computer what you want to do (despite what the guys at NI might say ). In DAQFactory we give you a choice, and most people progress down the choices:

1) use just channels, logging sets, etc.: easiest to do, most things are automatic (i.e. data acquisition starts as soon as the doc loads, labjack settings are done automatically), but you don't have a lot of flexibility, like starting acquisition at the 6 minute mark

2) use channels, logging sets with a little scripting: not as easy, but gives you a little more flexibility to do things like automated control, some event processing (setting an output based on an input), etc.

3) use pretty much all scripting. This gives total flexibility and in your case is the option you should be using. You could still use channels to store the data using the AddValue() function, and even logging sets, but you CANNOT use channel Timing to achieve your goal. The use of channel Timing falls into #1 and is not flexible enough for your particular app.

So, just drop the channel timing and do all your queries through script, including the labjack setup. Then, with a single auto-start sequence, you can control when everything happens. Once you let go of trying to use channel Timing, I think you'll find that the solution in scripting is actually quite simple.

[ekanderson]

"I think you'll find that the solution in scripting is actually quite simple"

"...simple.", assumes an intimate knowledge of the program/application/or whatever they are calling them now-a-days, and access to good and complete documentation. To add "quite" to the "simple", hurts.

I've always had trouble with C (since Small-C, in the 80's) and it's derivitives, but have managed, in most cases. But the last time I felt that I had any control over a computer was in the 90's with DOS, AMOS, and CP/M, i.e., pre-Windows. :>(

Like any data collection project, this one has progressed thru

1. Hardware evaluation (Done, and was most easily done with DF logging)

2. Software evaluation (DF appeared reliable under Hardware eval. conditions).

3. Data collection (again DF logging, but transition to other means in progress)

4. Quality control (so far under control) :>)

5. Reliability (transitional. Trying to go from what is working medium well using Export sets [and logging

Sets for historical capatibility]. to something that works as I want it to work and does it reliably).

6. Software modification, and loop back to Quality Control.

7. Data presentation (transitional into either Export sets or a system totally dependent on sequences).

I will probably muddle thru.

Thanks for the help.

[AzeoTech]

DAQFactory syntax models C a little, but its not C and doesn't have the pitfalls of C such as pointers and the ability to put 100 statements on a single line. Most of the script required to read the labjack through script instead of channels is in the DAQFactory - LabJack application guide, which is why I said it should be quite simple. You then only need a line of script, which I believe you already have, to delay the loop until the 6 minute point. Feel free to post if you have questions about the script.