I am working with MX Component .NET, and receiving one data value works well without any problem, but continuous reading does not work.
Is there a way to read data continuously?
Solved! Go to Solution.
receiving one data value works well without any problem, but continuous reading does not work.
Is there a way to read data continuously?
Use a loop to repeat a certain task/step in your VI.
When you want to read more than once you should place the Read operation into a loop…
Thanks for the response.
If the amount of data is small, you can use a loop, but if the amount of data increases, there is a delay, so you need a way to read it at once.
so you need a way to read it at once.
This is the time where you should read the manual for this hardware/software to learn about the parameters of these two ReadBlock calls…
I don't know your MX library but it seems it contains a bug in the contained type library. This bug can happen if the programmer used automatic tools to convert the C header definitions into the type library without reviewing the output carefully.
you see that your function declaration in the selection list box is as follows:
ReadDeviceBlock2(String szDevice, Int32 lSize, Int16 &lpsData);
Now an exerienced C(++/#) programmer can deduce from the name of the lpsData and the fact that there is a size numeric parameter too, that this is really a pointer to a memory buffer. Automated tools have not such inherent guessing capability. They see a parameter that is an Int16 passed by reference (pointer) and simply assume that this is exactly what this means.(a single Int16 passed through a pointer, which is a very valid thing as that is the only way a function can return values in the parameter list).
This tool creates the typelibrary with this information and embeds it in the assembly. LabVIEW wanting to make life for you easy goes and reads this type library and sets up the .Net node accordingly to what the .Net type library tells it (a single Int16 passed by reference). LabVIEW does not allow to correct this, as it assumes that the type library is the single authoritive reference that describes all entries in the assembly. (If it would allow you to do that or even require it, you are back at the Call Library Node where you MUST configure these things yourself as there is no such thing as a type library in classic DLLs).
The proper solution here is to get a new assembly from the manufacturer that has these type library entries fixed. This parameter needs to be defined as an array parameter in the type library and the only people who can do that are the manufacturers of that assembly.
A possibly more practical but messier solution would be to create a wrapper assembly in C# that calls this assembly and exports a properly declared interface that you then can import into LabVIEW through the .Net nodes.
thanks for Rolf Kalbermatter
These are links to previous questions about Mitsubishi MX components.
The problems were not resolved.
If the DLL provided by the manufacturer is a general DLL, there is no problem if I use the Call Library Node. But I can't use Call Library Node. Manufacturer only provides ActiveX control and .NET DLL.
I told you the two possible solutions:
1) Get a fixed version from the manufacturer: Seeing that this issue was already present in 2007 nd 2009 without any fix since, it is very unlikely that this will be possible. It's even very possible that this product is long since a legacy product that is not anymore supported by the manufacturer at all.
2) Create a wrapper assembly yourself that does the right thing.
It's theoretically possible to use a Hex editor and change the typelibrary definition in the original assembly. I did that once for an ActiveX library just for lolz but it is an unmaintainable solution. Finding the right byte to modify is a torterous and long process of disassembling the file structure of the assembly DLL and once you change it, it will be quickly and automatically restored by Windows to the original version as a way of preventing tampering with system files by viruses and such.
I try to wrap the "ActiveX Control DLL" and use it. I contacted NI, but it's not helping.
Rolf thanks for your help.
NI definitely is the wrong party to contact about such issues. It’s technically a bug in the assembly or ActiveX library by providing a bad type library..
While you might want to argue here that it’s perfectly possible to call this component in C++ so LabVIEW should be able to do it too, that’s not really fair play. The C(++\#) languages are ambiguous about the difference between a pointer to a value and an array. In the worst case you have to place a typecast in the code. LabVIEW is much stricter and the type library specifically makes a clear difference between the two so LabVIEW uses that information.
The only *fix* NI could do is to allow the user to configure the ActiveX or .Net node in a similar way to the Call Library Node and allow users to reconfigure the node that was created in 99.9% of the cases correctly from the type library to something else and then crash, simply because they can modify it without the slightest understanding what they are doing. Such a configuration option would be a major development effort and NI is not gona do that for a myriad of reasons, including that ir would actually increase the amount of support requests and would be for fixing a bug in a 3rd party component that does happen but very infrequently.