Hi Everyone,
I couldn't figure out why my code was behaving strangely, until I finally timed it's behaviour. It turns out that around 0.05% of the time, reading the counter takes longer than 100 milliseconds, and as long as 500 milliseconds. Most of the time it takes just 4 milliseconds.
I'm coding in matlab. A code snippet is below. Is there a faster way to read the counter? For what it's worth, psuedocode for what I'm doing is
while true:
If the counter larger than last time:
set labjack digital pin high
call other functions that display things on a monitor
set labjack pin low
function obj = myLJ()
%Make the UD .NET assembly visible in MATLAB
obj.ljasm = NET.addAssembly('LJUDDotNet');
obj.ljudObj = LabJack.LabJackUD.LJUD;
%Open Labjack
[ljerror, obj.ljhandle] = obj.ljudObj.OpenLabJack(LabJack.LabJackUD.DEVICE.U3, LabJack.LabJackUD.CONNECTION.USB, '0', true, 0);
function config_counter(obj)
obj.ljudObj.AddRequest(obj.ljhandle, LabJack.LabJackUD.IO.PUT_CONFIG, LabJack.LabJackUD.CHANNEL.TIMER_COUNTER_PIN_OFFSET, 4, 0, 0);
obj.ljudObj.AddRequest(obj.ljhandle, LabJack.LabJackUD.IO.PUT_COUNTER_ENABLE, 1, 1, 0, 0);
obj.ljudObj.GoOne(obj.ljhandle);
end
function cnt = read_count(obj)
[er, cnt] = obj.ljudObj.eGet(obj.ljhandle, LabJack.LabJackUD.IO.GET_COUNTER,1,0,0);
end
.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 ran a test with UD 3.47 and U3 firmware 1.46. I made a LabVIEW VI that reads Counter1 in a loop with an eGet call just like you are doing. It also makes an array of the time for each read and at the end displays that sorted array with longest times at the top. I ran the test for 1M (1000000) iterations which took about 10 minutes, and got 1 time of 6 ms (the max), 2 times of 5 ms, 30 times of 3 ms, and the rest at 2 ms or less.
I then repeated the test for 100k iterations (about 1 minute), but this time tried to open and close lots of programs while the test was running. Now my top 5 times were 84, 21, 19, 12, and 12 ms. I then repeated this, but went into the Windows Task Manager and set the priority of the LabVIEW process to realtime. Now my top 5 times were 10, 3, 3, 3, and 3.
So likely your problem is something with your program or computer. It looks like you are trying to do minimum latency feedback. That is, you want to set an output as soon as possible after an input event happens. That is going to require looking at things you can do on your computer to avoid other activity from interfering with your eGet call in Matlab.
One side comment is that you should add a hub between the U3 and your host if you don't already have one. This will usually drop the command-response time to less then 1 ms, whereas a direct connection will sometimes take 4 ms.
I worried that would be the case.
When you say a hub, you just mean a plain old fashioned USB hub? Any details about it I should look for?
Pretty much any hub. A hub that supports USB 3 will likely be the best.