Search the Community

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.