String Memory Management using Call Library Function

[JustinB_Everix]

I've saved the VI for LV 2016.

Thanks again for the help.

[JustinB_Everix]

I inserted a breakpoint to monitor the data being sent when HIMC_ConnectCtrl is called and here are the results. Could the issue come from the fact that I'm not sending a null value to the com_port_name?

[rolfk]

Well looking at that last pic I wonder if the order of elements means anything. It definitely is a different order than the typedef you showed earlier but that could have a number of reasons, such as different display ordering that you somehow configured. At least in older Visual Studio versions, the order in the variable view was however strictly corresponding to the order in memory.

Unfortunately it looks like you attached the control twice but not the VI.

And yes you definitely should make sure that the element after the last character in any of the strings is a a NULL element.

[JustinB_Everix]

Oh, I didn't notice I uploaded the control twice. Here is the VI.

I will try rearranging the order to match what I see from Visual Studio and see if that works.

[rolfk]

Another thing: Are you sure the function prototype reads actually:

int HIMC_ConnectCtrl( const ComInfo com_info, int *p_ctrl_id );

and not:

int HIMC_ConnectCtrl( const ComInfo *com_info, int *p_ctrl_id );

Because passing this huge structure by value over the stack is for sure going to be tricky!!!

[JustinB_Everix]

Here is a snippet straight from the api reference guide I was given. It appears that it isn't a pointer but I can't see what the issue could be.

The strange thing is that it seems so straightforward when I go through how it is handled in C#. 

[rolfk]

Well a structure passed by value means basically that instead of the pointer to the structure, the entire structure itself is passed on the stack. Basically you will have to do something along these lines (yikes)!!!!

This assumes that the ComInfo structure is organized as shown in your first post, not as in the Visual Studio variable display.

Also note that this will only work for 32 bit LabVIEW. For 64 bit LabVIEW all the strings need to be unflattened to an array of 64 bit integers and the array index would have to be shortened accordingly for each of them and also the number of numeric parameters per element would need to be adjusted like this:

n64 = (n32 + 1) / 2

[JustinB_Everix]

I had to change the unflatten from string to a typecast because it was expecting a binary string input but still I received the value "16777226" as a return which means it was unsuccessful, unfortunately. What is strange, though, is that the execution took almost 10 seconds. When it successfully connects via the C# code provided, it takes about 3 seconds. On the last VI I made that I sent to you, it was about 3000 us before returning with the "16777226" value. I'm not sure if this is relevant information but I figured I should share as much as I can given how much time you've put into helping me. 

I've been using WinAPIOverride to monitor the calls to this specific function (HIMC_ConnectCtrl) across different programs and I recognize that the call made from LV is missing a calling module, I've included screenshots. I am far too naïve in this subject to understand what that means but that seems to be the main difference between the successful and unsuccessful attempts at calling it. I have already reached out to the manufacturer to see if they understand what is going on but in the meantime I will be doing more research on what calling modules are and how they're implemented. 

Again, thank you for all your help. I'll let you follow up if I find a solution in case you're curious.

[rolfk]

The Typecast is definitely absolutely wrong. It performs always byteswapping on little endian CPUs so the byte order of the 32 bit integers is wrong! This means the string will be garbled which can explain the extra delay as the function attempts to connect to an invalid ip address.

The missing calling module is a red hearing. It’s probably a bug in API Monitor or intended behavior since in the case of LabVIEW the calling module is the LabVIEW executable itself.

Now, you keep mentioning a .Net example that you claim to work. If you had attached the sources for this instead in your first post rather than images of little pieces of information from VIs and manuals and various unclear screenshots of Visual Stiudio and API Monitor, we probably would have solved this already. Also please attach the HIMC_API.h from the manufacturer!

[JustinB_Everix]

In order to avoid getting an error, I had to wire a false value to the "data includes array or string size" input. Still no valid return value.

I've included the folder containing the example program, the header file, the HIMC API Reference Guide, the HMPL User guide (HIWIN's proprietary language), and the DLL can be found at c_sharp\api_example\bin\Debug. Please let me know if you need anything else.