I’m using the latest DLL version (k8055dll_rev3_0_2).
When I close the K8055D.DLL and then reopen it - all this without disconnecting the interface from the USB port - some things don’t seem to work right.
If I try to clear a digital channel that was previously set, nothing happens and the function returns as failed.
If I try to clear all digital channels at once, it works with no problems.
If I set a single digital channel, all the others become automatically cleared - and the same situation for the analog outputs.
Now in a different scenario, keeping the same DLL instance: I set a digital channel. Now when I clear that digital channel twice, it fails the second time. Shouldn’t it always return something that doesn’t create doubt?
Can we explain these behaviors? Are there ways of avoiding them?
Thanks again for your time and blessed patience.
Regards,
footswitch
Strange indeed!
According to the documentation the function SetDigitalChannel(long Channel) shouldn’t return anything.
Only these functions are returning a value:
FUNCTION long __stdcall OpenDevice(long CardAddress);
FUNCTION long __stdcall ReadAnalogChannel(long Channel);
FUNCTION bool __stdcall ReadDigitalChannel(long Channel);
FUNCTION long __stdcall ReadAllDigital();
FUNCTION long __stdcall ReadCounter(long CounterNr);
FUNCTION long __stdcall SearchDevices();
FUNCTION long __stdcall SetCurrentDevice(long lngCardAddress);
Return values for most functions aren’t documented, but they’re there if you adapt the function calls to return a long integer.
I guess I know where this is going. “If they’re not documented, they’re not supported.”
But they’re very useful. But yes, of course I’ll live without the return value of ClearDigitalChannel.
The only thing that really bothers me right now is the behavior of the board when responding to the function calls in certain conditions.
The scenario is:
Open the DLL
Open the device connection
Call some functions like SetDigitalChannel(4)
Close the device connection and the DLL, but do not remove it from the USB port
Open the DLL and device connection again
SetDigitalChannel(6) will set digital output 6 as expected, BUT it will clear digital output 4 (and any other digital outputs that would be set in the previous connection)!
My question is, is there a way of avoiding this behavior at all?
How can I keep the ins and outs of the board unchanged when opening a new thread?
According to your observations there seems to be some undocumented return values - interesting!
About the DLL close/reopen:
There is no readback feature in the DLL to get the status of the K8055 card. The DLL just remembers the status as long as “alive”. If you close it and then reopen the state of the card is unknown.
It seems that the only way to keep track of the status of the card is to store it in your application software - if possible.
Depending on the project, I might as well call both ClearAllAnalog and ClearAllDigital immediately after opening connection to the interface, in order to reset it, or assign one of the digital outputs to control every other, and maybe connecting it to an input as well.
When developing something new, we often think about adapting it to the user, but sometimes it’s the user that needs to adapt to the utility
By the way, those undocumented return values are mostly ‘1’ for success and ‘0’ for failure. In some cases, ‘0’ for success and ‘-1’ for failure. In those I just add 1 to the return, in order to get standard return values.
Again, in almost all of them, ‘failure’ means that the interface either isn’t connected or hasn’t been called to open first.
