RE: VISA alternative

[Jim K. <ji...@ji...>]

Chris, Rolf, et al.

Ideally, it would be nice to have an interface that was identical to the =
old
serpdrv VIs (but with error IO, of course ;-):

./vi.lib/Instr/Serial.llb

However, since it is a huge task to code up such an abstraction in each
development environment, then what I would suggest is to wrap each OS's
serial API in a shared library, and doing so in a way most natural for =
that
OS.  Then, for each platform, the higher-level cross-platform API can be
written in G.  This way there can be more people helping with the
cross-platform support and the folks working on the OS layer can focus =
only
on that (also fewer shared library builds etc.).  The OpenG Package
Installer can take care of installing all of the platform specific =
stuff.

Any thoughts?

-Jim


> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Christophe Salzmann
> Sent: Sunday, November 09, 2003 12:19 AM
> To: rol...@ci...; Jim Kring
> Cc: ope...@li...
> Subject: Re: VISA alternative
>=20
>=20
> Jim, Rolf,
>=20
> I second Rolf in the fact that a generic IOPort driver might=20
> be a quite large project. On the other hand a serial driver=20
> sounds like a reasonable starting point. Now regarding the=20
> Mac, there is no serial port built-in anymore. If you want=20
> one you should either replace your internal modem or use an=20
> usb-serial converter. On the other hand you can "route" your=20
> serial line to a bluetooth connection to talk to other=20
> devices such as phone, PDAs, etc. So there will be some use=20
> for such driver. There is no native parallel port on the Mac=20
> (I guess you all know it) but some external hardware provide=20
> this extension. I've some code for to access the serial port=20
> that worked quite well under OS9, I haven't done anything=20
> with OSX, but I guess this should not be too difficult. I=20
> guess the first step will be to define what functionalities=20
> we want in this driver and then see what can be done under=20
> each platforms.
>=20
> I'll explore what is possible under OSX and let you know
>=20
> Have a good week-end
>=20
> Chris=20
>=20
>=20
> > 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...,=20
> > ope...@li...
> > Subject: RE: VISA alternative
> >=20
> > Jim Kring [mailto:ji...@ji...] wrote:
> >=20
> >> If anyone has been reading the info-lv thread on NI VISA=20
> licensing,=20
> >> you can see that there is a huge demand for an open source=20
> solution=20
> >> for serial and parallel port I/O.  NI only allows you to=20
> distribute=20
> >> 10 copies of your built application that uses NI "Driver=20
> Software". =20
> >> After that, they want $395 per copy!  Sounds like a good openg=20
> >> project to me.  How about OpenGSerp and OpenGPortIO?  I don't have=20
> >> the background to code up the OS interface or sharedlib, but I can=20
> >> help with all other aspects of the project.
> >=20
> > Well, first as I stated earlier on Info-LabVIEW I do not think that=20
> > the $395 is for a VISA runtime license but rather for the=20
> entire VISA=20
> > software, with development libraries, documentation, T&M Explorer,=20
> > VISA Interactive Control and whatever there is. Anything=20
> else would be=20
> > stupid and completely unlogical to explain, as you can buy some NI=20
> > products which come with VISA for not much more than that amount.
> >=20
> > Second I was thinking about creating an OpenG PortIO driver which=20
> > supports both the slow but simple register access of the NI=20
> solution=20
> > as well as an alternative high speed access, which needs some prior=20
> > intialization. I have all the information and even some=20
> code for Win32=20
> > here but need to clean it up and prepare a proper LabVIEW=20
> solution for=20
> > it. It will be a source code release but since you need a=20
> Windows DDK=20
> > installed to compile it, I don't think there will be many people=20
> > trying to compile it themselves, so a pre- compiled binary will be=20
> > provided as well. I have not a very good idea about how to go to=20
> > implement the same under Linux, although it shouldn't be that=20
> > difficult, but for Mac I'm completely clueless, nor if there is=20
> > actually any possible need for this on the Mac. After all you don't=20
> > have LPT and COM ports there ;-)
> >=20
> > Third trying to write a OpenG Serp driver is a pain of a=20
> thing to do.=20
> > Doing so for one plattform is already quite a serious project, but=20
> > trying to support Win32, Linux, and Mac OS X is most=20
> probably a major=20
> > undertaking, requiring more commitement from several people=20
> than most=20
> > of us are willing and able to do. You would have to=20
> abstract the Win32=20
> > COMM API on one hand, the Linux device interface on the=20
> other and the=20
> > Macintosh device driver interface (or can one maybe use the Unix=20
> > device interface without loosing to much control), which are=20
> > completely different in their design, interface, and=20
> abstraction. Of=20
> > course one could still use the disappeared Device IO Control nodes,=20
> > which LabVIEW still supports in 7.0. But there are a number=20
> of issues.=20
> > The Device IO Control interface in LabVIEW is built to=20
> interface with=20
> > the Mac Device Manager and can actually be used to call=20
> virtually any=20
> > Mac OS device driver although it never was really used for anything=20
> > but the serial port drivers. On Windows the famous serpdrv=20
> acts as a=20
> > translation between the Mac OS Device Manger interface used=20
> in LabVIEW=20
> > and the native Win32 COMM API. The architecture of this translator=20
> > driver has never been published and depends on some internal
> > tools only available by NI, but has some similarities with=20
> creating CINs.
> > On Linux I'm not exactly sure if a similar serpdrv exists=20
> or if the LabVIEW
> > Device IO Interface nodes map directly to the unix device=20
> driver interface.
> > Problem is, that I'm fairly sure that NI tries to=20
> completely disable support
> > for this interface in one of the next major releases.
> > So the only viable solution would really be over a shared=20
> library interface
> > which in itself should work quite fine as proven in lvzlib=20
> and to a lesser
> > extend in labpython.
> > Neverthless serial port programming on Win32 API level in a=20
> generic way, and
> > not just for a particular device, is anything but pleasant,=20
> and other systems
> > won't be much simpler here.
> >=20
> > Rolf Kalbermatter
> >=20
> >=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest=20
> developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20
> and more! http://www.apachecon.com/=20
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20