05-07-2008 11:34 AM
05-07-2008 11:23 PM
Dear Hillary,
With the help of champions like mikeS81, smercurio, GerdW, rolfk i managed to finish up my work.
see this link for all the necessites.
Thanks,
Mathan
05-22-2008 06:42 AM
10-27-2008 02:53 AM - edited 10-27-2008 02:58 AM
mathan wrote:
Dear Champions,
In my application, everything is fine.
1) sCardEstablishContext works fine
2) sCardListReadersA showing correct name of my reader
3) sCardConnectA give proper mode(1) and protocol(1) values
4) sCardStatusA ???????????? There is the problem. It gives state(6 - reset) and protocol(1). That is correct i think. But ATRLEN is 0 and no ATR was received and most of the times labview crashes when the data comes to scardstatus(when i run in highlight execution).
I attached my vi and dll in zip format.
Please do the needful asap
Thanks,
Mathan
When interfacing to DLLs using the Call Library Node, standard C memory manager rules apply. And here it is usually the rule that the caller allocates the buffers where the called function fills in information. In C you don't have a memory manager like in LabVIEW that handles all buffer allocations, reallocations and dispositions on the fly in the background but you have to take care yourself that those buffers are allocated at the right time, in the right way and with the right size. And LabVIEW can't help you much here since this information is not at all available in the DLL but only sometiems in the documentation to the DLL, and often it is simply smart deduction by the programmer since the original programmer thought this would be something obvious, which it on;y is if you are a seasoned C programmer
But software is simply not able to do smart deduction on its own from information that is not clearly available.
So you have actually several problems in your VI already.
1)You shouldn't just pass in an emtpy string to SCardListReadersA. Instead allocate an array of Bytes with sufficient length as required by the function (the maximum amount that the DLL will fill in should be documented in the associated documentation for this function). You can allocate an array of bytes in LabVIEW using the Initialize Array function node. Use U8 as datatype and the required length as length input. You can either configure the function parameter in the Call Library Node (CLN) to be an array of U8 passed as C array pointer and convert the array to a string after the CLN or you configure the parameter to be a C string pointer and do the conversion before the CLN. The second variant has the advantage that on return from the CLN LabVIEW will automatically scan the string for the terminating NUL character and only return the string up to this point.
To the last parameter you should probably pass the actually allocated buffer length.
Without this, this function call will cause crashes already sooner or later. It could be during the function call, during some seemingly unrelated function call later on or at LabVIEW shutdown. It could also seem to work fine for a long time only to suddenly crash when youbuild the application into an executable or when changing some completely unrelated parts of your VI that make LabVIEw recompile the VI and place the data structures differently into memory.
2) The call to SCardStatusA has a similar problem with the buffer to the 6th parameter. The function is supposed to return some information in that buffer and can only do so if it gets handed a valid buffer. Here it seems to first check the value of the 7th parameter to see if the buffer size is long enough and since you don't wire up anything there it sees 0, which is correct since you haven't wired an array to the previous parameter either and also decides correctly that it does not have a big enough buffer to return its information.
Instead you have to allocate an array of bytes using the Initialize Array function node again. The necessary size should again be documented in the documentation to this function. Then you also pass the length of that array to the last parameter. Et voilá it should not only not cause any error anymore but it also should not crash.
Remains the challange to actually get out the right information from thebyte array, but that is an interesting exercise in interfacing DLLs from LabVIEW in itself.
Rolf Kalbermatter
03-31-2009 06:04 AM
Dear Rolf,
Am back into this project after a long time.
Sorry for the late reply. I have modified everything as per your suggestion and the vi works like a charm. Thanks a lot for all the nice suggestions.
Also as a next step, i have to transmit some commands and receive the corresponding output from the reader. For that i have to use scardtransmit function from winscard.dll. I find difficulties in scardiorequest structure. Could you please help me out in assigning alll the parameters in scardtransmit function. Thanks for your time.
Thanks a lot,
Mathan
03-31-2009 10:50 AM
mathan wrote:Dear Rolf,
Am back into this project after a long time.
Sorry for the late reply. I have modified everything as per your suggestion and the vi works like a charm. Thanks a lot for all the nice suggestions.
Also as a next step, i have to transmit some commands and receive the corresponding output from the reader. For that i have to use scardtransmit function from winscard.dll. I find difficulties in scardiorequest structure. Could you please help me out in assigning alll the parameters in scardtransmit function. Thanks for your time.
Thanks a lot,
Mathan
Sorry Scard is totally uncharted territory for me. For the principal things the same applies as with the previous APIs.
Rolf Kalbermatter
08-02-2013 07:44 AM
Finally i managed to get implement the scard transmit function. Posting it here for future reference.
Mathan
08-23-2014 03:37 AM
Dear All,
I want to read sle 5542 card, can someone please help me how to read(write) it? Thank you!
http://hashtips.wordpress.com/tag/sle5542/
B/R
Ancle