## Recommended Posts

stumped again trying to read my channel, wait 60 seconds, read the value again and then add math to it...

trying to find feet per minute...

i have scaled my value to read feet, but getting it to read it, wait, then read again and divide/multiply has my brain crunching!

it should be simple math, correct?

forcing myself to read the whole users guide and im pretty sure it has something to do with the delay() or wait() statements....

any info would be awesome....

thanks!

##### Share on other sites

Why wouldn't you just use a channel, set the Timing to 60, and then use a Conversion to scale the value?

##### Share on other sites

dunno...i'll give it a whirl...

##### Share on other sites

So would the conversion be something like:

10 * (Value[0] - Value[1]) ?

##### Share on other sites

No actually, you can't use [] notation on "Value". That would require DAQFactory to keep a history of unconverted values as well as converted values which would be a huge memory hog.

I didn't realize you wanted to do math on two readings from the same channel. The process follows how you should deal with counters when trying to determine number of pulses per second. In this case you do not want to reset the LabJack counter, but instead let DAQFactory calculate the difference between consecutive readings. This is because resetting the counter can result in missed counts. Here are the directions for doing that, which are pulled from a soon to be released complete LabJack / DAQFactory user's guide, and hopefully you can adapt it to your application. I included the whole section just in case:

1) Create a channel to read the counter. Call it RawCounts or similar. This will be Device Type LabJack of course, D# = LabJack ID, I/O type of Counter, Channel # = desired counter or 0 on devices with only one counter. Set the Timing to whatever your desired interval is. For counts per second, put 1.00.

2) Create a second channel that will hold your counts per interval. Call it Counts for now. This channel will be Device Type Test, D# = 0, I/O Type = A to D, Channel # = 0, and most importantly, Timing = 0. Click apply to save your new channels.

3) Click on the + next the CHANNELS: in the workspace, then click on the RawCounts channel. When the channel view appears, click on the Event tab. Enter the following script:

4) Click Apply. At this point, provided RawCounts is actually getting increasing counts, the Counts channel will have the interval counts. You can click on the Table tab to see this.

The problem with the above method is that it doesn't account for counter roll over. On a 32 bit counter this happens at just over 4 billion counts, so before worrying about this, you might want to figure out how long it would take to accumulate that many counts and see if its worth worrying about. Remember that if you reset the counter at startup, you only have to worry about the amount of time DAQFactory is continuously running. If rollover does occur, all you will see is a negative interval counts measurement. You can post-calc the correct measurement by simply adding 4294967296 to this negative number. That is 2 raised to the 32 power.

But, if you don't want negative counts on rollover, you just have to change the Event from step 3 slightly:

if (RawCounts[0] > RawCounts[1])

else

endif

Of course if you have a 16 bit counter, you'll need to change the 32 to 16 so it adds 65536 instead.

Hertz measurements:

Finally, if instead of actual counts in an interval, you want a hertz measurement (counts per second), we just change the AddValue() lines to divide by the difference in time:

if (RawCounts[0] > RawCounts[1])

Counts.AddValue((RawCounts[0] - RawCounts[1]) / (RawCounts.Time[0] - RawCounts.Time[1]))

else

Counts.AddValue((RawCounts[0] - RawCounts[1] + 2^32) / (RawCounts.Time[0] - RawCounts.Time[1]))

endif

The nice part about this is that if DAQFactory gets delayed a few milliseconds before doing the read, the hertz measurement will be properly normalized.

##### Share on other sites

i tried your initial reply, but somehow it shows up as a solid 50, dont know where that came from...

anyway, i think it's going to be a little different since we dont use counters...everything i am scaling/using math on is a very small analog voltage and the ft/min aspect is calculated by a very "old school" pressure transducer that is gravity/water fed and is set on a 96min clock, but still 60min is the mutliplier, and how ever many minutes it takes from point a to point b is the divider....

i.e. - the pressure transducer shows the pipe went down 5ft in 4 mins.... 5*60 = 300 then 300/4 = 75ft/min

i have it to where i can see the bristol pin movement in DF and it is scaled properly and reads the height of the moving "kelly" in feet...

the tricky part is i don't need ft/min all the time, just when it gets to a certain point then starts to calculate...the certain point is the actual size of pipe measured, say 31.27 feet....the kelly will raise the pipe, then start to push in....so when it gets to 31.27, i need it to start ft/min...then it starts all over again with a new pipe size....

the goal i am looking for is just the ft/min aspect...the whole adding a certain pipe size then starting to calc is secondary...i'll try out that hertz over time measurement....

thanks again, your information is priceless.

##### Share on other sites

I'm a bit lost as to what you want. The counter sample was just that, a sample, that you should be able to extrapolate out your needs from. The concepts for performing something with every channel value, calculating a value relative to another value on the same channel, and storing a calculation in another channel are all there. I think you just need some if statements to handle the pipe changes. If you want to determine delta-T as well, just use:

mychannel.time[0] - mychannel.time[1]

This is in seconds.