U3 counter0 error | LabJack

U3 counter0 error

8 posts / 0 new
Last post
U3 counter0 error

I'm trying to read counter0 on a U3. But I continually get an error code 7 back instead of the counter value. I left the timer clock at the default, so that shouldn't be stopping counter0 from working (I also tried setting the timer mode to 2). I need to be able to use both counters. I'm confused.

I have made a discovery.  The

I have made a discovery.  The "power" routine (used extensively in u3.c) doesn't work when compiled with gcc.  Gosh knows what it does, but it's definitely WRONG.  I changed that (just made it a left shift, because it's only called to do power of 2), and I think things may now be better.


LabJack Support
LabJack Support's picture
For clarification, what is

For clarification, what is the "power" routine you mention?

What functions from u3.h/c are you using that were not working before your modification? eTCConfig and eTCValues? What configuration are you using with them?

This is right out of the top

This is right out of the top of u3.c.  Obviously I added the "error handling," but the commented out line is what was there originally.// modified to only powers of 2 - didn't work
int power (int iItem, int iPower) {
    if (iItem != 2) {
        printf ("power of %d doesn't work\n", iItem);
    return (0x01 << iPower);
//  return (iItem ^ iPower);

Yes, eTCConfig, and eTCValues were how I found the problem.  But there are lots of other routines in u3.c that use power, and I didn't test any of the others.  Where I specifically saw it was:

        if( i + TCPinOffset < 8 )
            FIOAnalog = FIOAnalog - power(2, i + TCPinOffset);
            EIOAnalog = EIOAnalog - power(2, (i + TCPinOffset - 8));

Where FIOAnalog (and I presume EIOAnalog) was getting seriously screwed up.

Does that help?

There is also a minor bug in eTCConfig:

//    if( TCPinOffset < 0 && TCPinOffset > 8 )        RGB
    if( TCPinOffset < 0 || TCPinOffset > 8 )

The commented out line is unlikely ever to be true!  But all it's doing is telling you there's an error.



LabJack Support
LabJack Support's picture
Thanks for pointing out the

Thanks for pointing out the code.

I checked the code calculating FIOAnalog and EIOAnalog with pow, and it functions as expected when compiled with GCC/G++. It is calculating which FIO and EIO lines need to be digital I/O (bit = 0) for the timer/counter lines.

    if( TCPinOffset < 0 && TCPinOffset > 8 )

The above check you pointed out is a bug. I'll correct that soon as it should be using an "or" instead of "and".

As for error code 7, that can occur if you are trying to use a timer or counter with eTCValues, but it wasn't enabled/configured with eTCConfig.

You and I must have different

You and I must have different u3.c versions.  "My" routine is power, not pow.  And I found the problem because ehfeedback wasn't returning as many bytes as I was expecting, because it was instead returning an error.  When I tracked that down I got, eventually, to the problem.  Whether that was resulting in the error code 7 I know not.  I had a bunch of routines I was working on, and I think it was an eAIN call that had me find the problem.

LabJack Support
LabJack Support's picture
The code that I am checking

The code that I am checking and refering to is from the u3.c from the Exodriver source on GitHub, which uses the pow function from math.h. I also checked the eAIN usage of pow and their calculations are correct.

Note with the Feedback command-response that if there is an error code in the response, the response size can be smaller than expected causing the "ehFeedback error : did not read all of the expected buffer" message. Only response data before the errored IOType is returned, as documented here for the ErrorFrame byte:


Thanks for all the work you

Thanks for all the work you're putting ing!  My u3.c was from an exodrive-master.zip, which I downloaded from somewhere on 7/26/18.  And yes, it was the ehFeedback error message that (finally) led me to figure out what the heck was going on.  Anyway, all is good now. :-)