03-09-2015 03:00 AM
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:
Solved! Go to Solution.
03-09-2015 06:50 AM
@Ehouarn wrote:
Hello,
I'm trying to stick to the standards described just there:
- Developing LabVIEW Plug and Play Instrument Drivers
- Instrument Driver Development Tools and Resources
- Instrument Driver Guidelines
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.
03-09-2015 06:59 AM
From my poor understanding then
03-09-2015 06:59 AM
From my poor understanding then
03-09-2015 07:23 AM
03-09-2015 08:28 AM
03-10-2015 08:59 PM - edited 03-10-2015 09:11 PM
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:
03-10-2015 09:48 PM
03-10-2015 10:54 PM - edited 03-10-2015 10:57 PM
@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?
03-10-2015 11:12 PM