LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to distribute LabVIEW Instruments Drivers.

Solved!
Go to solution

Hello,

I'm trying to stick to the standards described just there:

However, I cannot see clearly what is the best way to distribute the LabVIEW Instruments Drivers, except that I need to be compliant with those standards to be on the IDNET (Instrument Drivers Network).

Here is a couple of questions I'm not really sure about their answers:

  • Is it okay to use a .NET dll and to make some calls?
  • Is it fine to hide the Block Diagram? With passwords in the Drivers
  • Can we put prevent the modification
  • In my situation several devices (or let's say modules can controlled through one communication medium), so basically I might have one instrument drivers for several things.,,
  • May I use some OOD? In order to control the equipment with methods and set some properties and encapsulate the communication stuff in classes, some equipments could be consider are inherited from others (more recent for instance), or this is totally prohibited by the guidelines above?
  • What is the most suitable Specification Build type: Packet Library or other? If packed library, how to handle the early version created issue when opening the lib with newer version of LabVIEW then?
  • How to deal with the copyright thing, do I need to copy and paste the copyright on both the Front Panel and on the Block Diagram?
  • Is this copyright enough: "Copyright (c) <Company Name>. All rights reserved"?

 

 

0 Kudos
Message 1 of 11
(3,424 Views)
Solution
Accepted by topic author Ehouarn

@Ehouarn wrote:

Hello,

I'm trying to stick to the standards described just there:

However, I cannot see clearly what is the best way to distribute the LabVIEW Instruments Drivers, except that I need to be compliant with those standards to be on the IDNET (Instrument Drivers Network).

Here is a couple of questions I'm not really sure about their answers:

  • Is it okay to use a .NET dll and to make some calls?
  • Is it fine to hide the Block Diagram? With passwords in the Drivers
  • Can we put prevent the modification
  • In my situation several devices (or let's say modules can controlled through one communication medium), so basically I might have one instrument drivers for several things.,,
  • May I use some OOD? In order to control the equipment with methods and set some properties and encapsulate the communication stuff in classes, some equipments could be consider are inherited from others (more recent for instance), or this is totally prohibited by the guidelines above?
  • What is the most suitable Specification Build type: Packet Library or other? If packed library, how to handle the early version created issue when opening the lib with newer version of LabVIEW then?
  • How to deal with the copyright thing, do I need to copy and paste the copyright on both the Front Panel and on the Block Diagram?
  • Is this copyright enough: "Copyright (c) <Company Name>. All rights reserved"?

 

 


Not sure about 1) but 2) and 3) are definitely a no go if you want your library to be distributable through the ID network. The standard only allows for DLLs in that  are really developed in C but would require you to also distribute the C code as far as I understand.

OOP may not be a problem.

 

Packed Library is definitely not something you want to do. They only work in the LabVIEW version in which they were created. You will hate the moment you decided to go with packed libraries as requests come in for other LabVIEW versions and your drivers are bashed on all discussion forums as being a pain in the ass to use.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 11
(3,398 Views)

From my poor understanding then

 

  • No .NET dll then, so I will try to everything in LabVIEW even if I need to duplicate stuff in two different languages

 

  • The sources must be fully accessible and modifiable to eventually allow the LabVIEW Instruments to part of the IDN, sounds a bit weird to me... I'm checking the guidelines given by NI but can't find where this rule is indicated or mentionned. I would understand if we were doing something like quite open source but this is not the case.

 

0 Kudos
Message 3 of 11
(3,393 Views)
Solution
Accepted by topic author Ehouarn

From my poor understanding then

 

  • No .NET dll then, so I will try to do everything in LabVIEW even if I need to duplicate stuff in two different languages

 

  • The sources must be fully accessible and modifiable to eventually allow the LabVIEW Instruments to part of the IDN, sounds a bit weird to me... I'm checking the guidelines given by NI but can't find where this rule is indicated or mentionned. I would understand if we were doing something like quite open source but this is not the case.

 

0 Kudos
Message 4 of 11
(3,393 Views)
All, repeat all, of the NI provided drivers have the source code available and unprotected so why is it weird? Why do you want the driver on idnet if you don't want people to freely use it? Is this for an instrument that your company manufactures?
0 Kudos
Message 5 of 11
(3,382 Views)
Solution
Accepted by topic author Ehouarn
p.s. If you want to use .NET, the standard is an IVI-.NET driver as described by ivifoundation.org. You should not be making up your own style.
0 Kudos
Message 6 of 11
(3,363 Views)

Oki let's say the source code has to be shared, what about if some confidential parts are part of the drivers for some reasons (I'm not saying this is my situation) or some specific algorithms, can we at least put a password on those parts? If I follow your logic, it means that just for the sake of the IDNET we need to drop everything to NI (I know IDNET belongs to them and a lot of things on it too...), I was checking some Instrument Drivers downloaded from that platform and saw a lot of copyrights to National Instruments... and not necesserarly to company that provides the drivers.

 

 So far from my understanding, for now:

  • Is it okay to use a .NET dll and to make some calls?: NO
  • Is it fine to hide the Block Diagram? With passwords in the Drivers NO / ???
  • Can we put prevent the modification See above
  • In my situation several devices (or let's say modules can controlled through one communication medium), so basically I might have one instrument drivers for several things.,, ???
  • May I use some OOD? In order to control the equipment with methods and set some properties and encapsulate the communication stuff in classes, some equipments could be consider are inherited from others (more recent for instance), or this is totally prohibited by the guidelines above? ???
  • What is the most suitable Specification Build type: Packet Library or other? If packed library, how to handle the early version created issue when opening the lib with newer version of LabVIEW then? ??? (Simply source distribution then?)
  • How to deal with the copyright thing, do I need to copy and paste the copyright on both the Front Panel and on the Block Diagram? ???
  • Is this copyright enough: "Copyright (c) <Company Name>. All rights reserved"? ???
0 Kudos
Message 7 of 11
(3,303 Views)
Solution
Accepted by topic author Ehouarn
I don't understand how you can have parts of a driver that are confidential or implement some algorithm. A driver reads and writes to an instrument. The commands would typically all be the in programming manual. A special hell is dedicated to an instrument vendor that keeps commands private. If you want to create an application that uses a driver In a unique way, then go ahead but that code is NOT a driver.

Source distribution is as you see all of the other drivers and how the wizard gets you started - as a lvlib project.

I don't understand your question about copyright. You can put out there if you want but I don't see where it's a requirement. Unless you actually go through the process, the copyright notice is meaningless.
0 Kudos
Message 8 of 11
(3,294 Views)

@Dennis_Knutson wrote:
I don't understand how you can have parts of a driver that are confidential or implement some algorithm. A driver reads and writes to an instrument. The commands would typically all be the in programming manual. A special hell is dedicated to an instrument vendor that keeps commands private. If you want to create an application that uses a driver In a unique way, then go ahead but that code is NOT a driver.

Source distribution is as you see all of the other drivers and how the wizard gets you started - as a lvlib project.

I don't understand your question about copyright. You can put out there if you want but I don't see where it's a requirement. Unless you actually go through the process, the copyright notice is meaningless.

What about specific implementations, some encyphering methods, or some sort of compressions used to achieve faster communication (yeah baudrate is not necesserarly the only answer), I'm afraid, actually I dont' really understand your point.

 

And worse, what about if a vendor decides that the communicate has to be ofuscated, the policy can independant of that.

Of course, the purpose of any drivers is *indeed* to communicate, but when the security is at stake I don't think that making everything open is that wise (once again not my situation).

Your opinion remains me a bit the people despising the use of the internal keyword in C#.

Definitely Drivers = Communication,

but saying Drivers = Open Specifications or maybe NI Drivers = Fully Open (and puttin' the NI Copyright of the vi belonging to others...ahem) seems a bit doggy.

 

I got my asnwer, so I would still say thanks for that (although I'm still looking for some guidelines that would be against the OO use)  but I do not fully agree about how a driver has to be open according to your thinking.

 

I might be wrong and if you should tell if that's the case, but do you have fully access to the source code of the NVIDIA drivers when using your video device, not sure the binaries are really open, well after all we can still go through all the bytes and spend plenty of time guessing what do they mean?

(yup I'm no more talking about LabVIEW Instrument Drivers).

I'm not willing to be sarcastic, but I'm curious about your explanations concening binaries used as drivers, according to you, they are not really drivers then?

 

0 Kudos
Message 9 of 11
(3,283 Views)
LabVIEW instrument drivers are not at all comparable to Windows device drivers. From the very beginning, the drivers were nothing more than LabVIEW VIs that used the basic communication protocols and packaged the published commands on a neat and manageable manner. Part of the popularity of LabVIEW is the number of drivers and the source is available to meet fix bids and meet special needs.

There is no security surrounding gpib, rs-232, Ethernet, etc. instruments. If you don't want to publish s programming manual where a user can communicate with those protocols, then don't. Your choice, but it's not an instrument I would purchase. Obfuscating the code so I can't fix your bugs or support it in a couple of years when you and your company are gone, is not something I am willing to approve of.
0 Kudos
Message 10 of 11
(3,263 Views)