ibconfig unsupported feature for ENET

[schudon]

Greetings NI fans,

I recently purchased the ENET/GPIB adaptor and I am having some odd timeout errors.  The avenue I am pursuing right now involves using ibconfig.  From the canned panel interface there is an option to enable/disable blocking on Lockout- exactly what I believe my real problem to be.  The panel interface says that IbcBlockIfLocked is only available for ENET which is fine -that's what I am using.  However when I call it; it returns ECAP (unsupported feature).  I have tried passing in the GPIB descriptor both as 0 and as a handle returned from ibdev- same result ECAP.  

If I still have your interest my real problem is I am running a multithreaded application and I am trying to share an expensive piece of instrumentation between two test bays.  I am attempting to accomplish this using the ENET/GPIB adaptor.  In order for me to do this I have written various practice programs to lock out the GPIB and have another application wait for it to unlock and  visa versa (two different PC's running the same SW) locking each other out and waiting for the other to unlock.  I have now integrated this approach into my multithreaded application (I am ok with different threads accessing the device, but I cannot have different Apps horning in on the instrument- hence my lockout and wait approach).  My belief is that now that I have integrated this approach into my multithreaded application it is inadvertently locking out the GPIB instrument from other threads in the same application.  I have not yet started to debug two different multithreaded applications.  One of the steps I have taken- the ENET/GPIB adaptor works fine in the multithreaded App without any of my iblock commands.  I am also trying to eliminate the other threads that might want to use the instrument but multithreaded SW is difficult to debug and I inherited it and didn't write it.

Any thoughts?  My factories are waiting for this solution.

Thanks,

-don

[Song_M]

Hey schudon!

I looked up two articles regarding iblock that might be of interest to you.  Please tell me if these help!

http://digital.ni.com/public.nsf/websearch/78b4fe652de1f9c18625682d006ceaa7?OpenDocument 

http://digital.ni.com/public.nsf/allkb/D22E1D17748DA98E8625659C0062ADDD?OpenDocument

 
Thanks and have a great weekend schudon!

[schudon]

Boy is my face red- all of my problems were related to iblock returning a non-zero error message.  How long have I been doing this?

Thanks for the help.

Actually I had checked out the first link and used that to structure my code and thats how I made it this far.

[Song_M]

Hey schudon, at least the cubbies are doing good right? So you can't be too mad 🙂  Now, quick question, does everything work fine if you use one pc and run the software in parallel?

[schudon]

Hi Song_M,

I had it "working" today with two parallel PC's however from the time my wait for unlock routine gave the OK to the waiting process; the other process could occasionally sneak in and take it back- resulting in an error.  I am now experimenting with the Visa Locks and UnLocks.  Not trivial but there are hooks for timeouts that I think can get me around these types of collisions.

BTW 

Thanks to your Houston (I am assuming you are in Texas) Astros- the Cubs just got swept at home Is this the beginning of the September slide?

I will keep you posted on the Visa approach- wish I would have started with that.

Thanks,

-don

[Song_M]

Hey schudon tell me how the Visa unlocks/locks work out!

[schudon]

I am still having collisions on my Lock/Un-Lock approach.  The Visa approach did not work as well as hoped but I did discover the GPIB tools intended for other compilers.  In my standalone experimental program using ni488.h, gpib-32.obj, and iblck; it was working nicely.  Unfortunately I cannot integrate gpib-32.obj into my real application because I have a lot more GPIB calls using the standard CVI/NI tools and I cannot get gpib-32.obj to link into my project properly. 

I really like using iblck because of the timeout feature that is not available in iblock.  But when I observe the GPIB activity using NI Spy I see that iblck is still being called - see capture from NI Spy below.  What I would like to know now is- is there a way that I can call iblck with timeouts (not set to zero as seen below)?  Obviously at some level CVI is still calling it when I call ibunlock but I can't get iblck to compile or link into my project. 

Or should I spend more time trying to get the Visa tools to work?

Thanks,

-don

> 17000.  ibunlock(1)
> Process ID: 0x00000264         Thread ID: 0x00000A9C
> Start Time: 11:30:26.593       Call Duration 00:00:00.000
> ibsta: 0x8000       iberr: 21             ibcntl: 0(0x0)

> 17001.  iblck(1, 0, 0, NULL)
> Process ID: 0x00000264         Thread ID: 0x00000A9C
> Start Time: 11:30:26.593       Call Duration 00:00:00.000
> ibsta: 0x8000       iberr: 21             ibcntl: 0(0x0)

[Song_M]

Hey schudon

I dug up some information regarding iblck that could help you!  The iblck function will allow a given GPIB session to lock a given GPIB interface board so that other attempted sessions or currently open sessions are locked from accessing the GPIB interface board. This behavior is preserved across the network for interfaces such as the GPIB ENET\100. The fundamental reason for this behavior being preserved across the network is that iblck is a board level command, affecting the interface board and all current and future attempted sessions open to it for the duration of the lock. For example, if computer A establishes a lock using iblck, then even if communication has already been established by computer B (over the network or otherwise), computer B will be locked out until the lock is released. The following is the iblck function prototype and a brief description of the function's behavior; see the NI-4882 Help for more information (with NI-488.2 installed: Start -> Programs -> National Instruments -> NI-488.2 -> NI-488.2 Help):

Prototype:
int iblck (int ud, int v, unsigned int LockWaitTime, void * Reserved)

Parameters:
ud: unit descriptor

v: lock parameter (1 or 0); if v is 1, the driver attempts to acquire an exclusive lock on the interface for the current process. The call fails with ELCK (that is, the call returns with ERR set in ibsta and iberr set to ELCK) if the lock could not be acquired within the timeout period specified by LockWaitTime. If v is 0, a lock previously acquired by the current process is released. Only the process that acquired an interface lock can release a lock. If v is zero, and no lock exists for the process, the call fails with ELCK. LockWaitTime is ignored when using iblck to release interface locks.

LockWaitTime: the period of time to wait, if necessary, to obtain the lock

Reserved: this parameter is reserved for future use; it must be NULL