RE: VISA alternative

[Rolf K. <rol...@ci...>]

Jim Kring [mailto:ji...@ji...] wrote:

> If anyone has been reading the info-lv thread on NI VISA licensing, =
you can=20
> see that there is a huge demand for an open source solution for serial =
and=20
> parallel port I/O.  NI only allows you to distribute 10 copies of your =
built=20
> application that uses NI "Driver Software".  After that, they want =
$395 per=20
> copy!  Sounds like a good openg project to me.  How about OpenGSerp =
and=20
> OpenGPortIO?  I don't have the background to code up the OS interface =
or=20
> sharedlib, but I can help with all other aspects of the project.

Well, first as I stated earlier on Info-LabVIEW I do not think that the =
$395
is for a VISA runtime license but rather for the entire VISA software, =
with
development libraries, documentation, T&M Explorer, VISA Interactive =
Control
and whatever there is. Anything else would be stupid and completely =
unlogical
to explain, as you can buy some NI products which come with VISA for not
much more than that amount.

Second I was thinking about creating an OpenG PortIO driver which =
supports
both the slow but simple register access of the NI solution as well as =
an
alternative high speed access, which needs some prior intialization. I =
have
all the information and even some code for Win32 here but need to clean =
it
up and prepare a proper LabVIEW solution for it. It will be a source =
code
release but since you need a Windows DDK installed to compile it, I =
don't
think there will be many people trying to compile it themselves, so a =
pre-
compiled binary will be provided as well. I have not a very good idea =
about
how to go to implement the same under Linux, although it shouldn't be =
that
difficult, but for Mac I'm completely clueless, nor if there is actually =
any
possible need for this on the Mac. After all you don't have LPT and COM =
ports
there ;-)

Third trying to write a OpenG Serp driver is a pain of a thing to do. =
Doing
so for one plattform is already quite a serious project, but trying to =
support
Win32, Linux, and Mac OS X is most probably a major undertaking, =
requiring
more commitement from several people than most of us are willing and =
able
to do.
You would have to abstract the Win32 COMM API on one hand, the Linux =
device
interface on the other and the Macintosh device driver interface (or can =
one
maybe use the Unix device interface without loosing to much control), =
which
are completely different in their design, interface, and abstraction.=20
Of course one could still use the disappeared Device IO Control nodes, =
which
LabVIEW still supports in 7.0. But there are a number of issues. The =
Device
IO Control interface in LabVIEW is built to interface with the Mac =
Device
Manager and can actually be used to call virtually any Mac OS device =
driver
although it never was really used for anything but the serial port =
drivers.
On Windows the famous serpdrv acts as a translation between the Mac OS =
Device
Manger interface used in LabVIEW and the native Win32 COMM API. The =
architecture
of this translator driver has never been published and depends on some =
internal
tools only available by NI, but has some similarities with creating =
CINs.
On Linux I'm not exactly sure if a similar serpdrv exists or if the =
LabVIEW
Device IO Interface nodes map directly to the unix device driver =
interface.
Problem is, that I'm fairly sure that NI tries to completely disable =
support
for this interface in one of the next major releases.
So the only viable solution would really be over a shared library =
interface
which in itself should work quite fine as proven in lvzlib and to a =
lesser
extend in labpython.
Neverthless serial port programming on Win32 API level in a generic way, =
and
not just for a particular device, is anything but pleasant, and other =
systems
won't be much simpler here.

Rolf Kalbermatter