Labjack T7 Reconnect - Reset Open/close - Streaming

[MrDeathStar]

We are using ethernet cabled LabJack T7 devices (channels and streaming) and found that the device identifier (IP address in my case) seems to associate with some internal handle used to initially open the device with that identifier.  If there is a short network error (or remote T7 power failure) and reconnection fails, LabJack reports LJME_RECONNECT_FAILED.  However, at this point DF can no longer reconnect to the device.  I cannot find a way to reopen the device using the same IP identifier, since it remains associated with the now non-working handle.  I must close/reopen my .ctl file.

 

If I setup my own extern methods to call into the LabJackM library, I can use 'LJM_Open' to obtain a new handle and even call other helpful methods such as 'LJM_eReadAddresses' as needed.  If I receive a connection error, I can close / reopen the device and obtain a new handle.  However, streaming methods in the library seems to require special support which I may not be able to create myself with this extern method (and DAQFactory already has nice methods for this, as in the LJM_Stream example).

 

Is there some way to reset any DAQFactory mapping between 'identifier' and its internal LJM_Open handle?  Or, is there some way to force close/reopen of the device again?  I tried Channel.Reset(), and creating a new Channel, but it did not work (and certainly not for LJM_eWriteName methods).  Once such a device error occurs, DAQFactory seems to attempt using the same handle for the given identifier.  You can duplicate the problem by setting up an extern method to manually call LJM_Close on DF's handle (or LJM_CloseAll).  While not totally fair to DF, it does show that once the driver handle goes bad, DF cannot reconnect to the device using the same device identifier (e.g. IP address).  Since it's possible that a wireless T7 may experience such troubles, it would be important to have a reconnection after failure procedure that does not require rebooting the DF application.

 

Thanks for your comments.

[LabJackSupport]

Hello,

 

I can't comment on DAQFactory's ability to close and re-open, but LJM should reconnect to devices after a reasonable amount of time. However, the current version of LJM and/or T7 firmware may have problems reconnecting quickly. We will look into this to make sure the reconnection time is minimal. I will update this thread.

 

Best regards,

Rory & LabJack

[AzeoTech]

DAQFactory pretty much leaves everything up to the LJM driver from LabJack.  That way LabJack can make improvements and add features and they'll automatically be enabled in DAQFactory without customers having to also update DAQFactory.  It gets a handle when it opens the device and then continues to use that handle.

[MrDeathStar]

Yes, I too think it's great how DAQFactory acts as a pass through for most devices because it does allow companies to improve their drivers independently.

 

"It gets a handle when it opens the device and then continues to use that handle." - This was my finding, and yet it would be appreciated if that handle could be reinitialized or closed (i.e. some scriptable way to ask DF to close a device identifier/handle or open it again).  Currently when a device identifier (i.e. IP address) is set in Channels, DF will open the 'new' device.  But returning to a previously used identifier just recycles the old handle which may have been closed.  (Even LabJack drivers can close all handles via someones call to CloseAll, so it would be nice to have a recovery procedure for such situations.)  Maybe Restart() with a parameter having the device identifier that needs recycling, or some other flag to indicate to DF that its handle is invalid and will require re-open when next used.

 

For now I can reopen a device with the same identifier using my own extern methods into the LabJack driver...but I lose DF T7 streaming capability since those methods rely on the invalid original handle.

[AzeoTech]

Probably a good idea and pretty easy to expose, so we've done that change.  Email us for the link, or if you've worked with us before on beta features (which I believe you have), you'll find the update in the same place.  We added LJM_Close(id).  Pass the id like any of the other functions and if it exists, it will call the LJM version of LJM_Close() on the associated handle, and then remove the handle from our map of ids->handles.  It will remove the handle even if LJM_Close fails.  The function returns 0 if successfully closed, 1 if we didn't find the id in our map, and throws an error if the LJM version of LJM_Close() returns an error.

[MrDeathStar]

Wow...thank you very much, I'll give 2222 a try over the weekend as we can really use it!  (FYI: if no parameters are given (stupid me) to LJM_Close() it reports "improper number of parameters in eReadName: Line 1"...not 'in LJM_Close'.)

 

And hey, thanks for all the time spent in forums responding to various issues and 'features' I bump into during development.  I always appreciate your kind comments, workarounds, solutions, and explanations.  To me, a key strength of DAQFactory is scripting, and that is the reason we chose your package for our needs.  But, I do feel like a pest sometimes reporting rough edges I find here and there in the forum...maybe there is another 'bugzilla' like place for that?  In any case, much appreciation extended to you and your developers.

 

Regarding 'beta features', I know you probably can't comment on future releases, but I was just curious if there is a basic release plan/interval with DAQFactory.  We have only been a customer since April.  The latest release 5.87c was last December, and 5.91/2203 last October was only RC.  But we have needed beta 2215 for graph reasons (and now probably 2222 for this LabJack T7 issue.)  It's not really an issue since beta is working well for us, but as product features can change, it's nice to be aligned with official releases.