I'm seeing strange results with blocks of AddRequest, GoOne, and GetResult. I'm seeing that GetResult sometimes outputs values that are from previous blocks of Add/Go/Get. If I stop my debugger and step my application back up to retry the Get again, I can get the desired output.
Here's some code to show you what I'm trying to do:
// Configure timer mode
AddRequest(handle, LJ_ioPUT_TIMER_MODE, channel, mode, 0, 0);
// request confirmation
AddRequest(handle, LJ_ioGET_TIMER_MODE, channel, 0, 0, 0);
// send these to the device
GoOne(handle);
// get the results
GetResult(handle, LJ_ioGET_TIMER_MODE, channel, &data);
That GetResult is what is failing on the first attempt. I realize that the list is built by the AddRequest. But when I do a GetResult with the ioType and the channel number, doesn't that pull that specific result out of the list for me? Or do I need to do all GetResults in order?
Is there a way to flush all results from the list?
.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")
Upon a deeper review of my entire library I'm building, I don't see any Add/Go/Get blocks that are malformed. They all have the correct order.
Also, I read in Section 2.8 that:
So by that, I should be safe, yet I'm often seeing Get results from the previous Add.
Some of my lib functions do multiple Adds followed by a single Go and then at least one Get (some multiple GetResult). I'm not bothering with GetFirst or GetNext. Is that a problem?
This is due to the order that types of requests are handled in the driver. In a list of requests, LJ_ioGET_TIMER_MODE operations are performed before LJ_ioPUT_TIMER_MODE operations, regardless of list order. This is causing the "previous" mode reading in your case since it is the mode before the new timer mode was set.
Instead, make sure you set the timer mode in one list of requests, and afterwards in a different list of requests or with eGet read the mode. As you pointed out, after a Go/GoOne, subsequent AddRequests will clear previous requests and results.
To detail more, the timer mode on the U3 can only be set and cannot be read directly from the device. The timer mode is stored locally in the driver from the last known configuration (last LJ_ioPUT_TIMER_MODE setting). Local settings requests, such as LJ_ioGET_TIMER_MODE, have no device communications and are performed before most other types of requests like LJ_ioPUT_TIMER_MODE (Feedback command-response) in a list of requests.
Thanks, that explains what I'm seeing. All fixed now.