looking for labview routines to read dallas semi 1 wire devices

[david43a]

I have recently tried to write code to talk with the dallas semi usb 1,2 and 3 wire adapter...just wondering if anyone has been successful!

[Lycangeek]

I've been working with someone using the 1-wire device recently. The ActiveX interface supplied by Dallas Semi has a bug in it where early binding clients (such as C++ or LabVIEW) won't work. However, they also have a .NET interface that seems to do the trick. I've included a little example program ported from the VBScript example that ships with the software. It scans the system looking for temp devices.

To get the .NET API, go to "C:\Program Files\Dallas Semiconductor\1-Wire Drivers Version 4.00 Beta 4" and run the OneWireAPI.NET_Setup.msi. Once this is done, copy "C:\Program Files\Dallas Semiconductor\OneWireAPI.NET\OneWireAPI.NET.dll" to the same directory as the VIs.

NOTE: There unforunately is a bug in LV 7.1 that prevents you from using the interfaces defined in this library, so you need to cast to your specific container object (OneWireContainer1, OneWireContainer2, etc).

Let me know if this helps.

[tomsch1]

EndExclusiveAccess.vi
  Virtual Instrument
    - LabVIEW does not have references to the following .NET assemblies used by this VI:
 OneWireAPI.NET, Version=1.0.1571.14202, Culture=neutral, PublicKeyToken=9d3abe1382c69a37
  Please add references to those assemblies by selecting "Tools>>Advanced>>.NET Assembly References" before editing the VI.

wheni try to use this i get this error. is this the bug you were refering to??

[Lycangeek]

Are you saying you get this error when trying to run the VI? If so, make sure that the assemblies are in the same directory as your top level VI.

That is not the error you get regarding the bug and .NET interfaces - you just can't do the casting in LV. The other way to work around this other than casting to the specific class is to create a simple little .NET assembly that does the cast for you.

[m3nth]

Brian,

I am trying to do something very similiar to the code you had posted so bear with me trying to get your stuff to work.

That error (text posted previously) is received when opening the VI, not when running it.  The run arrow doesn't break, it just comes up with that error in the same box that it would if it was telling you that it loaded VI's from different places than expected.  After downloading the .NET framework v1.1 and opening your VI, I receive the same error.  After clicking ok the VI isn't broken but none of the properties / methods are available.

Also, your post left some information out of it that made it somewhat cryptic::

"To get the .NET API, go to "C:\Program Files\Dallas Semiconductor\1-Wire Drivers Version 4.00 Beta 4" and run the OneWireAPI.NET_Setup.msi."

However you failed to mention what installation or drivers result in this Dallas Semi directory.  There are a slew of TMEX drivers and the like that are available for download here, but I'm pretty sure none of them are what you were referring to (I couldn't get the ones I tried to work).

Ah... I think I have found the correct site and files now here with a link to the MSI Installer.

After downloading and running the MSI Installer, this file is available: 

C:\Program Files\Dallas Semiconductor\1-Wire Drivers Version 4.00\1-Wire.NET\OneWireAPI.NET.dll

I copied it to the VI directory with your files and still receive the error when opening.  I then imported it as a reference (Tools > Advanced > .NET Assembly References) and once again am still receiving the error with no properties or methods available.  Even when restarting LabVIEW the error appears when the VI is opened, and going to the .NET Assembly References dialogs shows that the file is still on the list after adding it previously.

For those of us not versed in .NET, can you lay out a little groundwork on how to get this working?

• Will .NET framework v1.1 work or do we need some version 2 beta? (there were a dozen links on Microsoft's site and I couldn't figure out what to download so I just got v1.1)
• Can you give some more details on what you mean about the bug in LV7.1 where the interfaces are not available for this file?
• Can you give some more details on what you mean "to cast to your specific container object (OneWireContainer1, OneWireContainer2, etc)."? -- do you do this somewhere in the example code you posted?
• I noticed the version for the DLL was slightly higher than the version LV is asking for in the opening error message--does that matter? (I'm guessing it shouldn't)
• How did you get to a point where you can select different methods for the .NET class? I believe this is linked to the error message and the DLL (or Assembly Reference, whatever), being loaded correctly (and not getting the error message)
  

[Lycangeek]

Let me try to answer the questions you asked...

• Will .NET framework v1.1 work or do we need some version 2 beta? (there were a dozen links on Microsoft's site and I couldn't figure out what to download so I just got v1.1)
• You should only need v1.1 (although I strongly recommend installing the SP1 that is available from MS).
• Can you give some more details on what you mean about the bug in LV7.1 where the interfaces are not available for this file?
• The bug was in the code that worked out the interface implementation tree - what were the total of all interfaces implemented by a given class. Therefore when attempting to cast to a valid interface, LV would incorrectly report that the interface was not supported. But if you do the cast inside .NET (a helper method in your own assembly), you can work around this.
• Can you give some more details on what you mean "to cast to your specific container object (OneWireContainer1, OneWireContainer2, etc)."? -- do you do this somewhere in the example code you posted?
• The design of the 1-Wire API is that each type of device (or class of device, I'm not very familiar with this system) has its own class such as the ones listed above. There is a set of base classes and interfaces so that devices with common functionality can be programmed the same way, but at the end of the day, the full functionality of the device is implemented in a specific class. Does that make sense?
• I noticed the version for the DLL was slightly higher than the version LV is asking for in the opening error message--does that matter? (I'm guessing it shouldn't)
• I'm not sure I know what you mean, but I expect that I worked with an early beta than you have. Indeed, it looks like you have a released version rather than a beta so this seems reasonable.
• How did you get to a point where you can select different methods for the .NET class? I believe this is linked to the error message and the DLL (or Assembly Reference, whatever), being loaded correctly (and not getting the error message)
• I didn't get the experience you are describing so my invoke and property nodes had the drop down list I could select from. I'll need to reinstall everything to do this again (I last played with this stuff a few months ago).

Hope this helps some. I'll try to find some time to recreate the system in the near future...

[m3nth]

Brian,

Thanks a lot for your info.  I think the biggest problem I have is that the released version of the .NET DLL, when loaded into LabVIEW, doesn't have any property nodes or methods available.

Attached is the only version of the DLL I have or could find, v4.0.0.7122.  If I place a property node or invoke method and try and link to the .NET class (listed under the Assembly list as OneWireAPI.NET in the Select Object From Assembly dialog box), there are no objects to select under that option.  If I place a .NET constructor and try the same thing I get the same results... there is apparently nothing that LabVIEW recognizes to create.  I'm guessing that if I had a valid (ie, LabVIEW-recognizable) version of this file that I would be able to create the methods and property nodes in a similiar fashion to your example in order to get the information I need from the 1-Wire network.

[Lycangeek]

Unfortunately

"It works fine here"

I unzipped the assembly, put it into c:\temp and launched LV 7.1. I then created a blank VI and dropped a constructor node down. I then browsed over to the c:\temp directory, selected the assembly and picked one of the OneWireContainer classes. I was also able to wire up an invoke node and select a method.

Some things to check

1. Are you running LV 7.0 or 7.1?

2. Do you have .NET 1.1 installed, or just 1.0?

3. Do you have the .NET 1.1 SP1 installed?

[m3nth]

Well I'm not sure what to do about getting the .NET stuff to work... it looks like it just doesn't want to.

1) I am running LV 7.1.1
2) I installed .NET 1.1
3) I installed the SP1

It still does the same thing.

My workaround will be to determine the serial numbers of my devices using the Maxim java app and then use those in conjunction with someone else's drivers that have already been compiled.  It would really be nice to write my own code for discovering the devices though.

If you think of anything else that may be causing this to happen please let me know.  If all it should take are the above three things to get it to show up with stuff when I pull it up in LabVIEW I'm not sure why it's not.  I didn't configure anything in the .NET control panel or anything like that--don't have .NET installed for anything else either (C# for example), but I don't think those things should matter.

Thanks

[Lycangeek]

The only other things I can suggest to try are

1. Clear out your .NET Assembly Reference List and try it. Make sure to restart LV after your clear it out.

2. If it is cleared, try adding the assembly to the reference list.

3. Move the assembly to the same directory as the VI.

Personally, I don't have it in my reference list - it is completely empty. I then create a blank VI and browse over to it in the c:\temp directory. But if you can get it working on one of these variants, it might give ideas as to what is going on...