LabVIEW
Receiving pointer by reference from DLL
Solved!
From the PDF:
sr_i2c_read_arr
Read a array of bytes from the I2C interface
SR_FUNC int sr_i2c_read_arr(SR_HANDLE srh, int port, unsigned char i2c_addr, unsigned char *arr, unsigned short cnt)
Parameters:
srh Handle to connection
port I2C module to query
i2c_addr Address of target device
arr A byte pointer where to store readed array
cnt Number if bytes to read
Return:
0 on failure. Non zero on success
Remarks:
I2C address is shifted 1 bit left: A6(MSB) A5 A4 A3 A2 A1 A0 <don't care bit>(LSB)
Maximum size of arr is 128 bytes. If bigger, function return a error.
The remarks stick out.
It isn't clear if the address in should be shifted 1 bit left. I'd give it a try (Logical Shift function).
It seems the size needs to be appropriate for the function? Or perhaps make it 128 so it fits even the maximum of data?
Search LabVIEW like a graph! 
@Luc1234 wrote:I know srh and address is correct because the other functions are executing correctly.
Does the manual mention for the other functions that the address needs to be shifted left one bit?
If there is source code for some examples, I'd study them, and the manual. Not just read them, but study them. Study until the code works and you fully understand why it works. If there is anything in the examples and\or manual and\or your code that doesn't make sense (e.g. it doesn't work or it does work and you don't know why), you will probably hit a wall at some point.
@Luc1234 wrote:
I read somewhere that Labview is not very good with pointers to arrays, and that sometimes you have to manually dereference it, maybe this is the case right now?
That's nonsense! LabVIEW is perfectly fine with that and treats them properly. It is the understanding of most LabVIEW programmers trying to do C programming when having to deal with Call Library Nodes that is lacking! 😀
And
unsigned short cntis not an uint8 like you configured in your Call Library Node but an uint16. Not likely causing the function to fail as LabVIEW will have to pass an entire int anyhow onto the stack but still not correct.
@Luc1234 wrote:Indeed I have taken this into account. As said, I know the other parameters are correct because I passed them into other functions with succes.
Any change the read array function will only work if cnt is exactly 2 (or whatever is expected)?
@Luc1234 wrote:I read somewhere that Labview is not very good with pointers to arrays, and that sometimes you have to manually dereference it, maybe this is the case right now?
I agree with Rolfk on this.
Of course you might sometimes have to dereference memory, but that's either a self inflicted choice of the LabVIEW programmer or the API programmer. It would be the same in any language.
The only 'complication' that LabVIEW adds is that you can easily abort a VI, before deallocating memory or calling proper close functions. This could leave 'leaking' memory. I quoted 'complication', because this is one of the best features of LabVIEW! It's a luxury few other programming languages, and no compiled programming langue I can think of, have.
wiebe@CARYA wrote:
The only 'complication' that LabVIEW adds is that you can easily abort a VI, before deallocating memory or calling proper close functions.
The main "complication" LabVIEW has with this is that you do not have to worry about these sort of things when programming in LabVIEW. That makes programmers assume that it must be the same when using the Call Library Node, but LabVIEW can't do that for you. The DLL/shared library interface was developed around the rules implied by C. C has certain low level rules and a lot of conventions but no strict definition about how to allocate memory, pass it around and all that stuff. The Call Library Node has to work with these constraints and can't invent its own rules.
The only real rule in C about this is that if it crashes you did something wrong, if it doesn't crash you still very possibly did something wrong and it will come and bite you later on!
There is no way a function in a shared library can tell the caller, look I expect here a parameter, it is an array, needs to have 30 bytes preallocated and I will fill in up to 29 and terminate it with a zero byte at the end. Or this is an array, I will allocate whatever I deem necessary from heap XYZ and hand it back to you, you do need to deallocate it with exactly the matching heap function as soon as you are done with it or our beloved system memory manager will quickly get very unhappy with us two.
@Luc1234 wrote:
Wiebe and Rolfk,
Thanks a lot for your help, there must have been something wrong with the call library block sr_i2c_read_arr, because I copied the call library block sr_i2c_write_arr and only changed the name (they have the same parameters) and it works now.
Thanks for taking the time, it means a lot.
I recommend you go back to the wrong version (hopefully you use Source Code Control) to study the differences. You'll probably learn something that you'll never forget.
My first guess would be on the calling convention. That would usually crash LabVIEW, but if the dll simply reads a parameter (address), and then skips everything if it's wrong, it might not. You could simply get no results.
