Menu
▾
▴
opengtoolkit-developers
|
From: Rolf K. <rol...@ci...> - 2003-11-11 09:42:05
|
Hello all, I have been thinking a lot over the weekend about this and I think there is a reasonable approach which might work. We might be able to create a modularized VISA (the current NI implementation is similar in this) which intially might support serial only. The idea is to separate the implementation of the hardware related interface driver (I think NI calls it in their architecture a passport) from the actual VISA32.DLL. LabVIEW and all other software always interfaces with VISA32.DLL only (well I guess T&M Explorer doesn't comply with this but I have really absolutely no intention of supporting T&M in the beginning, both for the fact that the interfaces it uses are entirely undocumented as well as possible license issues). OpenG Visa32.dll would enumerate the underlying passport drivers on first use and manage them accordingly. For the rest it would pass the VISA requests from application space to the according passport driver depending on the actual VISA session. It would be a plugin architecture on shared library niveau, which is also the drawback of this project. Although not inherently very complicated, it is something not every programmer is comfortable to work in as it has a serious amount of abstraction, so I'm at the moment afraid that there would be little if no active support from others for this and therefore it would silently die before it has reached any useful stage. OpenG passport drivers would intially and most probably always NOT be compatible with NI passport drivers as there is no documentation about that interface, although I have a fairly good idea how it works ;-), but the devil lies in the detail and therefore I would not want to attempt to achieve compatibility on that level unless NI might at some stage want to help. As a side node, we might be able to support PORTIO as a passport driver in this architecture as VISA has the according register access primitives although it is currently only used for PXI and VXI. Any comments to this? Rolf Kalbermatter |
|
From: Jean-Pierre D. <jea...@tr...> - 2005-01-11 00:14:52
|
In the light of recent licensing issues, I resurrect this old post from R= olf. At Avensys where I work I'm director of software development and in decis= ion regarding sofware tools we use for R&D and commercial applications. As much as I love LabVIEW I'm seriously thinking about drop= ping it for application distribution, keeping it only for internal sofware development needs. We develop our own harware. Some are stand alone devices for which we hav= e LabVIEW GUIs communicating with Serial/Modem/TCP. We also have general distributed I/O boards (using BACnet protocol mainly used in= HVAC) in which LabVIEW applications acts as data acquisition/logging servers that serves data to network and Internet Lab= VIEW clients. As such we're not a great source of revenues to NI and eventually competitors if they ever get into the BACnet arena. The prohibitive VISA licensing and the fact that NI can decide anyday tha= t our applications are compition to their own products and then against their licensing makes the use of LabIEW "complicated". Rolf, what is this visa32.dll? It seems to be a NI product so I don't thi= nk you meant OpenG VISA to be a replacement of NI-VISA. I would like to have a serial interface to get rid of VISA installation whe= n I want to use the serial port on target computers. Both licensing fees and installation footprint make no sense for me for the me= re use of the serial port. Like VISA, I 'd like to see a generic communication API where the interfa= ce would be the same whatever the actual communication channel is (serial, TCP, etc). It would be OOP so when there is a need fo= r another communication channel, just provide a specific implementation that is simply integrated. How difficult would it be to bu= ild an interface to Windows (or your favorite OS) serial drivers? Gateways (like serial<->TCP to access serial port on remote comp= uters) to connect any two different channels could also be implemented. Any comment to this? Jean-Pierre ----- Message d'origine -----=20 De : "Rolf Kalbermatter" <rol...@ci...> =C0 : <ope...@li...> Envoy=E9 : 11 novembre, 2003 04:38 Objet : OpenG VISA > Hello all, > > I have been thinking a lot over the weekend about this and I think ther= e is > a reasonable approach which might work. > > We might be able to create a modularized VISA (the current NI implement= ation > is similar in this) which intially might support serial only. The idea = is to > separate the implementation of the hardware related interface driver (I= think > NI calls it in their architecture a passport) from the actual VISA32.DL= L. > > LabVIEW and all other software always interfaces with VISA32.DLL only (= well > I guess T&M Explorer doesn't comply with this but I have really absolut= ely > no intention of supporting T&M in the beginning, both for the fact that= the > interfaces it uses are entirely undocumented as well as possible licens= e > issues). > > OpenG Visa32.dll would enumerate the underlying passport drivers on fir= st use > and manage them accordingly. For the rest it would pass the VISA reques= ts from > application space to the according passport driver depending on the act= ual VISA > session. It would be a plugin architecture on shared library niveau, wh= ich is > also the drawback of this project. Although not inherently very complic= ated, it > is something not every programmer is comfortable to work in as it has a= serious > amount of abstraction, so I'm at the moment afraid that there would be = little > if no active support from others for this and therefore it would silent= ly die > before it has reached any useful stage. > > OpenG passport drivers would intially and most probably always NOT be c= ompatible > with NI passport drivers as there is no documentation about that interf= ace, > although I have a fairly good idea how it works ;-), but the devil lies= in the > detail and therefore I would not want to attempt to achieve compatibili= ty on > that level unless NI might at some stage want to help. > > As a side node, we might be able to support PORTIO as a passport driver= in this > architecture as VISA has the according register access primitives altho= ugh it is > currently only used for PXI and VXI. > > Any comments to this? > > Rolf Kalbermatter > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers |
|
From: Rolf K. <rol...@ci...> - 2005-01-11 10:23:52
|
Hi Jean-Pierre, > Rolf, what is this visa32.dll? It seems to be a NI product so=20 > I don't think you meant OpenG VISA to be a replacement of NI-VISA. Well, the VXI PnP Alliance has made a standard available in the form of VISA. And yes in sense if you want to do your own VISA you will have to replace VISA32.DLL. This is the common API to all VISA services and this DLL then will distribute the commands to the according lower level driver according to the VISA resource identifier. It is unfortunate that VISA32.DLL has to be replaced entirely but that is the way it was designed. I'm not entirely sure how HP does it but I feel that if you install HP hardware for instance you seem to have some sort of problem in that you need to decide if you want to have NI-VISA and only use a limited set of HP hardware supported by it or install HP VISA and only have limited support for standard NI hardware. The interface between VISA32.DLL and the low level drivers is nowhere documented that I could find it and although I have a fairly good general idea how it is done, trying to figure out all the nitty gritty details is really a big nono, so the most straightforward method is indeed replacing VISA32.DLL altogether to get rid of any possible NI licensing issues. This however has some implications. In that way you won't have support for any interface unless there is an approapriate OpenG (or whatever) low level VISA driver avaialable. While I started with the ASRL driver already (but it is by no means near a working state yet) I have no idea how complicated the addition of drivers for GPIB, TCP/IP, USB etc might be. GPIB seems fairly straightforward to me but I haven't really looked into that yet. > would like to have a serial interface to get rid of VISA=20 > installation when I want to use the serial port on target=20 > computers. Both licensing fees and installation footprint > make no sense for me for the mere use of the serial port. I would estimate the base driver to be around 100k for the VISA32.DLL and at most 100k for each low level driver. There probably would have to be a small UI application for configuration tasks too, although that could be handled through ini files entirely for starters.=20 > Like VISA, I 'd like to see a generic communication API where=20 > the interface would be the same whatever the actual communication > channel is (serial, TCP, etc). It would be OOP so when there=20 > is a need for another communication channel, just provide a specific > implementation that is simply integrated. How difficult would=20 > it be to build an interface to Windows (or your favorite OS) serial > drivers? Gateways (like serial<->TCP to access serial port on=20 > remote computers) to connect any two different channels could also be > implemented. Well it is C programming and support in that area is very limited in the LabVIEW community. I have had no positive feedback until now and can't possibly take on this task alone. For this reasons I postboned further work for the time being. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:rol...@ci... =20 |
|
From: Rolf K. <rol...@ci...> - 2005-01-13 10:09:49
|
One more comment here: > Rolf, what is this visa32.dll? It seems to be a NI product so=20 > I don't think you meant OpenG VISA to be a replacement of NI-VISA. I > would like to have a serial interface to get rid of VISA=20 > installation when I want to use the serial port on target=20 > computers. Both licensing fees and installation footprint > make no sense for me for the mere use of the serial port. Instead of replacing VISA32.DLL we could create for the time being a library which is in principle compatible and built on the same architecture but name it for instance ogvisa.dll/shl/... Then a VI library could be created which looks and feels like the VISA icons to access that library. This would avoid the problem of rendering normal NI resources unavailable while testing or using the OpenG version in your application but would still give the same look and feel to using it. Once it is working properly for some resources, with a single compile switch a real visa32.dll could be created if anyone wants to test or use it with the built in nodes instead of relying on the NI or HP version. Rolf Kalbermatter |
|
From: Michael A. <mic...@im...> - 2005-01-13 14:32:23
|
Hi gents, I have been out of the VXI plug-n-play and VISA arema for a while, so forgi= ve me for asking this, but, Rolf and others mention HP and NI VISA librarie= s, but no one else. VISA is an open standard. Does any other company beside= s HP & NI have a VISA implementation? Cheers, Mike Ashe **************************** Imaginatics 860-444-2141 mic...@im... **************************** ---- ope...@li... wrote: > Instead of replacing VISA32.DLL we could create for the time being > a library which is in principle compatible and built on the same > architecture but name it for instance ogvisa.dll/shl/... > ... snip... > Once it is working properly ... anyone wants to test or use it=20 > ... instead of relying on the NI or HP version. >=20 > Rolf Kalbermatter |
|
From: John R. <jr...@ke...> - 2005-01-13 15:05:41
|
yes,=20tektronix=20have=20visa -----Original=20Message----- From:=20o...@li... [mailto:ope...@li...]On=20Behalf=20= Of Michael=20Ashe Sent:=20Thursday,=20January=2013,=202005=209:32=20AM To:=20o...@li... Subject:=20RE:=20OpenG=20VISA Hi=20gents, I=20have=20been=20out=20of=20the=20VXI=20plug-n-play=20and=20VISA=20arema=20= for=20a=20while,=20so=20forgive=20me=20for=20asking=20this,=20but,=20Rolf=20= and=20others=20mention=20HP=20and=20NI=20VISA=20libraries,=20but=20no=20on= e=20else.=20VISA=20is=20an=20open=20standard.=20Does=20any=20other=20compa= ny=20besides=20HP=20&=20NI=20have=20a=20VISA=20implementation? Cheers, Mike=20Ashe **************************** Imaginatics=20=20=20=20=20860-444-2141 mic...@im... **************************** ----=20o...@li...=20wrote: >=20Instead=20of=20replacing=20VISA32.DLL=20we=20could=20create=20for=20th= e=20time=20being >=20a=20library=20which=20is=20in=20principle=20compatible=20and=20built=20= on=20the=20same >=20architecture=20but=20name=20it=20for=20instance=20ogvisa.dll/shl/... >=20...=20snip... >=20Once=20it=20is=20working=20properly=20...=20anyone=20wants=20to=20test= =20or=20use=20it=20 >=20...=20instead=20of=20relying=20on=20the=20NI=20or=20HP=20version. >=20 >=20Rolf=20Kalbermatter ------------------------------------------------------- The=20SF.Net=20email=20is=20sponsored=20by:=20Beat=20the=20post-holiday=20= blues Get=20a=20FREE=20limited=20edition=20SourceForge.net=20t-shirt=20from=20Th= inkGeek. It's=20fun=20and=20FREE=20--=20well,=20almost....http://www.thinkgeek.com/= sfshirt _______________________________________________ OpenGToolkit-Developers=20mailing=20list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers __________________________________________________________________________= ___ Scanned=20by=20IBM=20Email=20Security=20Management=20Services=20powered=20= by=20MessageLabs.=20For=20more=20information=20please=20visit=20http://www= .ers.ibm.com __________________________________________________________________________= ___ __________________________________________________________________________= ___ Scanned=20by=20IBM=20Email=20Security=20Management=20Services=20powered=20= by=20MessageLabs.=20For=20more=20information=20please=20visit=20http://www= .ers.ibm.com __________________________________________________________________________= ___ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X