Using DLL for connecting and read data from CR95HF and rfid tag

[saleh_hp]

Hi 

I build the LabVIEW code according to AN3954 Application note from ST company for reading data from the tag, but it returns an error, I did it with ST software successfully and I am sure my software is ok. On page 41 it said that if lngStatus become 4 we have communication error with tag. It exactly happens to me.

I attache my code picture, DLL, and AN3954, thanks for your help

[rolfk]

No you do not have communication error with the tag but an invalid parameter.

Your strTagResponse is an empty buffer. The DLL tries to write data into that buffer but since you do not preallocate it, that will of course cause an exception, which the DLL apparently catches and translates into the "helpful" error 4.

First thing: Go into the Call Library Node configuration and then change the Minimum Size value for the strTagResponse parameter to 50 (or higher) as this value is also used in the C sample code in the PDF file for this function.

This should fix the problem.

Second thing: Change the data type for this parameter to be a String, Array Data Pointer too, just as the other parameter. Make sure you leave the Minimum size set to 50. This will make sure that LabVIEW scans the string after the function returns and only returns the section up to the termination NULL character. With a byte array LabVIEW will always return the full 50 bytes and you have to manually scan the array for the NULL character to terminate the string there.

C has specific memory management requirements and as low level programming language requires the programmer to care about every detail of it. The DLL interface is based on the C language capabilities and inherits these requirements. There is no way LabVIEW could know what buffer size the parameters should have. That is for the programmer to define based on documentation for the according function.

[saleh_hp]

Thanks for your quick reply

I modify the format and size but I still get error 4!

One thing I can't understand why we have 2 input and 2 output, maybe it has problem

I attache modified vi

[rolfk]

Which function returns status 4? If it is the first or second, then you obviously have a problem with your software that is beyond anything that LabVIEW can influence. Do you happen to have your ST software still open while you try to run this in LabVIEW? If so that would explain a lot, since a device can not be accessed from more than one application at the same time.

[saleh_hp]

I close ST software always and the third function has error, I attach block diagram and front panel

[saleh_hp]

I read data from tag with one trick, I execute source code exe on ST file and run CR95HFDll_Select for iso 15693 and close the exe file and run labview and it works! but when I use this function on LabVIEW i get an error, and the other issue is that I receive in data strange data but the format according to page 40 is correct, first picture is function without CR95HFDll_Select and the second is with this function on LabVIEW

[rolfk]

You do obviously something different than in your C source file. What that is we can't know, as you prefer to just post a front panel picture. My parapsychological abilities are not further developed than yours, so I can not guess what your C source program looks like, nor see and investigate your VI in which you try to do the same.

[saleh_hp]

I modified my code and add CR95HFDll_Select to my function and it read the tag without error but again I can't read the whole EEPROM of the tag, I can't understand why ST did not mention exactly how can read the user area, or maybe I can't find it in the document.

Another document is CR95HF that I attached to this post and also vi.

Thanks

[rolfk]

First: CR95HFDll_Select also returns a status code that indicates if the call was successful. I would definitely configure the return value of that function as a int32.

Second: It's not that they do not explain anything but it is scattered throughout different locations. This is hardware and you are supposed to be able to figure out a few things on your own. The hardware reference manual is pretty extensive and since it is not a simple 2 bit register device but in fact a whole little microprocessor of its own, also quite complicated with many functions that can be selected and interact with each other, and not all combinations are equally useful or even possible. On this level you can't expect a ready made step by step youtube movie explaining to you how to use this hardware. This is hardware tinkering at its finest and means you need a good basic understanding of the technologies involved. The CR95HF demonstration board is a Hardware Developer Kit demonstration board. It is not meant to use as end user device but as a sample implementation to creating your own hardware and a first step to tinker with the chip while developing your own hardware. Without such tools a hardware designer has basically an extra hard problem by having to design his own hardware AND having to figure out how to control the chip from his design. If it doesn't work, which it always will not do in the beginning when you get your first prototype from the PCB shop, he has no idea if it is because the PCB design has a problem or because the software is addressing the chip not exactly in the right way. Debugging a hardware design under those conditions is frustrating and often very ineffective. With the demonstration board he can try out the configuration steps and basic communication and reimplement it in his own design and be reasonable sure that at least that part is fairly ok. Then he can concentrate on debugging his own hardware.

If you want to use that board as end user product you have basically chosen the wrong product. If you have chosen that board because you want to design your own hardware eventually, then you have obviously still a steep learning curve to tackle.