I have a data type issue regarding calling. net assemblies

[Freddy.]

The type received by the program interface is Byte&ipAddress, and I used the function of converting IP address strings to bytes. I am not sure if this method is correct because I have been receiving connection timeout errors in subsequent function functions

[rolfk]

It’s definitely not correct. That .Net assembly uses an ambigues type for this parameter that can work in C or C# with its loose type compatibility but not in LabVIEW!

Byte&ipAddress can either be a single byte passed by reference or a pointer to the first element of a byte array. LabVIEW choses to interpret this as the first, which is syntactically very correct.

Most likely this assembly was created by automatically wrapping or converting a C/C++ code library to .Net. The type library really should use Byte ipAddress[] to be unambigues.

Unfortunately there is no way to overwrite the LabVIEW interpretation of the type library in that assembly. LabVIEW assumes that a type library in an assembly is more reliable than what 99.999% of potential users could be when trying to “fix” things.

You have several options:

1) Talk with the manufacturer to fix the assembly. Would be best but might take years to never before it’s done.

2) Create your own .Net wrapper assembly in C# that calls this function but provides the right type information to LabVIEW and then call it from LabVIEW. This is some work and makes you end up with an extra asssembly file to maintain and keep in your code base.

3) Find another API in this assembly with different parameters, for instance with the IP address in string form.

4) if the protocol for your device is documented, write your own LabVIEW library that communicates to this device directly through the LabVIEW network functions.

5) Invoke that function through .Net reflection to define your own interface. This is cumbersome, complicated, requires .Net superpowers and is going to be a nightmare to maintain. I would choose any method above 10 times before going this path.

[Freddy.]

Yes, your analysis is very accurate. I also tried using the method in the routine, but after converting the IP string into a byte array, I didn't know how to reference the value in LV.

C # Part Code:

int iByteCount = MotoComES._ECode.GetByteCount( "192.168.255.10" ) + 1;
byte[] bIPAdd = MotoComES.StringToByteArray( "192.168.255.10", iByteCount );

Program._Temp.AppendLine( "ESOpen" );

// YRC10000==>4 MIC===>5
Program.res = MotoComES.ESOpen(5,ref bIPAdd[0], ref Program._Handle);

I have uploaded the program and. net assembly

[Freddy.]

By the way, when I pass in the wrong ipaddress parameter, sometimes calling the servo controller switch function (ESServo) can work, but it keeps reporting a connection timeout error.

[rolfk]

Just as I guessed. That MotoComES_CS.dll is simply a very thin .Net wrapper, using simply .Net Interop, around the actual native MotocomES.dll. And most likely generated fully automatically by a tool that takes the C syntax from the header a little to literally.

Personally I would simply ditch that .Net wrapper and go directly to the DLL with the Call Library Node in LabVIEW. However the problem with that is that you need to understand a few things about C programming to be able to have any chance of getting such a project be anything more than a crash producer.

The underlying C API for that function is:

LONG STDCALL ESOpen(long controllerType, char *ipAddress, HANDLE *handle);

While it is not conclusive (char * in C could be a single byte or character passed by reference, or an array of binary bytes or a C string) this prototype does one make believe that it would be possible to actually pass in a simple string with the address. If that is true, the (automatically generated) .Net assembly is not only ambiguous but simply outright wrong!!

But without proper documentation of the actual underlying DLL (preferably not in Chinese or Japanese), this is all guess work anyways.

[Freddy.]

I guess I can use MOTOCOMES.dll directly instead of referencing MotoComES_ CS.dll to call library functions, I have uploaded the development instructions

[Freddy.]

There is another issue: when I use labviewv to import shared library files, the program will freeze. Perhaps it is related to the complex structures in the library...

[rolfk]

---

@Freddy. wrote:

There is another issue: when I use labviewv to import shared library files, the program will freeze. Perhaps it is related to the complex structures in the library...

---

Well, for one that file is in Unicode (those Japanese characters in the comments wouldn't be possible otherwise) and LabVIEW does not like Unicode files. You should first convert it to clean ASCII.

The other thing is that the Import Library Wizard does not have any magical capabilities, despite its name. It will try to interpret the C syntax in the header as best as possible, but as pointed out already, C is notoriously ambiguous in its syntax, as you can see in the mixup of the .Net assembly creation for the ESOpen() function! An automated tool simply can't know what will be the right thing to do in a lot of these cases. The LabVIEW import library wizard incidentally will understand this specific parameter correctly as it likes to assume that char * is in fact a C string, but there are other things in this API such as the sometimes fairly involved structure parameters for some of the APIs that it will at least struggle with or potentially simply throw its hands in the air and declare defeat.

Even if it can generate a VI wrapper for a specific function, depending on it to be correct, is as safe as driving your car with a blindfold on. Yes, indeed, it is NOT! Someone with enough understanding of the C syntax and details about how a C compiler works, will need to review each and every of these VIs to make sure it is not somehow doing buffer overflow errors or other insidious things.

[Freddy.]

I directly called the library function myself and wrote a control function to open servo control, but I am confused about handling this type of handle

[rolfk · Accepted solution]

There are a few more confusions you are having!

1) LONG, long, and int are all 32-bit integers (at least under Windows)

2) the handle needs to be passed by reference, so configure it accordingly in the Call Library Node

3) HANDLE is a pointer sized integer datatype, so configure it as such in the Call Library Node and treat it as 64-bit integer on the LabVIEW diagram

4) No need to try to do integer to pointer voodoo for the handle

5) Why hardwire every input parameter on the diagram? You want to be able to call these functions from your program later and be able to specify the parameters you want to use.

 

But there is a long path ahead for you. Some of the other functions are going to really test your resilience. 😁