"This class contains no public constructors" message

[JoelWhittC]

Hey Garima,

I was able to reproduce the crash. I find it odd that the get_Item method is able to be called in the first place, considering that it is no where in the pdf documentation for the dll.

What are you expecting the get_Item method to return? I though it was a little strange that you called the method and then immediately closed the reference. I found that when I removed the Close Reference vi that the program successfully executed. I tried wiring other things to the output of the get_Item method and found that if I wire anything at all to the output that it will crash, so it wasn't just the act of closing the reference that caused the error but the act of using that output in anyway.

If I knew what you were trying to accomplish with this application, then maybe we can use the documentation to find a method that will do what you need.

This does appear to be a problem with the dll though. When I opened the dll in notepad and did a search for get_Item, I can see that it does exist in some form, but may just be an empty or incomplete function. You will have to see the third party that created the dll for more information about the get_Item method, especially since it is undocumented. The methods that have been documented seem to work properly.

Thanks,

Joel C.

National Instruments

[Garima]

Hi Joel,

Thank you so much for an update so soon. I sent you a changed VI, I was using the get_Item reference by a property node for CyUSBDevice object.

This method in my case is expected to return the reference to the CyUSBDevice object, or you can say the reference to the first device attached.

So, yes it fails or crashes as you told.

Is it that get_Item is a generic method available? I thought its like a part of the .NET frameworks or some other standard dlls which are always by default included. Is that so? or is it coming as an option because the CyUSB.dll includes it.

Also, here is what I want to achieve: I wanted to use the index operator as given in section 4.25.6 of the CyUSB.NET.pdf attached for you. This index operator I know can be easily used in Visual C# applications. I don't know how to use it in LabVIEW, I found it identical to get_Item and thought it should be correct to use it. Is there any way to implement the index opeartor as in section 4.25.6 and the few consecutive ones?
This is an inevitable operation, as it will return to you the reference to the attached USB device object and then you can do the consecutive processing on it.

In my first elaborate update on this query, I asked a few questions before answering your queries. Will it be possible for you to address them ? Also, is there something specific I should ask to the team which developed this dll?

Please pardon me for my numerous queries.

Best Regards,

Garima

[JoelWhittC]

Hello Garima,

Sorry it has been a while since my last reply.

I am not sure what you mean by get_Item being a generic method. The methods in each dll can differ depending on what the developer coded into the dll. This is also not a standard dll by though, it was developed by a third party.

I looked through the manual to try to find an alternative to 'get_Item' and found 'CyUSBEndPoint', however the documentation was not specific enough for me to figure out how to call it.

get_Item is coming out of that dll in LabVIEW because the dll file is including it as an option. The method is still subject to the code inside of the dll, which appears to be broken or we not being implemented in the manner for which it was designed. Since there is no documentation for the method, I'm not sure how to use it for what it was designed for.

I think the best course of action at this point would be to contact the developer of the dll and see if they have updated documentation, a new version of the dll, or any pointers on how to do what you are trying to accomplish.

Thank you,

Joel C

National Instruments

[DM83]

I have encountered the same issue. Was a solution or workaround found?

[RyanPoPo]

DM83,

Are you also experiencing this issue with CyUSB.dll? Some previous members found success by following this Knowledge Base article: How LabVIEW locates .NET Assemblies

If you are not dealing with the CyUSB.dll, could you give me a little more information on your project and how you encounter this error?

Regards,

Ryan

[tyk007]

I was curious and did some digging around this mysterious CyUSB .net assembly.

The "get_Item" method that is referred to is actually part of a .Net indexer. This is a feature of .Net that allows a type to be indexed like an array (eg. list[0], list[1]) and to be able to both read and write to those indexes, even if the type itself is not actually an array. In this example, the type is a list of USBDevices so each index is a type of USBDevice. This indexer feature is a convenience one that enables any type to appear as if it is an array of types and using convenient syntax.

.Net indexers are implemented, at a lower level, by special "get_" and "set_" methods that specially marked in the compiled code so that client code can identify that they are for an indexer. In the case of this indexer, the methods are "get_Item(Int32)" and "set_Item(Int32, USBDevice)". When client code uses the indexer, these methods are actually called - the client is blissfully unaware of this and thinks they are getting / settings items in an array type of some sort using this convenient "USBDeviceList[0]" syntax.

The USBDeviceList type has many indexers - the one referred to in these posts is one that takes an index as an Int32. While many languages recognise indexers, LabVIEW does not. LabVIEW, however, sees the low level method names. This is where the "get_Item" methods that are exposed come from. This is also why there is no documentation for these methods - they are .Net artifacts there to make interoperabiliy easier and to make the indexer convenience feature work.

Documentation does exist for the indexer itself. Looking through the pdf on the previous post, I found the entry as "USBDeviceList [int index]" which is the indexer. This entry explains what the indexer does but it is as simple as it sounds - it reads or writes the USBDevice from an array set based on the index provided as an Int32. In our case we are interested in the get_ method, so we are only reading from the USBDevice list at the specified index. I decompiled the CYUSB.dll file and can verify that the source does exactly that.

I realise that this explanation does not directly solve the issue presented here but hopefully this background material will be helpful in resolving it.

EDIT: I was able to use the CyUSB assembly in LabVIEW 2012, construct an instance of the USBDeviceList type and use the get_Item(Int32) method without crashing LabVIEW. However I do not have any of the actual devices involved so the issue may be related to the interoperability with the unmanaged code in the assembly related to working with USB.

[DM83]

The attached is my LabVIEW implementation of c# code that I inherited. The c# code is running fine.

The LabVIEW code runs fine until the “get_Item” method; if the output of get_Item is wired at all to anything then LabVIEW crashes.

The line of c# code that has caused me issues is

fx2 = usbDevices[0] as CyFX2Device; // where usbDevices is the USBDeviceList

I have noticed that in c#, picking out a single USB device from the device list is as simple as indexing an “array”. However, I couldn’t find a direct equivalent in LabVIEW so went the next closest method in the absence of anything better to do.

tyk007, how did you make the code run?

[tyk007]

---

@DM83 wrote:

The attached is my LabVIEW implementation of c# code that I inherited. The c# code is running fine.

The LabVIEW code runs fine until the “get_Item” method; if the output of get_Item is wired at all to anything then LabVIEW crashes.

The line of c# code that has caused me issues is

fx2 = usbDevices[0] as CyFX2Device; // where usbDevices is the USBDeviceList

I have noticed that in c#, picking out a single USB device from the device list is as simple as indexing an “array”. However, I couldn’t find a direct equivalent in LabVIEW so went the next closest method in the absence of anything better to do.

tyk007, how did you make the code run?

---

Yes, as I detailed above the convenient "[]" syntax is due to the .Net indexer but this is simply syntactic sugar in languages that support it (eg. C#) - in reality your C# code is still calling the get_Item(Int32) method behind the scenes, jut as your LabVIEW code does.

I have tried your snippet but I had to modify it - I do not have any CyUSB devices in my system since I don't have the hardware; unfortunately only you do. I removed the case structure so that get_Item() would run irrespective of the Count property. This means that there will always be a Count of 0, and thus get_Item will always return a null reference. However it does this fine on my system using your snippet.

I strongly suspect that the issue is to do with the unmanaged unsafe code inside the CyUSB assembly, but I will attach a mini project that you can use to try out whether the indexer itself is causing you issues on your system.

EDIT: I have attached a LV2012 project with a made-up .Net assembly called Indexer (.Net 3.5 in CLR 2). The attachment extension should be re-named to .zip and extracted. Run the Test MagicList.vi - it should generate an array of five int32 items (123, 456, 789, -1 and -2) using the index (ie. the "get_Item" method). If this works on your system then the issue is not to do with how LabVIEW interacts with the indexer - rather it is an issue in the CyUSB.dll itself that is causing your LabVIEW to crash.

SECOND EDIT: I just re-read your post - how many devices do you have (ie. what is the Count property returning)?

[DM83]

Thanks tyk007.

I removed the micro controller, and hardcoded the case structure to false so that “get_Item” would be called anyway. The result is that “get_Item” returned an empty refnum and the “To More Specific Class” generated an error onto the error cluster, but LabVIEW didn’t crash. I think that you are also seeing this.

Test MagicList.vi ran as expected on my system without any issue.

The Count property is returning the number of Cypress Micro controllers that are attached to the PC’s USB ports.

In my case I have one so count returns 1. The reason that I check is that I don’t want to attempt to download firmware if the USB is unplugged.

[tyk007]

There are a number of .Net integration issues that have been fixed as part of LV2013 (I have noticed a few cases where sets of property nodes could cause LV to crash). Perhaps an upgrade is an option?