Check U3 status within python loop | LabJack

Check U3 status within python loop

2 posts / 0 new
Last post
mdbudde's picture
Check U3 status within python loop


I'm using the U3 counter feature within a python loop to check for events on a connected TTL line, based on the source example:

import time
import u3
d = u3.U3()
d.configIO(EnableCounter0 = True, FIOAnalog = 15)

bitState = 0
while 1:
    bitState = d.getFeedback(u3.Counter0( Reset = True ) )

    #if statement to do something when bitState > 0
    time.sleep(0.001) #in s

This works quite nicely.  Occasionally, it fails to detect events, which I haven't debugged completely, but restarting the script returns functionality.  I suspect a check for status within the loop may help without having to restart the script to reconnect. I didn't see a specific function to check whether the device is still operating or communicating. 
Is another call to configIO a proper way to do that? For example:

while 1:
    CounterConfig = d.configIO(EnableCounter0 = True, FIOAnalog = 15)
    ec0 = CounterConfig['EnableCounter0']
    if (ec0 == False):
        print('Counter0 not enabled, exiting capture loop')

    bitState = d.getFeedback(u3.Counter0( Reset = False ) )
    time.sleep(0.001) #in s

Finally, if the device does seem to get disconnected, is the proper way to restablish communication within the loop a reset:

U3.reset(hardReset = False)
d = u3.U3()
d.configIO(EnableCounter0 = True, FIOAnalog = 15)

or some other solution.

thanks for the help (and for all the great tools and documentation).

LabJack Support
labjack support's picture
I would not expect the issue

I would not expect the issue is a disconnection. If the device connection is disrupted you should see some exception from the feedback commands. If not handled, an exception should stop the program.

By "fails to detect events" do you just mean that you are not triggering the conditional as often as you expect?

I would not expect that you would lose edges seen by the U3 even under a temporary disconnection unless there is some hardware setup issue.

One thing that could be happening is you are receiving an edge or edges while still handling your triggered condition, and the counter reset is essentially hiding the extra edges. A test you could try is to keep an accumulator variable that tracks the total number of edges read from the counter over your runtime.

You could set up the watchdog to reset the device in the case of disconnection: