From: John B. <jb...@Tr...> - 2005-01-16 18:41:14
|
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 |
From: Martin H. <mar...@mh...> - 2005-01-16 21:23:04
|
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 |
From: Scott H. <st...@ma...> - 2005-01-16 22:52:43
|
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 |
From: Martin H. <mar...@mh...> - 2005-01-16 23:31:48
|
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 |
From: Rolf K. <rol...@ci...> - 2005-01-17 00:13:26
|
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 |
From: Martin H. <mar...@mh...> - 2005-01-17 01:03:52
|
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 |
From: Scott H. <st...@ma...> - 2005-01-17 03:52:50
|
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. |