U3 LJ_ioGet_DIGITAL_BIT_STATE syntax | LabJack


8 posts / 0 new
Last post

I want to read the "current" state of EIO0-EIO2 when it has already been set to a digital output, and at present is either high or low.

I'm assuming it would be something like an addrequest or eget in the form of ... LJ_ioGet_DIGITAL_BIT_STATE, 9, %dblValue for one pin. (i.e. EIO0).

Would someone please help!

LabJack is a great product, I've used them for years.. The one complaint I do have is the documention/pseudocode examples sux. i.e. I can not find anything on the BIT_STATE or PORT_STATE.

Thanks for your time,


LabJack Support
labjack support's picture
The information you are

The information you are looking for is at the beginning of this page:


The listing of ioTypes notes which ones also set direction, so you don't want to use those.  The paragraph right after that listing talks more about this topic.  Here it is:

The general bit and port IOTypes automatically control direction, but the _DIR and _STATE ones do not. These can be used to read the current condition of digital I/O without changing the current condition. Note that the _STATE reads are actually doing a read using the input circuitry, not reading the state value last written. When you use LJ_ioGET_DIGITAL_BIT_STATE or LJ_ioGET_DIGITAL_PORT_STATE on a line set to output, it leaves it set as output, but it is doing an actual state read based on the voltage(s) on the pin(s). So if you set a line to output-high, but then something external is driving it low, it might read low.


Yes..... I read that... But

Yes..... I read that... But that is NOT what I asked.  I asked about the LJ_ioGET_DIGITAL_BIT_STATE "syntax..." So I could read the state of EIO0-EIO2. But never mind, after hours of reading, re-reading and searching it is this....

"AddRequest (lngHandle, LJ_ioGET_DIGITAL_BIT_STATE, 8, 0, 0, 0)" than channel 9, then 10...

Please show me where in section 4.3.5 is describes, explains or shows which of the AddRequest's six parameters are used in the LJ_ioGET_DIGITAL_BIT_STATE digital io type???

Thanks for your time,

LabJack Support
labjack support's picture
Yes, the paragraph I quoted

Yes, the paragraph I quoted is pointing out that the _STATE registers do not change direction.  As for syntax, that is a general UD topic.  Syntax is usually not specific to the IOType, and indeed with LJ_ioGET_DIGITAL_BIT_STATE it has normal syntax.  Here is what I would say for syntax, and we will add this to the downloads page for each programming language:


The first step is to understand a general overview of the UD library:


The UD driver just has a handful of functions, and those all have the same 4-6 parameters.  Those parameters are described at the bottom of the Overview page.  Usually the meaning of each parameter should be apparent (e.g. Channel is the channel number you are operating on), but when it is not the pseudocode section should have any extra information that is needed.

Handle:  Always the handle.
IOType:  Always the IOType.
Channel:  If something besides a channel number the pseudocode section will tell you.
Value:  Always the value.
X1:  Usually not used, but if used the pseudocode section will tell you.
UserData:  Usually not used, but if used the pseudocode section will tell you.

So next you go to the pseudocode section:


The IOType LJ_ioGET_DIGITAL_BIT_STATE is listed at the beginning, and does not have any special comments.  The fact that it does not have any special comments tells you:

Channel is the channel you want to read.
Value is the value you will read.
X1 is not used.
UserData is not used.


OK, "Usually not used, but if

OK, "Usually not used, but if used the pseudocode section will tell you." I think LabJack is "assuming" a lot about what a reader will comprehend when reading through the manuals, which have changed a lot over time.

I.E. the BIT_STATE doesn't use the x1 but the PORT_STATE does.

When I tried to use the PORT_STATE, the GetFirstResule/GetNextResult balked at the x1 parameter. Although, this is what the manual,  (4.3.5 just before the pserdocode) says to use.

All this "normal" because it is not "specially commented" on, (meaning to disregard the 5 & 6 parameters) and "unable to convert 'long' to 'long' compile errors, when using the 5th parameter.... Can be confusing and frustrating...

Would you know why the GetFirstResult/GetNext would have a problem with the x1 parameter? throwing ''can't convert 'long' to 'long''' compile error in C? (btw, I used a pointer to a long varible in the x1 parameter,  a long varible, and a simple "3". Nothing worked.


Thanks for all your time,

LabJack Support
labjack support's picture
There is certainly room for

There is certainly room for improvement.  I'd say there is 1 key reminder/hint that could be in more places.  Maybe the following key hint should be on every pseudocode page, along with a link that points you to the info I posted last time if someone is not sure about syntax.

    X1 & UserData:  If used for a particular IOType, the pseudocode section will tell you.

I would add that LJM (for the T4 and T7) is our 3rd generation library with 3rd generation documentation, so is improved in our opinion.  UD is not as active as LJM, but is still active so we do continue to make improvements to documentation.


Sometimes casting can be tricky with the x1 parameter because it is used in different ways.  I'll mark this for someone else to follow up, but I do see that the U3simple.cpp example in the VC6_LJUD archive uses some IOTypes that use x1.



LabJack Support
labjack support's picture

GetFirstResult/GetNextResult are documented here:


The px1 parameter in those functions are a pointer (long *px1). Pass a long variable by reference when using DIGITAL IOTypes.

    long lngIOType = 0;
    long lngChannel = 0;   
    double dblValue = 0;
    long lngX1 = 0;
    double dblUserData = 0;
    GetFirstResult(lngHandle, &lngIOType, &lngChannel, &dblValue, &lngX1, &dblUserData);

Alternatively you can also pass 0 to that parameter if you want to ignore its result:

    GetFirstResult(lngHandle, &lngIOType, &lngChannel, &dblValue, 0, 0);

Thank you, it will now

Thank you, it will now compile.

Thanks for all your time,