Hello,
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:
https://github.com/labjack/LabJackPython/blob/master/src/u3.py
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')
break
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).
-matt
.png%3Fitok=PHGBxf6M "EEV Blog Reviews LabJack T7-Pro & Software Tools")
.jpg%3Fitok=B1YcuDFK)
.png%3Fitok=Ybt-OlgU "LabJack + JEDI One Can Create a Powerful Distributed DAQ Ecosystem")
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:
https://github.com/labjack/LabJackPython/blob/master/src/u3.py#L1163