Re: VISA alternative

[Christophe S. <chr...@ep...>]

Jim, Rolf,

I second Rolf in the fact that a generic IOPort driver might be a quite
large project. On the other hand a serial driver sounds like a reasonable
starting point.
Now regarding the Mac, there is no serial port built-in anymore. If you want
one you should either replace your internal modem or use an usb-serial
converter. On the other hand you can "route" your serial line to a bluetooth
connection to talk to other devices such as phone, PDAs, etc. So there will
be some use for such driver. There is no native parallel port on the Mac (I
guess you all know it) but some external hardware provide this extension.
I've some code for to access the serial port that worked quite well under
OS9, I haven't done anything with OSX, but I guess this should not be too
difficult.
I guess the first step will be to define what functionalities we want in
this driver and then see what can be done under each platforms.

I'll explore what is possible under OSX and let you know

Have a good week-end

Chris 


> From: Rolf Kalbermatter <rol...@ci...>
> Reply-To: rol...@ci...
> Date: Fri, 07 Nov 2003 23:55:41 +0100
> To: 'Jim Kring' <ji...@ji...>
> Cc: chr...@ep..., ope...@li...
> Subject: RE: VISA alternative
> 
> Jim Kring [mailto:ji...@ji...] wrote:
> 
>> If anyone has been reading the info-lv thread on NI VISA licensing, you can
>> see that there is a huge demand for an open source solution for serial and
>> parallel port I/O.  NI only allows you to distribute 10 copies of your built
>> application that uses NI "Driver Software".  After that, they want $395 per
>> copy!  Sounds like a good openg project to me.  How about OpenGSerp and
>> OpenGPortIO?  I don't have the background to code up the OS interface or
>> 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.
> 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
> 
>