I have done a search on this and had no hits, so maybe someone can help with this. I am using VB 2005 Express. and the 8055. The card connects OK and I can drive the digital outputs OK. But when I use the debugger I get the following message when I do an OpenDevice call:
A call to PInvoke function ‘UsbCard!UsbCard.form1::OpenDevice’ has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.
I am using the v2 DLL and calling OpenDevice as described, in fact I have used all available int types and the error still occurs.
Although some functions work on the card, I have found articles on MS saying that the stacksize according to the system and the actual stacksize are different and will cause memory faults at some point i.e. at the moment the opendevice call is returning MAXINT (long).
Maybe the problem is in the DLL function calls. Strange that the problem occurs only in debugger.
Here are the DLL function declarations for VB.NET. I think these are OK for VB 2005 Express too. Please note the use of “integer”, “ByVal” and “ByRef”:
Private Declare Function OpenDevice Lib "k8055d.dll" (ByVal CardAddress As Integer) As Integer
Private Declare Sub CloseDevice Lib "k8055d.dll" ()
Private Declare Function ReadAnalogChannel Lib "k8055d.dll" (ByVal Channel As Integer) As Integer
Private Declare Sub ReadAllAnalog Lib "k8055d.dll" (ByRef Data1 As Integer, ByRef Data2 As Integer)
Private Declare Sub OutputAnalogChannel Lib "k8055d.dll" (ByVal Channel As Integer, ByVal Data As Integer)
Private Declare Sub OutputAllAnalog Lib "k8055d.dll" (ByVal Data1 As Integer, ByVal Data2 As Integer)
Private Declare Sub ClearAnalogChannel Lib "k8055d.dll" (ByVal Channel As Integer)
Private Declare Sub SetAllAnalog Lib "k8055d.dll" ()
Private Declare Sub ClearAllAnalog Lib "k8055d.dll" ()
Private Declare Sub SetAnalogChannel Lib "k8055d.dll" (ByVal Channel As Integer)
Private Declare Sub WriteAllDigital Lib "k8055d.dll" (ByVal Data As Integer)
Private Declare Sub ClearDigitalChannel Lib "k8055d.dll" (ByVal Channel As Integer)
Private Declare Sub ClearAllDigital Lib "k8055d.dll" ()
Private Declare Sub SetDigitalChannel Lib "k8055d.dll" (ByVal Channel As Integer)
Private Declare Sub SetAllDigital Lib "k8055d.dll" ()
Private Declare Function ReadDigitalChannel Lib "k8055d.dll" (ByVal Channel As Integer) As Boolean
Private Declare Function ReadAllDigital Lib "k8055d.dll" () As Integer
Private Declare Function ReadCounter Lib "k8055d.dll" (ByVal CounterNr As Integer) As Integer
Private Declare Sub ResetCounter Lib "k8055d.dll" (ByVal CounterNr As Integer)
Private Declare Sub SetCounterDebounceTime Lib "k8055d.dll" (ByVal CounterNr As Integer, ByVal DebounceTime As Integer)
Your definition shows the ints as integer, mine (that came with V2 DLL) has them as long. I have now changed them to int32 (as new longs in VB are 64 bits not 32) and it works fine.
Some more info, in case other users run into the problem:
This means that the type (and size) of one or more parameters is incorrect
Example: The caller pushed 8 bytes onto the stack (64-bit integer), the callee popped only 4 bytes (32-bit integer), hence the stack is out of balance.
This means the caller uses a different calling convention than the callee.
Example: The stdcall calling convention requires the callee to pop the arguments from the stack; if he doesn’t do this and the caller expects him to, the stack will also get out of balance.
In short: Check your data types and calling conventions
Only debugging mode would detect this problem, otherwise you’ll get unexpected behavior, since the stack has been partly overwritten.
I think that if the documentation reflected the possible difference and ramifications of different int types this would help, unfortunately I followed the documentation explicitly, as you should, and tripped up. Maybe if the doc said int32 instead of long then users would know how to apply it to their platform.