Just when does data collection start with LJ U3????


Recommended Posts

Trying to get DF express to start data collection at an even 6 minute interval.

CANNOT do a LJ reset here, since counter's MAY contain data I need.

Set all channels' timing to 0 in autostart sequence.

do some stuff to save historical values. either from LJ counter values or History

Check if LJ U3 is in correct mode, by reading a counter channel.

If get D0050 error, set flag in OnAlert seq to reset LJ

delay(10) // OnAlert seq. SLOW to respond

If the LJ reset flag set

do LJ reset to configure it to mode required for counter's etc.

endif

wait until the 6 minute interval

then set channels' timing to what I require.

After all this, I DO NOT GET channel readings on 6 minute intervals.

IF THE LJ U3 RESET has to occur AFTER the 6 minute interval..... Give me some hint of the time required for the reset, IF YOU CAN.

Oh dear.

ek

Link to comment
Share on other sites

If you really want that much control, you shouldn't be using channel timing. Channel timing is really for simpler apps that want to start acquiring data when the app loads, and pretty much do it continuously. The ability to change timing dynamically from script is more for those apps where you want to provide a user interface to allow someone to change timing from a runtime installation.

In your case, I recommend using the labjack commands to do the read directly as described in the DAQFactory-LabJack application guide. You can do a bunch of AddRequests and a single GoOne to get all the reads simultaneously, which is exactly what the channels do when they have the same timing. Then, if you want to use the channels to store the data, do MyChannel.addvalue() for each result.

Link to comment
Share on other sites

This is a simple application (at least in my view), other than I want to have readings occur on a 6 minute interval +_ several seconds.

To have to do the starting sync manually (which I am now doing) is primative.

If I understand your reply, you suggest that I write primatives for all channels, when that is all built into your channels already..... just to get DF to start collecting data at a specific time interval. To me, this is not a simple answer to a simple question.

The "program" as it exists works reliably pretty much continuously.

I'll experiment, and let you know the answer.

ek

Link to comment
Share on other sites

Sure, its simple to us. The problem is that there are 1000's of simple things you can do in data acquisition and if we tried to incorporate them all into the channels, the channel table would be 500 items wide and much more confusing then you simply writing some very basic code that is in the manual.

The very first versions of DAQFactory had little to no scripting and we very quickly found out that no matter what feature we implemented to make it so you didn't need to script, there was another simple thing somebody wanted to do. Scripting is the simplest way to tell a computer exactly what you want to do that gives complete flexibility. In DAQFactory we try and hit the most common things without scripting and then give you the scripting backend for when you need something special, whether simple or not. You may think your needs are pretty standard, but truthfully, in 8 years and 10,000 users or so, you are the first person I've heard that has needed exactly this.

Link to comment
Share on other sites

I take your answer to be, "you don't know, or don't want to share, or don't bug me" :>}.

I guess people don't use assembly language anymore. That's the only place I ever felt I had some control. Windows, forget control, just cross your fingers.

However, to get back to the problem.....

Preliminary results seem to be that the channel's starting times depend on whether they have averaging enabled. Got my grunge machine going and have been futzing stuff.

So far, FOR MY configuration, non-averaged channels fall into one group: Timing starts either from the time DF* is loaded or when the *.Ctl file is loaded (possibly the former). I've been loading the *.ctl fairly soon after loading DF.

The 2nd group is any channel that has averaging enabled (various timings and various # to average ALL ending up with 360 second overall time). This group starts timing either from the Channel.Restart() or LJ reset times. These two functions occur back to back in the current code, so will have to break them with a delay to test.

Maybe other people needed it, but after they read the doc, decided they couldn't do it (which I did, because of the catch-22 of not being able to leave SafeMode, except manually). But I'm stubborn, and have usually found a way, not always elegant. We'll see if it holds true for this problem.

ek

Link to comment
Share on other sites

Nope. The answer is: "do it in script". You cannot predict when the channel timing is exactly going to start. It wasn't designed to be predictable. DAQFactory is very multithreaded, and things happen at different times depending on your system, priorities and many other things. The only way to make things predictable is to do it in script. Its just like sequence auto-start. You can mark 5 sequences as Auto-start, but the only way you can ensure that they start in a particular order is to create one sequence that starts the other 4. In script its quite simple:

private val
private nexttime = floor(systime() / 360) * 360 + 360
while (1)
   waituntil(nexttime)
   AddRequest(0, LJ_ioGET_AIN, 1, 0, 0, 0)
   AddRequest(0, LJ_ioGET_AIN, 2, 0, 0, 0)
   AddRequest(0, LJ_ioGET_AIN, 3, 0, 0, 0)
   GoOne(0)
   GetResult(0, LJ_ioGET_AIN, 1, val)
   chan1.addvalue(inserttime(val,nexttime,0))
   GetResult(0, LJ_ioGET_AIN, 2, val)
   chan2.addvalue(inserttime(val,nexttime,0))
   GetResult(0, LJ_ioGET_AIN, 3, val)   
   chan3.addvalue(inserttime(val,nexttime,0))
   nexttime += 360
endwhile

As for safemode, its not designed to have things start at a particular time. Its designed to largely allow our techs to open customer documents without crashing the system because the hardware doesn't exist. Customers can use it for the same purpose which is why its a public function. We also sometimes use it for samples to put the setup instructions on a base page, and then a user can click on a button to leave safe mode once their hardware is plugged in.

Link to comment
Share on other sites

OK, if I understand this ff would apply to the simple group of channel

**********************
// Sequence 360 sec channels
private val
private nexttime = floor(systime() / 360) * 360 + 360
while (1)
   waituntil(nexttime)
   AddRequest(0, LJ_ioGET_COUNTER, 5, 0, 0, 0)
   AddRequest(0, LJ_ioGET_AIN, 13, 0, 0, 0)
   GoOne(0)
   GetResult(0, LJ_ioGET_COUNTER, 5, val)   // @val ????
   chan5.addvalue(inserttime(val,nexttime,0))
	  BeginSeq(R_count_extern)					   // do processing
   GetResult(0, LJ_ioGET_AIN, 13, val)		  // @val ????
	  // do conversion of val here
   chan13.addvalue(inserttime(val,nexttime,0))
   nexttime += 360

do logging and exporting here as required

endwhile
******************

Then another set of sequences to do averaged channels Group 1, Group 2

*********************************
// Sequence   Average of 60 sec channels
private val0
private val1
private val2
private counts =0
private sum_val0
private sum_val1
private sum_val2

private offset =0.01	 /// assume need a different offset for each group

private nexttime = floor(systime() / 360) * 360 + (360 +offset)
while (1)
   waituntil(nexttime)
   sum_val0 =0
   sum_val1 =0
   sum_val2 =0
   counts =0
	private c_nexttime =floor(systime() /60) *60 +59	// 59, so we don't overflow our 360 sec window
	while(1) 
	  AddRequest(0, LJ_ioGET_AIN, 1, 0, 0, 0)
		  ditto	  next one
		  ditto	  next one
	  GoOne(0)
	  GetResult(0, LJ_ioGET_AIN, 1, val0)		  // @val ????
	  ditto and ditto

	  counts +=counts
	  sum_val0 +=val0
	  ditto and ditto 

	  waituntil(c_nexttime)
	  c_nexttime +=60

	  if (counts >5)
			val0 =sum_val0 /counts
			// ditto and ditto   val1 & 2
			// do conversion of val0 thru 2 here

			//	actual time will be a bit off
		   chan1.addvalue(inserttime(val0,nexttime,0))
		  break							  // break inner while
	  endif
   endwhile
   nexttime += 360

do logging and exporting here as required

endwhile
**************************

Now as to how DF channels should be set.

Assume timing for all should be 0 as well as # Ave and offset.

Assume Channel Names, history, and Persist can remain unchanged.

What about type???

Appears that conversions are N.A. with this method, so I loose ability to log Raw data????

Link to comment
Share on other sites

You should be able to do it with one sequence and let the Channels still do the averaging. Just remember that the averaging is adding up data points, so until you have accumulated the appropriate number of readings, you won't get a value for that channel. If you wanted to average in the sequence for more control, I'd probably do it all in one sequence, both averaged and unaveraged data. That way you are sure to have everything lined up and no conflicts.

Timing should be 0.

Everything else can remain unchanged

Type doesn't matter.

Conversions do not apply. If you want to log raw, you'll need another channel.

Link to comment
Share on other sites

Guru

Group: Administrators

Posts: 1,061

Joined: 27-July 07

Member No.: 63

Am unclear about letting channels do the averaging.

GetResult(0, LJ_ioGET_AIN, 1, val0) // @val ????

would seem to me, to put the Result of the read into val0, rather than into anything relating to a channel

OR

do I do a "channel.addvalue(val0)" immediately after the GetResult(), which would do the conversion and take care of averagings???????

This would mean, leaving # to average alone in the channel definitions.

Since I have two different sets of channel averaging (one 60 sec interval for 6, and the other 15 sec. for 24) I'll have to mull over if the collection of data can all be put into one sequence. I think I see how to put two of them together, but right now stumped on getting all 3 into one seq. Have to think about it.

Required syncrony of channel data is +- a minute or so.

Your comment "Conversions do not apply." Does this mean the channel conversions do not apply, or that I don't have to do the conversions in my sequences??????

ek

Quote from your last reply***************************

You should be able to do it with one sequence and let the Channels still do the averaging. Just remember that the averaging is adding up data points, so until you have accumulated the appropriate number of readings, you won't get a value for that channel. If you wanted to average in the sequence for more control, I'd probably do it all in one sequence, both averaged and unaveraged data. That way you are sure to have everything lined up and no conflicts.

Timing should be 0.

Everything else can remain unchanged

Type doesn't matter.

Conversions do not apply. If you want to log raw, you'll need another channel

******************************** end quote from your last reply

Link to comment
Share on other sites

  • 1 month later...

As far as I can determine the following is what happens with DF Express 5.80 as to data collection timing:

NOTE: Times within about +-10 seconds.

DF*.exe ~load time determines time base for unaveraged channels AT TIME of FINAL Channel.Restart().

~Channel.Restart() time determines time base for averaged channels. (all channels with same timing and number to average).

Setting all channels to average at initial *.ctl load in the channel table does NOT affect the final outcome.

It is the channel average setting at the tme of the FINAL Channel.Restart.

Averaged channels set at 60 sec interval, average of 6 (total time 360 seconds)

Unaveraged channels set at 360 sec interval.

Link to comment
Share on other sites

As far as I can determine.

DF does NOT set channel to type AD ???? Haven't fully investigated this

With all channels set to timing 0

Averaged channels left with average of 6

If the you do

addRequest(0, LJ_ioGet_AIN, 0,0,0,0)

and

GetResult(0, LJ_ioGet_aIN, 0, @val) // NOTE @ your code did not have

YOU MUST DO SUMMATION, and CONVERSION in the code for averaged channels

For unaveraged, YOU MUST DO CONVERSION.

Only 3 days to figure this out.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.