opengtoolkit-developers — OpenG Toolkit developers mailing list

Re: OpenG Serial Port API

[<alb...@ph...>]

Good start Martin

I attach a use case that even VISA does not handle nicely.

One of the problems with the VISA serial implementation is that after 
opening the port you have to specify extra settings before using the 
channel.
VISA takes the default settings from the operating system but normally you 
 initialize these settings after opening in VISA.
This is shown in the new templates for instrument drivers. Only for serial 
you have a special VI to configure the port.
It not only makes instrument driver VI's look ugly but also has some weird 
effects on ports when changing the baudrate after already initializing the 
port.
Sometimes the instrument chokes on an inadvertently send hiccup on the 
line. 
It would be nice to inform the operating system of new "default values" 
before really initializing the port..

I worked out a way to add these settings to a VISA resource name but did 
not yet inform the operating system.
something like    ASRL1::INSTR ;baudrate=9600;parity=even
In fact my application accepts the eventual hiccup after opening the port 
because I did not have the time to sort out how to inform the OS.

If you are interested I can send you the VI's but 
So even when using VISA for serial we need such a special serial open.

Albert Geven                                         Tel  +31 (0)40 27 
43019
Philips Research                                 Fax +31 (0)84 722 9844
prof Holstlaan 4        WAA01             Email  alb...@ph...
5656AA Eindhoven

OpenG Serial Port API

[Martin H. <mar...@mh...>]

Hello Jim,

I was a little bit off, but now the first description of the
project  is  available  (see  the  attached  lvserial.html).
Because  my  english  is not the best, I would prever if you
are correcting this text.

I've  only  set the font and font size inside the html file.
If you like to have more formatting elements I'll do that.

-- 
Martin Henz

RE: OpenG MSI Installer Builder

[Jim K. <jim...@ja...>]

Konstantin Shifershteyn wrote:
> 
> I believe the installer is ready for release (as an 
> independent tool yet) and testing. I prepared
> ogmsiib.spec file for the packager but not sure if
> all info is correct. Please verify it  and make
> changes if any needed.
> 

Kostya,

This is exciting!  We can now create MSI Installers from applications built
by OpenG Builder.

I have released the package as "ogrsc_msi_builder".  It is now available for
download using OpenG Commander.

Please make an announcement in the Builder Announcements forum:

	"Builder Announcements Forum"
	http://forums.openg.org/viewforum.php?f=18

Please also reply to this post:

	"Are there plans for Installer creation?"
	http://forums.openg.org/viewtopic.php?t=58

Thanks again for your continued hard work on the Builder and MSI Installer
Builder.

Regards,

-Jim Kring

Re: OpenGToolkit-Developers digest, Vol 1 #108 - 2 msgs

[Josh J. <Joh...@Or...>]

What about not only a forum but some kind of ranking system where
ideas/proposals could be listed and ranked in order of priority and brought
up or doled out on a regular basis... something like that? just a thought.
~Josh~

=============


Hello OpenG Developers,

As most of you know, the OpenG Commander alpha version has been released
and
it is being used by many people to automatically obtain and install OpenG
Packages directly from the Internet.  This is a great success.  Now it is
possible to give some attention to the various OpenG Library packages.
There is a HUGE backlog of submissions and feature requests sitting in my
inbox.  The question now becomes, "how do we manage all of these?"  We
should be careful not to simply add new VIs or change existing VIs, but to
be very meticulous in ensuring that any changes are well thought-out.

I propose that we have some sort of review process, whereby any proposed
feature or submission can be viewed, downloaded, and tested by anyone for
some minimum period of time (maybe 30 days).  We can use the discussion
forums for obtaining feedback on the proposal and use the feedback as a
basis for making a good decision.  I think that this is also a very good
way
to get people involved.  For example, if people know that there is a place
to view, download, and discuss project proposals then we are likely to get
a
lot more participation in our process.

Any thoughts?

-Jim Kring

--
James Kring, Inc.
415.720.5972 phone
415.366.3299 fax
jk...@ja...
http://jameskring.com <http://jameskring.com/>

RE: Submission review process

[Paul F. S. <Pa...@SU...>]

Jim,

A formal process would help a lot.

I had voiced the question of a preferred location for the Commander 
cache when I first got the alpha but it fell through the cracks until 
I ran into problems because of a poor choice of location. As you 
know, that got answered immediately in the OpenG forum. So the forum 
is a great idea for handling development feedback.

-- 
	Paul F. Sullivan

----------------------------------------------------

	SULLutions		(781)769-6869
	"when a single discipline is not enough"

	visit http://www.SULLutions.com

----------------------------------------------------

RE: Submission review process

[Jim K. <jk...@ja...>]

Hello, All
 
There are already a few submissions that you can review.  Please take a look
and provide your input.
 
http://forums.openg.org/viewforum.php?f=13
 
Regards,
 
-Jim


  _____  

From: ope...@li...
[mailto:ope...@li...] On Behalf Of
Jim Kring
Sent: Thursday, February 03, 2005 9:14 AM
To: ope...@li...;
ogp...@li...
Subject: Submission review process


Hello OpenG Developers,
 
As most of you know, the OpenG Commander alpha version has been released and
it is being used by many people to automatically obtain and install OpenG
Packages directly from the Internet.  This is a great success.  Now it is
possible to give some attention to the various OpenG Library packages.
There is a HUGE backlog of submissions and feature requests sitting in my
inbox.  The question now becomes, "how do we manage all of these?"  We
should be careful not to simply add new VIs or change existing VIs, but to
be very meticulous in ensuring that any changes are well thought-out.
 
I propose that we have some sort of review process, whereby any proposed
feature or submission can be viewed, downloaded, and tested by anyone for
some minimum period of time (maybe 30 days).  We can use the discussion
forums for obtaining feedback on the proposal and use the feedback as a
basis for making a good decision.  I think that this is also a very good way
to get people involved.  For example, if people know that there is a place
to view, download, and discuss project proposals then we are likely to get a
lot more participation in our process.
 
Any thoughts?
 
-Jim Kring
 
--
James Kring, Inc.
415.720.5972 phone
415.366.3299 fax
jk...@ja...
http://jameskring.com <http://jameskring.com/> 
 

RE: Submission review process

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

  -----Original Message-----
  From: ope...@li... =
[mailto:ope...@li...]On Behalf Of =
Jim Kring
  Sent: Thu, February 03, 2005 18:14
  To: ope...@li...; =
ogp...@li...
  Subject: Submission review process


  Hello OpenG Developers,

  As most of you know, the OpenG Commander alpha version has been =
released and it is being used by many people to automatically obtain and =
install OpenG Packages directly from the Internet.  This is a great =
success.  Now it is possible to give some attention to the various OpenG =
Library packages.  There is a HUGE backlog of submissions and feature =
requests sitting in my inbox.  The question now becomes, "how do we =
manage all of these?"  We should be careful not to simply add new VIs or =
change existing VIs, but to be very meticulous in ensuring that any =
changes are well thought-out.

  I propose that we have some sort of review process, whereby any =
proposed feature or submission can be viewed, downloaded, and tested by =
anyone for some minimum period of time (maybe 30 days).  We can use the =
discussion forums for obtaining feedback on the proposal and use the =
feedback as a basis for making a good decision.  I think that this is =
also a very good way to get people involved.  For example, if people =
know that there is a place to view, download, and discuss project =
proposals then we are likely to get a lot more participation in our =
process.=20
Seems fine with me. Also as a side note, the lvzip library needs still a =
Linux build of the shared library for the new version. I was planning on =
doing that but haven't been able to, and as it looks at the moment I'm =
so deep into work that I can't spend much time on OpenG libraries at the =
moment.

The problem at the moment is indeed, that unreleased OpenG packages are =
only available over CVS, either direct CVS or the sourceforge Web based =
CVS interface. For a lot of users this is a to big hurdle to take, to =
try out new software.

Rolf Kalbermatter

Submission review process

[Jim K. <jk...@ja...>]

Hello OpenG Developers,
 
As most of you know, the OpenG Commander alpha version has been released and
it is being used by many people to automatically obtain and install OpenG
Packages directly from the Internet.  This is a great success.  Now it is
possible to give some attention to the various OpenG Library packages.
There is a HUGE backlog of submissions and feature requests sitting in my
inbox.  The question now becomes, "how do we manage all of these?"  We
should be careful not to simply add new VIs or change existing VIs, but to
be very meticulous in ensuring that any changes are well thought-out.
 
I propose that we have some sort of review process, whereby any proposed
feature or submission can be viewed, downloaded, and tested by anyone for
some minimum period of time (maybe 30 days).  We can use the discussion
forums for obtaining feedback on the proposal and use the feedback as a
basis for making a good decision.  I think that this is also a very good way
to get people involved.  For example, if people know that there is a place
to view, download, and discuss project proposals then we are likely to get a
lot more participation in our process.
 
Any thoughts?
 
-Jim Kring
 
--
James Kring, Inc.
415.720.5972 phone
415.366.3299 fax
jk...@ja...
http://jameskring.com <http://jameskring.com/> 
 

RE: real time

[Jim K. <jk...@ja...>]

Tony,

I replied to your support request:

http://forums.openg.org/viewtopic.php?t=28

Regards,

-Jim

> -----Original Message-----
> From: ope...@li... 
> [mailto:ope...@li...] 
> On Behalf Of Toni Sierra Fuentes
> Sent: Tuesday, February 01, 2005 7:04 AM
> To: ope...@li...
> Subject: real time
> 
> 
> Hello. I'm working in a real time application with a cfp-2020 and 
> I need to save the data a database. To run the sql toolkit, I 
> need to install de mdac executable (ODBC drivers). What can I 
> do to install this drivers??? I have the microsoft exe and i don't 
> know the way to install this drivers into the compact field point.
> 
> Thanks!!! Bye.
> 
>  
> 
> 

real time

[Toni S. F. <ton...@ya...>]

Hello. I'm working in a real time application with a cfp-2020 and 
I need to save the data a database. To run the sql toolkit, I 
need to install de mdac executable (ODBC drivers). What can I 
do to install this drivers??? I have the microsoft exe and i don't 
know the way to install this drivers into the compact field point.

Thanks!!! Bye.

 

Re: labsql and cfp-2020

[Jim K. <jk...@ja...>]

Toni,

As this is a developers mailing list, I have answered your support
question in the OpenG support forums.  Here is a link to the forums, where
you can find your answer:

http://forums.openg.org/viewtopic.php?t=28

Regards,

-Jim Kring



Toni Sierra Fuentes wrote:
>
> Hello. I'm developing an application in LabView and I using de
>  Labsql toolkit. Now, when I embedded t'he applilcation, I
> don't know what I must do to save the data in a access
> database. I need to save the libraries in the cfp-2020
> memory??? When I can found this information???
>
> Thanks. Bye.
>
>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> OpenGToolkit-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>


-- 
Jim Kring
James Kring, Inc.
jk...@ja...
415.720.5972 phone
415.366.3299 fax
http://www.jameskring.com

labsql and cfp-2020

[Toni S. F. <ton...@ya...>]

Hello. I'm developing an application in LabView and I using de
 Labsql toolkit. Now, when I embedded t'he applilcation, I
don't know what I must do to save the data in a access
database. I need to save the libraries in the cfp-2020
memory??? When I can found this information???
 
Thanks. Bye.

 

RE: Proposal to write a serial driver

[Jim K. <jk...@ja...>]

This may not solve the problem, but...

VISA controls/indicators have a property called UpdatedTagList[] which
queries the VISA driver and returns the latest list of items available (in
LV 7.1, but I haven't checked previous versions).

-Jim Kring

> -----Original Message-----
> From: ope...@li... 
> [mailto:ope...@li...] 
> On Behalf Of Rolf Kalbermatter
> Sent: Sunday, January 16, 2005 4:11 PM
> To: ope...@li...
> Subject: RE: Proposal to write a serial driver
> 
> Martin Henz wrote:
> 
> > I have to change my job or my customers, before I can change
> > the oS :->
> > 
> > I  don't know who really is responsible for this effect, but
> > I  can  access  the  serial ports if I call the OS functions
> > directly (without VISA).
> 
> I think you can do so as well in VISA. The problem is that the
> pop-up menu is not dynamically repopulated whenever the resources
> change. But VISA should probably be able to access a port as soon
> as it gets available. Just use a VISA resource control which
> allows for undefined resources or use a sting control instead.
> The VISA Node will automatically coerce that string in a VISA
> resource.
> 
> Rolf Kalbermatter
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> OpenGToolkit-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
> 

RE: Proposal to write a serial driver

[Scott H. <st...@ma...>]

At 1:11 +0100 1/17/05, Rolf Kalbermatter wrote:
>Martin Henz wrote:
>> I have to change my job or my customers, before I can change
> > the oS :->
Which came first, the chicken or the OS?


> > I  don't know who really is responsible for this effect, but
>> I  can  access  the  serial ports if I call the OS functions
>> directly (without VISA).
>
>I think you can do so as well in VISA. The problem is that the
>pop-up menu is not dynamically repopulated whenever the resources
>change. But VISA should probably be able to access a port as soon
>as it gets available.
I got this tip from a VISA developer awhile back.  It didn't seem to work for me at the time and I worked around it another way.  I started messing with some settings in the visaconf file and they got into my master copy that was destributed and hosed all my systems.....  Those darn rusty nails in the attic.

But this is a possible solution FWIW.  The goal was to programmatically read the VISA conf file with the config file VIs (it almost works, but works well enough) and then could set aliases for the various VISA ports.  (IE "Blue HP DMM" for GPIB0::5::INSTR, etc.)

>Scott,
>
>I do believe that I have a solution to your question about programmatically
>updating the list the VISA I/O control displays.  First of all, I would
>like to say that this is a round-about way of doing it and that we cannot
>guarantee that it will continue to work in future versions of LabVIEW.
>That being said, however, it is unlikely that we will change the behavior.
>To programmatically force a refresh:
>1)  Touch the visaconf.ini file (ie so that the modified date on the file
>changes)
>2)  Using a property node for the VISA I/O control, set the "Visible"
>property to FALSE
>3)  Using a property node for the VISA I/O control, set the "Visible"
>property to TRUE
>
>This will force a refresh: whenever the VISA I/O control becomes visible,
>LabVIEW asks VISA if it needs a refresh.  VISA checks to see if the
>visaconf.ini file was changed since it last read it.  Since you touched the
>file, VISA believes that a change has occurred and will actually perform
>the refresh and LabVIEW will display the new results in the VISA I/O
>control.
>
>Also, changing the "Refresh" settings in the visaconf.ini will not help
>solve your problem.  Some of them are not even used any longer.  Must
>likely, visaconf.ini will be cleaned up to remove the unused settings to
>avoid future confusion.

Re: Proposal to write a serial driver

[Martin H. <mar...@mh...>]

Rolf Kalbermatter wrote:

> Martin Henz wrote:

>> I have to change my job or my customers, before I can change
>> the oS :->
>> 
>> I  don't know who really is responsible for this effect, but
>> I  can  access  the  serial ports if I call the OS functions
>> directly (without VISA).

> I think you can do so as well in VISA. The problem is that the
> pop-up menu is not dynamically repopulated whenever the resources
> change. But VISA should probably be able to access a port as soon
> as it gets available. Just use a VISA resource control which
> allows for undefined resources or use a sting control instead.
> The VISA Node will automatically coerce that string in a VISA
> resource.

No,  that  does  not  work.  It  might be normally possibly,
because  I  can't  remember  that  I  have  seen this effect
before.  But  I  had  some  strange  effects  in the past on
customers  PCs  where VISA sometimes said, that the resource
is not available and sometimes not.

-- 
Martin Henz

RE: Proposal to write a serial driver

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

Martin Henz wrote:

> I have to change my job or my customers, before I can change
> the oS :->
>=20
> I  don't know who really is responsible for this effect, but
> I  can  access  the  serial ports if I call the OS functions
> directly (without VISA).

I think you can do so as well in VISA. The problem is that the
pop-up menu is not dynamically repopulated whenever the resources
change. But VISA should probably be able to access a port as soon
as it gets available. Just use a VISA resource control which
allows for undefined resources or use a sting control instead.
The VISA Node will automatically coerce that string in a VISA
resource.

Rolf Kalbermatter

Re: Proposal to write a serial driver

[Martin H. <mar...@mh...>]

Scott Hannahs wrote:

> At 22:23 +0100 1/16/05, Martin Henz wrote:

>>Start  your  MS Win PC, and if the OS is up and running plug
>>in a USB to serial converter, then start a labview and place
>>a  VISA  control onto the front panel. This VISA control did
>>not  show the new serial port. You are also unable to access
>>this  serial port trough VISA. - Ok, I have tested this only
>>on two different PC's, both with win XP.

> Get a better OS?

[...]

I have to change my job or my customers, before I can change
the oS :->

I  don't know who really is responsible for this effect, but
I  can  access  the  serial ports if I call the OS functions
directly (without VISA).

-- 
Martin Henz

Re: Proposal to write a serial driver

[Scott H. <st...@ma...>]

At 22:23 +0100 1/16/05, Martin Henz wrote:
>While  most  people  are  talking about the licencing issue,
>nobody  seems  to  talk  about  disadvatages  of  the actual
>NI-VISA implementeation and the way it works.

Good point.  The VISA implementation is to keep generality and isolate what is specific to certain interfaces.  This takes careful thought.  There are some major problems I ran into with NI VISA (wait till next week when I post some timing performance issues to info-labview).

>Start  your  MS Win PC, and if the OS is up and running plug
>in a USB to serial converter, then start a labview and place
>a  VISA  control onto the front panel. This VISA control did
>not  show the new serial port. You are also unable to access
>this  serial port trough VISA. - Ok, I have tested this only
>on two different PC's, both with win XP.

Get a better OS?  To be honest, OS X is written from the ground up to handle networks going in and out and USB, etc.  I can add serial ports  on the fly to OS X.  While a VI is running and it will pick them up. The VISA control doesn't always show them, but they can be opened and used.  I try not to show my bias too often, but here, the machines are same cost, better capabilities, and a *LOT* less pain to use.

>VISA  Lock  and  Unlock are working as described, but that's
>not  a  useful  locking  mechanism for the serial port on MS
>Win.  Nobody  needs  to  give  a process exclusive access to
>anything he already has.
Well it is general and can work on other OSs usefully!.  It also has some weird effects that recently surprised me!

>The  Termination  Character  is  a  nice thing, but for some
>devices  with horrible protocols I would prefer to have more
>than   one   Termination   Character   and/or  one  or  more

The NL serial library had multiple characters, but not multiple strings.  A good thing to implement!

-Scott

Re: Proposal to write a serial driver

[Martin H. <mar...@mh...>]

Hi John,

John Brohan wrote:

> This information about the 10 or 100 copies is new to me. I think that
> it changes the discussion completely.

No,  it does not really change anything, because this is not
really new.

> I  have  written  to  my  local  rep and hopefully he will
> confirm this.

I think he will confirm this, but up to now nobody has shown
me  a  licence  agreement  wich explains this 10 or 100 free
copies and I havn't found it up to now in any of the NI-VISA
licences. But I havn't read all NI-VISA licences.

Maybe,  this  10  or  100  free  copies are a decision of NI
beside  the  licence agreement. Should I ask NI for the free
copies whenever I wants to distribute a application?

> There are other projects I could better spend my efforts on.

Oh yes, I'm too.

Please read what Scott Hannahs explained in Info-LabVIEW:

> Well the problem is not if it is 10 or 100.  That is rearranging the deck chairs.
> Suppose I write an application that uses serial.  I think it is cool and put it out on
> my web site.  Do I put a note that the first 100 people who download it can use it,
> but the next 100 are SOL?  Do I keep track of it by number of downloads and then have
> to remove it from the web site?  Do I have to count downloads by web indexing spiders?
> 
> Once I reach the 100 limit, can I take it down, change the version number and put it
> back up as a different application?  Does the 100 distributions take over then? 
> Despite being written by very exacting lawyers this license agreement doesn't make
> sense (translation: it's flakin' stupid!).
> 
> It is nice to raise the limit but it doesn't address the fundamental problem.
> 
> NI sells their own serial board (which some folks have complained about the price)
> but it claims much higher performance due to better drivers/hardware combination. 
> That means that NI is competing on the quality of their product.  To put this kind of
> restriction on use of all serial ports is trying to squeeze out another fee without
> providing that kind of performance advantage.  Charging people to use the hardware
> they already purchased is a bit over the top.
> 
> Next is a distribution fee if your application actually draws on a video screen?  Use
> of the LabVIEW graphics libraries is obviously something that should be charged for? 
> Maybe it is a basic question of what the hell are you paying for when you buy LV?  Is
> it a data acquisition and control language or just a stripped down IDE where you need
> to purchase a slew of addons to use it as a product development platform.
> 
> I am glad that NI is considering changes in this license agreement.  Some time they
> should have their alliance members talk to management about what keeps all of them in
> business.  If they plan on eating their seed corn and squeezing the alliance members,
> then the agreement will reflect that.  Other than that, NI management should be the
> ones controlling the lawyers instead of vice-versa which seems to be the obvious
> conclusion from reading the license agreement.
> 
> Next, we start to talk about the non-compete clause?
>
> -Scott

Now  you  can  decide  if  you  really  want  to  stop  your
activities  for  an OpenG Serial Port API. But, whatever you
do,  I'll  continue  (as  an  OpenG  project or at any other
place).

While  most  people  are  talking about the licencing issue,
nobody  seems  to  talk  about  disadvatages  of  the actual
NI-VISA implementeation and the way it works. A view example
(all of them for the serial port and for the windows OS):

Start  your  MS Win PC, and if the OS is up and running plug
in a USB to serial converter, then start a labview and place
a  VISA  control onto the front panel. This VISA control did
not  show the new serial port. You are also unable to access
this  serial port trough VISA. - Ok, I have tested this only
on two different PC's, both with win XP.

VISA  Lock  and  Unlock are working as described, but that's
not  a  useful  locking  mechanism for the serial port on MS
Win.  Nobody  needs  to  give  a process exclusive access to
anything he already has.

The  Termination  Character  is  a  nice thing, but for some
devices  with horrible protocols I would prefer to have more
than   one   Termination   Character   and/or  one  or  more
Termination Strings.


-- 
Martin Henz

Proposal to write a serial driver

[John B. <jb...@Tr...>]

Hello Martin

This information about the 10 or 100 copies is new to me. I think that 
it changes the discussion completely. I have written to my local rep and 
hopefully he will confirm this.

There are other projects I could better spend my efforts on. I am 
interested in Trees and also the handling of global variables. Maybe 
when/if this serial driver issue calms down I'll put my work here on 
OpenG and get them debugged completely and polished up to the standard 
of the other tools in the toolkit.

Yours Sincerely
John Brohan
-- 
John Brohan         National Instruments LabVIEW expert in Montreal
Traders Micro         "We connect all sorts of things to computers"
317 Barberry Place DDO Montreal PQ Canada H9G 1V3 Tel (514)995-3749
jb...@Tr...      http://www.TradersMicro.com

RE: OpenG Serial drivers

[Jim K. <jk...@ja...>]

 
Martin Henz wrote:
> 
> Jim Kring wrote:
> 
> > Assuming that we are legally allowed do distribute the
> > files, aggregating them on OpenG.org is fine with me.
> > There are many mechanisms for doing this.  I recommend
> > that we create a forum topic and attach the documents
> > to the initial forum posting.  This will allow others
> > to download the documents and directly start a
> > discussion.
> 
> > If we are not allowed to (re)distribute the files, then
> > I recommend hyperlinking to the files, rather than posting
> > them on OpenG.org.
> 
> Thank's, thats a great idea.
> 
> > Please wait to post any files to OpenG.org until we 
> "go-live" with the new
> > discussion forums.  The new forums will provide a lot of 
> nice features.
> > We have only a few minor things to do before we are ready.
> 
> I  think, that the VISA discussion started a long time ago -
> since  LabVIEW  4.1  or so. And I remember that I don't like
> some  of  the  legacy serial port driver disatvantages since
> the  time  I  moved  from  LabVIEW  2.5.1  on  MAc to 3.1 on
> windows.
> 
> We are not in hurry :-)
> 

The new discussion forums are up and running.  I have started a discussion
topic called "OpenG Serial Drivers" here:

http://forums.openg.org/viewtopic.php?t=12

If you already have an OpenG.org user account (from the old website), use
the "I forgot my password" link to have your password reset and a new one
emailed to you.

Regards,

-Jim

OpenG.org website upgrade

[Jim K. <jk...@ja...>]

Hello, OpenG members.

We are starting the new year with some exciting changes at OpenG.org!  We
have reorganized the content, upgraded the server, and developed a more
stylish user interface.  All of this was done in an effort to create a more
enjoyable user experience.  You will notice that it is much easier to find
information at OpenG.org and easier to download and install OpenG software
products.  Visit http://www.openg.org for more info.

We encourage you to start discussing OpenG related topics in the new
discussion forums.  These have been upgraded and are now faster and easier
to use.  We hope this makes you successful in using and participating in
OpenG.

To log into the forums, you will need to reset your password.  You can do
this at the following location:
http://forums.openg.org/profile.php?mode=sendpassword

This page is also available from:
http://forums.openg.org >> "Log in" >> "I forgot my password".

Best Regards, and thank you for supporting OpenG.

The OpenG Web Team
http://www.openg.org

RE: OpenG Serial drivers

[<Dou...@mk...>]

Folks, here is some more confirmation and information on this topic from
our local NI field engineer, Steve Schiffhauer.  In the interest of brevity
and clarity I have omitted the intervening series of e-mails between Matt
Dennie (who also works at MKS), Steve, and myself.  Doug Femec

----- Forwarded by Doug Femec/US/MKS on 01/14/2005 04:33 PM -----

Matt & Doug,

Sorry for 2 e-mails here.  (I didn't see Matt's second e-mail)  The Product
Manager told me that by the end on next month, this will all be documented
on a web page for customers.  He understood the confusion in our current
licenses and as part of this 10 free to 100 free licensing change, he is
moving to better document our policies for both internal and external
customers.

Steve

-----------------------------------------------------------------------------------------



Steve Schiffhauer
Field Engineer
National Instruments
3177 Latta Rd #322
Rochester, NY  14612

(585) 723-2005
ste...@ni...


----- Forwarded by Doug Femec/US/MKS on 01/14/2005 04:33 PM -----

Doug,

I just spoke to the Product Manager for GPIB, VISA, etc last night.  He
confirmed what this e-mail said.  The first 100 installations are free.

Steve

-----------------------------------------------------------------------------------------



Steve Schiffhauer
Field Engineer
National Instruments
3177 Latta Rd #322
Rochester, NY  14612

(585) 723-2005
ste...@ni...



|---------+--------------------------------------------------->
|         |           "Mark Balla" <mb...@Ch...>    |
|         |           Sent by:                                |
|         |           ope...@li...ur|
|         |           ceforge.net                             |
|         |                                                   |
|         |                                                   |
|         |           01/13/2005 04:47 PM                     |
|         |           Please respond to                       |
|         |           opengtoolkit-developers                 |
|         |                                                   |
|---------+--------------------------------------------------->
  >----------------------------------------------------------------------------------------------|
  |                                                                                              |
  |       To:       "'ope...@li...'"                            |
  |        <ope...@li...>                                       |
  |       cc:       "Adam. Sweet (E-mail)" <ada...@ni...>                                   |
  |       Subject:  RE: OpenG Serial drivers                                                     |
  >----------------------------------------------------------------------------------------------|




The Wisconsin User Group Steering comity Just recently ask our District
Sales Manager this NI Visa question.
He did some research and replied with this response.


Good afternoon all,


The $395 NI-VISA license is only applicable if you are building your own
hardware and would like to use the NI-VISA layer.


Today, our licensing policy DOES NOT require a customer to pay a licensing
fee for NI-VISA if the deployment target contains NI hardware or software
written using NI development software. In the scenario where you have a
LabVIEW VI or EXE talking on a built-in serial port, National Instruments
allows the first 10 distributions for free and after that we require a
licensing fee.  We are about to change our licensing policy to allow up to
100 distributions per application for free and after that require a
license.


So the short story is that if you are an end-user or alliance member, this
is a non-issue and NI-VISA will continue to be free.


Thank you,


Adam Sweet


        Mark Balla
        Sr. Test Engineer
        Cherry Electrical Products
        11200 88th Ave.
        Pleasant Prairie, WI
        53158-0913
        Phone:  262-942-6420
        Cell:      847-721-2047
        Fax:      262-942-6411
        Email    mb...@ch...



This e-mail is intended solely for the person or entity to which it is
addressed and may contain confidential information.  Any review,
dissemination, copying, printing or other use of this e-mail by persons or
entities other than the addressee is prohibited. If you have received this
e-mail in error, please contact the sender immediately and delete the
material from any computer.

Re: OpenG Serial drivers

[Michael A. <mic...@im...>]

Martin outlines a lot of good concerns below. NI's rep, Adam Sweet, said:=
=20

"The $395 NI-VISA license is only applicable if you are building your own h=
ardware and would like to use the NI-VISA layer."
... In the scenario where you have a LabVIEW VI or EXE talking on a built-i=
n serial port, NI allows the first 10 distributions for free and after that=
 we require a licensing fee.  We are about to change our licensing policy t=
o allow up to 100 distributions per application for free and after that req=
uire a license.
So the short story is that if you are an end-user or alliance member, this
is a non-issue and NI-VISA will continue to be free."
       =20
So what about if we are just trying to support a new application, to which =
anyone can connect serial (or VXI/GPIB, ie, VISA instruments) and we do not=
 manufacture hardware? And I second the issue with how do we maintain contr=
ol over how many copies are out there? With Open Source tools and applicati=
ons we obviously want there to be as many copies out in the wild as possibl=
e.

It seems to me that this scenario is exactly what NI was targeting when the=
y implemented NISLA clause 1.E. to try to limit applications that:

<PARAPHRASE>"replace, by themselves or *in combination with other component=
s* the software or [other NI tools]" </PARAPHRASE>

I guess the bottom line is that we need an open source serial and/or VISA a=
nd even if NI allows 100 (or 1000) copies that we still won't be out from u=
nderneath the licensing issues.

Mike Ashe

---- ope...@li... wrote:
>
> Hi Mark,
>=20
> Mark Balla wrote:
>=20
> > The Wisconsin User Group Steering comity Just recently ask our District
> > Sales Manager this NI Visa question.
> > He did some research and replied with this response.
>=20
> [...]
>=20
> > Today, our licensing policy DOES NOT require a customer to pay a licens=
ing
> > fee for NI-VISA if the deployment target contains NI hardware or softwa=
re
> > written using NI development software. In the scenario where you have a
> > LabVIEW VI or EXE talking on a built-in serial port, National Instrumen=
ts
> > allows the first 10 distributions for free and after that we require a
> > licensing fee.  We are about to change our licensing policy to allow up=
 to
> > 100 distributions per application for free and after that require a
> > license.
>=20
> [...]
>=20
> Oh  yes,  i  know  that,  but  have  you  read  the  licence
> agreements?  I only found that NI supplies different licence
> agreements  on  their  FTP  server, all targeting NI-VISA. I
> havn't  read  them  all, but up to now I did't find anything
> about 10 or 100 free installations.
>=20
> For   me  it  is  actually  unclear
>=20
> - which of the licence agreements have to be used (for which
> labview version or for which hardware or whatever).
>=20
> - where the licence agreement is which correctly and clearly
> explains how many installations can be used.
>=20
> -  how  a  developer  should be able to ensure that only the
> number of allowed installations ere exists in the world.
>=20
> -  where  is  clearly  explained  under what circumstances a
> developer  can  distribute the VISA runtime installer. (only
> when creating an installer with LabVIEW7 as explained in one
> of the licences? - what is with LV 5, 6, 6.1 and 7.1?)
>=20
> -  If  NI  changes  the  licencing  issue, whats about older
> versions/installations.
>=20
> ...
>=20
> I can understand NI, that they wants to mainly support their
> hardware  and  I also understand, that they would have a fee
> if  anyone  is  using  their  software  without  using their
> hardware.  That's  not the topic here - but we all have paid
> for  LabVIEW  and we all should be able to use the basics of
> our PC and operating system (which we also have paid for).
>=20
> 73 de Martin, DL5NAH

RE: OpenG VISA

[Michael A. <mic...@im...>]

This method of implementation (passports) would still require NI-VISA to be=
 installed to access the passport interface, yes?  That does not seem to be=
 an option for us. Rolf's offer of his framework under LGPL seems the way t=
o go.

Mike Ashe
******************************************
Michae C. Ashe                 Imaginagics
860-444-2141  mic...@im...
******************************************

---- ope...@li... wrote:
>
> Frederic Villeneuve [fre...@la...] wrote:
> >=20
> > Some companies also piggy-back on NI's VISA implementation by just=20
> > adding a passport. Rohde&Schwarz does that.
>=20
> But that probably might require an NDA? The passport interface is
> not part of the open VXIPlug&Play specification for VISA.
>=20
> Rolf Kalbermatter
>