Menu
▾
▴
opengtoolkit-developers — OpenG Toolkit developers mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(53) |
Nov
(66) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(5) |
Mar
(72) |
Apr
(15) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(18) |
Oct
(2) |
Nov
|
Dec
(6) |
| 2005 |
Jan
(41) |
Feb
(28) |
Mar
(14) |
Apr
(18) |
May
(10) |
Jun
(6) |
Jul
(5) |
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
From: Jim K. <ji...@ji...> - 2003-11-16 18:14:06
|
Niels and All, I have figured out a solution. The Dynamic Palette View package now installs two palette views: "Dynamic Palette View" and "2D Dynamic = Palette View". The 2D Dynamic Palette View is identical to the Dynamic Palette View, with the exception that the Controls palette has Classic (2D) = controls submenus and has a submenu called "3D Controls", which contains all of = the 3D controls. The "2D Dynamic Palette View" (./menus/2ddynamic/) contains only two mnu files (root.mnu and 3dctrls.mnu) which link to mnu files in the Dynamic Palette View (./menus/dynamic/), so there is virtually no duplication = of work in supporting the additional palette view. I have released ogrsc_dynamicpalette-0.6-1.ogp, which includes the 2D Dynamic Palette View. This package is part of = all_packages-2.0.5.ogp.zip. <http://sourceforge.net/projects/opengtoolkit/> I'll update the OpenG Toolkit Downloads page on OpenG.org with = instructions that include the 2D Dynamic Palette View. <http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3A+Downloa= ds> Regards, -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Jim Kring > Sent: Saturday, November 15, 2003 10:45 AM > To: ope...@li... > Subject: RE: "Classic Controls" package >=20 >=20 > Niels, >=20 > >=20 > > Jim, > >=20 > > I certainnly agree with you,- espicially relating to the=20 > OpenG Style. > >=20 > > However, I'd preferred that it was the other way round:=20 > Having the 2D=20 > > controls in the main entry and the 3D controls as a sub=20 > menu. You're=20 > > actually creating quite a lot more non-GUI windows than GUI windows! > >=20 >=20 > You're right! Hmmm... Well, the original idea for the=20 > Dynamic Palette View was that it was going to be just like=20 > the "default/advanced" Palette View, but with the palettes,=20 > synch'ed to specific folders. However, I really like your=20 > idea. The problem is that I think that this would create=20 > quite a bit of work. I'll have to think about that one, for=20 > a little while. I am also hesitant to change the Dynamic=20 > Palette View to a 2D controls because I don't want to turn=20 > off users who are not OpenG Developers and really like the=20 > super cool 3D controls ;-) It would be great if there were a=20 > really easy way to allow users to choose between 3D and 2D=20 > controls as the root controls palette of the Dynamic Palette View. >=20 > >=20 > > BTW the 'Complete Waveform' control has a bad linkage in 'Numeric'-> > > 'Classic Numeric'! > >=20 >=20 > Actually, I don't think that there is such a thing as=20 > 'Complete Waveform' > (any more). The numeric controls palette links to this=20 > missing control but > the ./menus/default/readonly.txt file prevents the question mark from > appearing in the palette. I haven't yet decided if I want to=20 > delete this > dead-link or just make it disappear with a readonly.txt file.=20 > I'll fix this > before the official release of 'Classic Controls'. >=20 > > Just my $0.02. > >=20 > > All the best > > Niels > >=20 >=20 > Regards, >=20 > -Jim >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF. Net email is sponsored by: GoToMyPC > GoToMyPC is the fast, easy and secure way to access your computer from > any Web browser or wireless device. Click here to Try it Free! > = https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=3D/g22lp.tmpl > _______________________________________________ > OpenGToolkit-Developers mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers >=20 |
|
From: Jim K. <ji...@ji...> - 2003-11-15 22:31:59
|
Hello All, I just wanted to let everyone know that I have released version 1.0 of = the OpenG Package Installer. This doesn't really add anything different = from v0.9, except that it supports almost all LabVIEW platforms. Here is a = list of the changes: 1) The OGPI 1.0 does not install any additional packages during installation. Previously, it installed the restart, palette, and deab packages. I have removed these. Users should download them seperately. 2) The OGPI 1.0 supports LabVIEW 6.0, 6.1, and 7.0 on Windows, Mac OS X, = and Linux -- all this in a single download (ogpi-1.0-all.zip), with no = special steps for non-PC users!!! The Mac OS X installer accomplishes this by launching a self extracting MacBinary'ed archive of the lvzlib shared library (.Framework). This allows the resource fork of the shared = library to be preserved while its in the ogpi-1.0-all.zip file. Also, Philippe Guerit has integrated the OGPI installation instructions = into the OGTK-2.x installation instructions on the OpenG Toolkit Downloads = page (Thanks, Philippe): <http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3A+Downloa= ds> Regards, -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-15 18:58:34
|
dynamicpalette-0.5 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X. |
|
From: Jim K. <ji...@ji...> - 2003-11-15 18:58:34
|
-=3D all_packages-2.0.4 =3D- Notes: * dynamicpalette-0.5 is compatible with LabVIEW 6.0, 6.1, and 7.0 on Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib -=3D 2.0.4 Changelog =3D- all_packages 2.0.3 --> 2.0.4 -------------------------------------- ogrsc_dynamicpalette 0.4-1 --> 0.5-1 (Added LV7.0 support for Mac OS X) -=3D 2.0.3 Changelog =3D- all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) -=3D 2.0.2 Changelog =3D- all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) -=3D 2.0.1 Changelog =3D- all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-15 18:44:35
|
Niels, >=20 > Jim, >=20 > I certainnly agree with you,- espicially relating to the OpenG Style. >=20 > However, I'd preferred that it was the other way round: Having the 2D > controls in the main entry and the 3D controls as a sub menu. You're=20 > actually creating quite a lot more non-GUI windows than GUI windows! >=20 You're right! Hmmm... Well, the original idea for the Dynamic Palette = View was that it was going to be just like the "default/advanced" Palette = View, but with the palettes, synch'ed to specific folders. However, I really = like your idea. The problem is that I think that this would create quite a = bit of work. I'll have to think about that one, for a little while. I am = also hesitant to change the Dynamic Palette View to a 2D controls because I = don't want to turn off users who are not OpenG Developers and really like the super cool 3D controls ;-) It would be great if there were a really = easy way to allow users to choose between 3D and 2D controls as the root = controls palette of the Dynamic Palette View. >=20 > BTW the 'Complete Waveform' control has a bad linkage in 'Numeric'->=20 > 'Classic Numeric'! >=20 Actually, I don't think that there is such a thing as 'Complete = Waveform' (any more). The numeric controls palette links to this missing control = but the ./menus/default/readonly.txt file prevents the question mark from appearing in the palette. I haven't yet decided if I want to delete = this dead-link or just make it disappear with a readonly.txt file. I'll fix = this before the official release of 'Classic Controls'. > Just my $0.02. >=20 > All the best > Niels >=20 Regards, -Jim |
|
From: Niels H. <ni...@ha...> - 2003-11-15 13:21:58
|
Jim, I certainnly agree with you,- espicially relating to the OpenG Style. However, I'd preferred that it was the other way round: Having the 2D controls in the main entry and the 3D controls as a sub menu. You're actually creating quite a lot more non-GUI windows than GUI windows! BTW the 'Complete Waveform' control has a bad linkage in 'Numeric'-> 'Classic Numeric'! Just my $0.02. All the best Niels |
|
From: Jim K. <ji...@ji...> - 2003-11-15 01:57:41
|
Hello All, I have an idea I want to bounce off of the group. Personally I like to use Classic (2D) Controls for all non-GUI VIs, and think that this should be part of the "OpenG Style" of coding. The = reason for using 2D Controls is related mostly to performance and memory = issues, but I also think that they simply look much "cleaner". So, I have = created a package called "ogrsc_classic_controls". It is an add-on for the = Dynamic Palette View. What it does is the following: For each of the 3D = controls menus it adds the corresponding 2D controls menu as a submenu. For = example, the Classic (2D) Numeric Controls menu is added as a submenu of the 3D Numeric Controls. To me, this seams like a more natural route, for = getting to classic controls, than having to go in to the root classic controls submenu and then navigating to the control type I need. Any thoughts? BTW, the "classic_controls" package is a good example of the flexibility provided by the Dynamic Palette View. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-14 21:02:30
|
Jean-Pierre and All, If you have an illegal name, you will get an error; and, if you have a name collision, you will get an error. So the worse case, when attempting to rename an illegal name, is that you get a name collision, and you have a different error. -Jim Jean-Pierre Drolet <jea...@tr...> said: > That is a known issue. In the first place, NI's Config VIs don't check for EOLs in keynames. I assume that NI's response about this would be "Don't use non-printable characters in keynames", which is reasonable. If a user creates a FP with the goal to save it on INI files, he must be aware that control names must follow the rules of keynames for INI files. If we want variantconfig to prevent for this issue, we could filter keynames to replace any sequence of non-printable characters (control char., whitespace and few others like []) with a space. However, this substitution can create duplicate keynames so maybe the best is to generate an error for irregular keynames. > > Jean-Pierre > > > > > Jim Kring <ji...@ji...> wrote: > Hello All, > > Philippe submitted the bug shown in the attached email. It is a problem > with variantconfig that effects control names with EOL characters in their > names. Philippe suggests a fix by converting EOL characters to a space. I > think this is a good fix. This will cause the names to appear as a single > line in the INI file. The only possible problem is that there could be a > name collision with a control that has the same name. However, LabVIEW also > allows controls with the same name so this problem already exists. Hmmm, > sounds like we need some error handling... any thoughts? What preconditions > should we be testing for? > > - No two controls can have the same names tested after converting all > illegal names to legitimate names (like converting EOLs in control names to > spaces.) > > Any others? > > -Jim > > > -----Original Message----- > From: SourceForge.net [mailto:no...@so...] > Sent: Thursday, November 13, 2003 5:25 PM > To: no...@so... > Subject: [ opengtoolkit-Bugs-841864 ] If a control name is on 2 line, read > panel from INI will fai > > > Bugs item #841864, was opened at 2003-11-13 17:25 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/? func=detail&atid=466832&aid=841864&group_id > =52435 > > Category: lib_variantconfig > Group: LabVIEW 7.0 (All) > Status: Open > Resolution: None > Priority: 5 > Submitted By: philippe guerit (pjm_design) > Assigned to: Jim Kring (jkring) > Summary: If a control name is on 2 line, read panel from INI will fai > > Initial Comment: > If a control name is on 2 line such as > "my control > name" > read panel from INI will fail because the controls was > saved as two different keys on two different lines > > Possible Fix: when saving key name, scan string for end > of line or line feed or carriage return and replace it > by a space. > The same thing is required when getting the name of the > control from the variant > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/? func=detail&atid=466832&aid=841864&group_id > =52435 > > > > ------------------------------------------------------- > 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 > > > ---------------------------------------------------------------------------- -- > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > -- |
|
From: Jean-Pierre D. <jea...@tr...> - 2003-11-14 20:15:48
|
That is a known issue. In the first place, NI's Config VIs don't check for EOLs in keynames. I assume that NI's response about this would be "Don't use non-printable characters in keynames", which is reasonable. If a user creates a FP with the goal to save it on INI files, he must be aware that control names must follow the rules of keynames for INI files. If we want variantconfig to prevent for this issue, we could filter keynames to replace any sequence of non-printable characters (control char., whitespace and few others like []) with a space. However, this substitution can create duplicate keynames so maybe the best is to generate an error for irregular keynames.
Jean-Pierre
Jim Kring <ji...@ji...> wrote:
Hello All,
Philippe submitted the bug shown in the attached email. It is a problem
with variantconfig that effects control names with EOL characters in their
names. Philippe suggests a fix by converting EOL characters to a space. I
think this is a good fix. This will cause the names to appear as a single
line in the INI file. The only possible problem is that there could be a
name collision with a control that has the same name. However, LabVIEW also
allows controls with the same name so this problem already exists. Hmmm,
sounds like we need some error handling... any thoughts? What preconditions
should we be testing for?
- No two controls can have the same names tested after converting all
illegal names to legitimate names (like converting EOLs in control names to
spaces.)
Any others?
-Jim
-----Original Message-----
From: SourceForge.net [mailto:no...@so...]
Sent: Thursday, November 13, 2003 5:25 PM
To: no...@so...
Subject: [ opengtoolkit-Bugs-841864 ] If a control name is on 2 line, read
panel from INI will fai
Bugs item #841864, was opened at 2003-11-13 17:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=466832&aid=841864&group_id
=52435
Category: lib_variantconfig
Group: LabVIEW 7.0 (All)
Status: Open
Resolution: None
Priority: 5
Submitted By: philippe guerit (pjm_design)
Assigned to: Jim Kring (jkring)
Summary: If a control name is on 2 line, read panel from INI will fai
Initial Comment:
If a control name is on 2 line such as
"my control
name"
read panel from INI will fail because the controls was
saved as two different keys on two different lines
Possible Fix: when saving key name, scan string for end
of line or line feed or carriage return and replace it
by a space.
The same thing is required when getting the name of the
control from the variant
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=466832&aid=841864&group_id
=52435
-------------------------------------------------------
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
------------------------------------------------------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
|
|
From: PJ M <pjm...@ya...> - 2003-11-14 18:49:01
|
Hi all, When I found that bug, I was actually implementing some error checking. It is based on the following assumption: 1) VI name (containing the saved panel) might be changed in the future 2) Paramater can be added or remove from the panel and in both case, the "read panel from INI" should work (if possible) In the first case, I check the Section Name[] of the INI against the file name and try to get a match or a best match In the second case I check the Keys[] of the INI against the controls name and report to the user if the INI is missing anything so the user can manually finish populating what is missing. Regarding the EOL issue, replacing the EOL by space should be enough. The programmer should be aware of the issue by having two controls/indicators with the same name. Returning a warning in such a case is a possibility as well Philippe Jim Kring <ji...@ji...> wrote: Hello All, Philippe submitted the bug shown in the attached email. It is a problem with variantconfig that effects control names with EOL characters in their names. Philippe suggests a fix by converting EOL characters to a space. I think this is a good fix. This will cause the names to appear as a single line in the INI file. The only possible problem is that there could be a name collision with a control that has the same name. However, LabVIEW also allows controls with the same name so this problem already exists. Hmmm, sounds like we need some error handling... any thoughts? What preconditions should we be testing for? - No two controls can have the same names tested after converting all illegal names to legitimate names (like converting EOLs in control names to spaces.) Any others? -Jim -----Original Message----- From: SourceForge.net [mailto:no...@so...] Sent: Thursday, November 13, 2003 5:25 PM To: no...@so... Subject: [ opengtoolkit-Bugs-841864 ] If a control name is on 2 line, read panel from INI will fai Bugs item #841864, was opened at 2003-11-13 17:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=466832&aid=841864&group_id =52435 Category: lib_variantconfig Group: LabVIEW 7.0 (All) Status: Open Resolution: None Priority: 5 Submitted By: philippe guerit (pjm_design) Assigned to: Jim Kring (jkring) Summary: If a control name is on 2 line, read panel from INI will fai Initial Comment: If a control name is on 2 line such as "my control name" read panel from INI will fail because the controls was saved as two different keys on two different lines Possible Fix: when saving key name, scan string for end of line or line feed or carriage return and replace it by a space. The same thing is required when getting the name of the control from the variant ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=466832&aid=841864&group_id =52435 ------------------------------------------------------- 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 --------------------------------- Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard |
|
From: Jim K. <ji...@ji...> - 2003-11-14 05:22:01
|
Hello All, Philippe submitted the bug shown in the attached email. It is a problem with variantconfig that effects control names with EOL characters in = their names. Philippe suggests a fix by converting EOL characters to a space. = I think this is a good fix. This will cause the names to appear as a = single line in the INI file. The only possible problem is that there could be = a name collision with a control that has the same name. However, LabVIEW = also allows controls with the same name so this problem already exists. = Hmmm, sounds like we need some error handling... any thoughts? What = preconditions should we be testing for? - No two controls can have the same names tested after converting all illegal names to legitimate names (like converting EOLs in control names = to spaces.) Any others? -Jim -----Original Message----- From: SourceForge.net [mailto:no...@so...]=20 Sent: Thursday, November 13, 2003 5:25 PM To: no...@so... Subject: [ opengtoolkit-Bugs-841864 ] If a control name is on 2 line, = read panel from INI will fai Bugs item #841864, was opened at 2003-11-13 17:25 Message generated for change (Tracker Item Submitted) made by Item = Submitter You can respond by visiting:=20 https://sourceforge.net/tracker/?func=3Ddetail&atid=3D466832&aid=3D841864= &group_id =3D52435 Category: lib_variantconfig Group: LabVIEW 7.0 (All) Status: Open Resolution: None Priority: 5 Submitted By: philippe guerit (pjm_design) Assigned to: Jim Kring (jkring) Summary: If a control name is on 2 line, read panel from INI will fai Initial Comment: If a control name is on 2 line such as "my control name" read panel from INI will fail because the controls was saved as two different keys on two different lines Possible Fix: when saving key name, scan string for end of line or line feed or carriage return and replace it by a space. The same thing is required when getting the name of the control from the variant ---------------------------------------------------------------------- You can respond by visiting:=20 https://sourceforge.net/tracker/?func=3Ddetail&atid=3D466832&aid=3D841864= &group_id =3D52435 |
|
From: Jim K. <ji...@ji...> - 2003-11-14 04:54:57
|
-=3D all_packages-2.0.3 =3D- =20 Notes: =20 * dynamicpalette-0.2 is compatible with LabVIEW 6.0, 6.1, and 7.0 on = Windows an Linux * OpenG Toolkit 2.0 packages are name mangled as "*__ogtk.vi" to avoid namespace collisions with vi.lib =20 =20 -=3D 2.0.3 Changelog =3D- =20 all_packages 2.0.2 --> 2.0.3 -------------------------------------- ogrsc_dynamicpalette 0.3-1 --> 0.4-1 (Fixed LV7.0 platform specific = support) =20 =20 =20 -=3D 2.0.2 Changelog =3D- =20 all_packages 2.0.1 --> 2.0.2 -------------------------------------- oglib_appcontrol 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) oglib_file 2.1-1 --> 2.1-2 (Fixed non-Windows Install Problem) oglib_lvzip 2.0-1 --> 2.0-2 (Fixed non-Windows Install Problem) ogrsc_dynamicpalette 0.2-1 --> 0.3-1 (Added LV6.0/6.1 and Linux support) =20 =20 =20 -=3D 2.0.1 Changelog =3D- =20 all_packages 2.0 --> 2.0.1 ---------------------------------------------------------- oglib_file 2.0-1 --> 2.1-1 |
|
From: Jim K. <ji...@ji...> - 2003-11-11 21:34:05
|
And now it's been rev'ed to v0.3 <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> I promise that I have actually tested it in LV70 this time ;-) -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jim Kring > Sent: Tuesday, November 11, 2003 11:25 AM > To: ope...@li... > Subject: RE: Relinking Projects to OGTK-2.x > > > I have just rev'ed ogrsc_relink_project_to_ogtk_2 to v0.2. > Ed found a bug caused by the fact that I didn't build vi.lib > into the utility and this was causing the same problem it was > trying to solve (the utility was linking to "Simple Error > Handler.vi" which uses "Trim Whitespace.vi" in LV70). > > <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3 > A+Downloads> > > -Jim > > > -----Original Message----- > > From: ope...@li... > > [mailto:ope...@li...] > > On Behalf Of Jim Kring > > Sent: Tuesday, November 11, 2003 8:42 AM > > To: ope...@li... > > Subject: Relinking Projects to OGTK-2.x > > > > > > Hello All, > > > > As you may know, the OpenG Toolkit 2.0 has some changes. > > > > (1) OpenG Toolkit VIs are now installed beneath > > <./user.lib/_OpenG.lib/>. > > > > (2) The OGTK library packages are integrated into the > > palettes by installing the libraries' .mnu files beneath the > > "Dynamic Palette View" directory <./user.lib/_dynamicpalette_dirs/>. > > > > (3) OpenG Toolkit VIs now have a suffix and are named like > > "*__ogtk.vi". This avoids name collisions with new LV70 > > vi.lib VIs such as "Trim Whitespace.vi" and "Get Tag.vi". > > > > #3 introduces the problem that projects, which are linked to > > OGTK-1.x, will need to be relinked to OGTK-2.x (because the > > Toolkit VI names have changed). For this, I have created a > > tool called "Relink Project to OGTK-2.x" > > (ogrsc_relink_project_to_ogtk_2 package). This tool performs > > the following > > actions: > > > > 1 - Creates a temporary copy of OGTK 2.x in a temp dir > > 2 - Removes the __ogtk suffix from the OGTK 2.x in the temp > > dir 3 - Loads the OGTK 2.x in the temp dir into memory 4 - > > Opens your project source files into memory 5 - Restores the > > __ogtk suffix to the OGTK 2.x in the temp dir 6 - Saves > > project source files 7 - Unloads all files from memory 8 - > > Deletes OGTK 2.x in the temp dir 9 - Loads the OGTK 2.x into > > memory 10 - Opens your project source files into memory 11 - > > Saves project source files > > > > There is a link for downloading this tool on the "OpenG > > Toolkit: Downloads" page... > > > <http://openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> > > Please back up your project source files, before running this > utility :-) > > -Jim > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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: Jim K. <ji...@ji...> - 2003-11-11 19:24:43
|
I have just rev'ed ogrsc_relink_project_to_ogtk_2 to v0.2. Ed found a bug caused by the fact that I didn't build vi.lib into the utility and this was causing the same problem it was trying to solve (the utility was linking to "Simple Error Handler.vi" which uses "Trim Whitespace.vi" in LV70). <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jim Kring > Sent: Tuesday, November 11, 2003 8:42 AM > To: ope...@li... > Subject: Relinking Projects to OGTK-2.x > > > Hello All, > > As you may know, the OpenG Toolkit 2.0 has some changes. > > (1) OpenG Toolkit VIs are now installed beneath > <./user.lib/_OpenG.lib/>. > > (2) The OGTK library packages are integrated into the > palettes by installing the libraries' .mnu files beneath the > "Dynamic Palette View" directory <./user.lib/_dynamicpalette_dirs/>. > > (3) OpenG Toolkit VIs now have a suffix and are named like > "*__ogtk.vi". This avoids name collisions with new LV70 > vi.lib VIs such as "Trim Whitespace.vi" and "Get Tag.vi". > > #3 introduces the problem that projects, which are linked to > OGTK-1.x, will need to be relinked to OGTK-2.x (because the > Toolkit VI names have changed). For this, I have created a > tool called "Relink Project to OGTK-2.x" > (ogrsc_relink_project_to_ogtk_2 package). This tool performs > the following > actions: > > 1 - Creates a temporary copy of OGTK 2.x in a temp dir > 2 - Removes the __ogtk suffix from the OGTK 2.x in the temp > dir 3 - Loads the OGTK 2.x in the temp dir into memory 4 - > Opens your project source files into memory 5 - Restores the > __ogtk suffix to the OGTK 2.x in the temp dir 6 - Saves > project source files 7 - Unloads all files from memory 8 - > Deletes OGTK 2.x in the temp dir 9 - Loads the OGTK 2.x into > memory 10 - Opens your project source files into memory 11 - > Saves project source files > > There is a link for downloading this tool on the "OpenG > Toolkit: Downloads" page... > <http://openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> Please back up your project source files, before running this utility :-) -Jim ------------------------------------------------------- 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: Ed D. <ed...@cf...> - 2003-11-11 16:56:44
|
And I was just about to start building a way to this. Thanks Jim Ed -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Jim Kring Sent: Tuesday, November 11, 2003 10:42 AM To: ope...@li... Subject: Relinking Projects to OGTK-2.x Hello All, As you may know, the OpenG Toolkit 2.0 has some changes. (1) OpenG Toolkit VIs are now installed beneath <./user.lib/_OpenG.lib/>. (2) The OGTK library packages are integrated into the palettes by installing the libraries' .mnu files beneath the "Dynamic Palette View" directory <./user.lib/_dynamicpalette_dirs/>. (3) OpenG Toolkit VIs now have a suffix and are named like "*__ogtk.vi". This avoids name collisions with new LV70 vi.lib VIs such as "Trim Whitespace.vi" and "Get Tag.vi". #3 introduces the problem that projects, which are linked to OGTK-1.x, will need to be relinked to OGTK-2.x (because the Toolkit VI names have changed). For this, I have created a tool called "Relink Project to OGTK-2.x" (ogrsc_relink_project_to_ogtk_2 package). This tool performs the following actions: 1 - Creates a temporary copy of OGTK 2.x in a temp dir 2 - Removes the __ogtk suffix from the OGTK 2.x in the temp dir 3 - Loads the OGTK 2.x in the temp dir into memory 4 - Opens your project source files into memory 5 - Restores the __ogtk suffix to the OGTK 2.x in the temp dir 6 - Saves project source files 7 - Unloads all files from memory 8 - Deletes OGTK 2.x in the temp dir 9 - Loads the OGTK 2.x into memory 10 - Opens your project source files into memory 11 - Saves project source files There is a link for downloading this tool on the "OpenG Toolkit: Downloads" page... <http://openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3A+Downloads> Please back up your project source files, before running this utility :-) -Jim ------------------------------------------------------- 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: Jim K. <ji...@ji...> - 2003-11-11 16:47:52
|
Sorry, somehow the EOL char's got messed up that last email... The relinking tool performs the following actions: (1) Creates a temporary copy of OGTK 2.x in a temp dir (2) Removes the __ogtk suffix from the OGTK 2.x in the temp dir (3) Loads the OGTK 2.x in the temp dir into memory (4) Opens your project source files into memory (5) Restores the __ogtk suffix to the OGTK 2.x in the temp dir (6) Saves project source files (7) Unloads all files from memory (8) Deletes OGTK 2.x in the temp dir (9) Loads the OGTK 2.x into memory (10) Opens your project source files into memory (11) Saves project source files -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > On Behalf Of Jim Kring > Sent: Tuesday, November 11, 2003 8:42 AM > To: ope...@li... > Subject: Relinking Projects to OGTK-2.x > > > Hello All, > > As you may know, the OpenG Toolkit 2.0 has some changes. > > (1) OpenG Toolkit VIs are now installed beneath > <./user.lib/_OpenG.lib/>. > > (2) The OGTK library packages are integrated into the > palettes by installing the libraries' .mnu files beneath the > "Dynamic Palette View" directory <./user.lib/_dynamicpalette_dirs/>. > > (3) OpenG Toolkit VIs now have a suffix and are named like > "*__ogtk.vi". This avoids name collisions with new LV70 > vi.lib VIs such as "Trim Whitespace.vi" and "Get Tag.vi". > > #3 introduces the problem that projects, which are linked to > OGTK-1.x, will need to be relinked to OGTK-2.x (because the > Toolkit VI names have changed). For this, I have created a > tool called "Relink Project to OGTK-2.x" > (ogrsc_relink_project_to_ogtk_2 package). This tool performs > the following > actions: > > 1 - Creates a temporary copy of OGTK 2.x in a temp dir > 2 - Removes the __ogtk suffix from the OGTK 2.x in the temp > dir 3 - Loads the OGTK 2.x in the temp dir into memory 4 - > Opens your project source files into memory 5 - Restores the > __ogtk suffix to the OGTK 2.x in the temp dir 6 - Saves > project source files 7 - Unloads all files from memory 8 - > Deletes OGTK 2.x in the temp dir 9 - Loads the OGTK 2.x into > memory 10 - Opens your project source files into memory 11 - > Saves project source files > > There is a link for downloading this tool on the "OpenG > Toolkit: Downloads" page... > <http://openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> Please back up your project source files, before running this utility :-) -Jim ------------------------------------------------------- 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: Jim K. <ji...@ji...> - 2003-11-11 16:42:25
|
Hello All, As you may know, the OpenG Toolkit 2.0 has some changes. (1) OpenG Toolkit VIs are now installed beneath = <./user.lib/_OpenG.lib/>. (2) The OGTK library packages are integrated into the palettes by = installing the libraries' .mnu files beneath the "Dynamic Palette View" directory <./user.lib/_dynamicpalette_dirs/>. (3) OpenG Toolkit VIs now have a suffix and are named like "*__ogtk.vi". This avoids name collisions with new LV70 vi.lib VIs such as "Trim Whitespace.vi" and "Get Tag.vi". #3 introduces the problem that projects, which are linked to OGTK-1.x, = will need to be relinked to OGTK-2.x (because the Toolkit VI names have = changed). For this, I have created a tool called "Relink Project to OGTK-2.x" (ogrsc_relink_project_to_ogtk_2 package). This tool performs the = following actions: 1 - Creates a temporary copy of OGTK 2.x in a temp dir 2 - Removes the __ogtk suffix from the OGTK 2.x in the temp dir 3 - Loads the OGTK 2.x in the temp dir into memory 4 - Opens your project source files into memory 5 - Restores the __ogtk suffix to the OGTK 2.x in the temp dir 6 - Saves project source files 7 - Unloads all files from memory 8 - Deletes OGTK 2.x in the temp dir 9 - Loads the OGTK 2.x into memory 10 - Opens your project source files into memory 11 - Saves project source files There is a link for downloading this tool on the "OpenG Toolkit: = Downloads" page... <http://openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3A+Downloads> Please back up your project source files, before running this utility = :-) -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-11 16:22:26
|
Sorry about that, Bj=F8rnar. I have updated the OpenG Toolkit Downloads page... <http://openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3A+Downloads> ...with a link to the OpenG Package Installer. Also, the reason that = there aren't any .zip file (manual installation) packages is that I haven't = had the time to package them all up, yet. Give the OGPI a try and let me = know if you have any trouble. -Jim > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...]=20 > On Behalf Of Svingen Bj=F8rnar > Sent: Tuesday, November 11, 2003 12:20 AM > To: 'ope...@li...' > Subject: RE: OpenG Toolkit Downloads >=20 >=20 > I hope you will excuse my ignorance here, but I can't seem to=20 > find the OpenG package installer nor the pure zip files (only=20 > those with .ogp extension) >=20 > B >=20 > > -----Original Message----- > > From: Jim Kring [mailto:ji...@ji...] > > Sent: 10. november 2003 10:58 > > To: OpenGToolkit-Developers > > Subject: OpenG Toolkit Downloads > >=20 > >=20 > > Hello All, > >=20 > > I have updated the "OpenG Toolkit: Downloads" page... > >=20 > > <http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Toolkit%3 > > A+Downloads> > >=20 > > ...on OpenG.org with some information that helps end-users > > understand the > > distribution mechanisms. Basically there are a couple key points. > >=20 > > (1) There are two different package formats: ZIP files and > > OpenG Package > > (*.ogp) files. Zip files are for manual installation and=20 > > OpenG Package > > files are for installation with the OpenG Package Installer. > >=20 > > (2) One can either download all the latest packages in a single=20 > > "all_packages" zip file (two choices a ZIP file of manual=20 > installers=20 > > or a ZIP file of OpenG Packages), or download individual packages > > seperately. > >=20 > > -Jim > >=20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.Net email sponsored by: ApacheCon 2003, > > 16-19 November in Las Vegas. Learn firsthand the latest=20 > developments=20 > > in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more!=20 > > http://www.apachecon.com/=20 > > _______________________________________________ > > OpenGToolkit-Developers mailing list=20 > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers > >=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 |
|
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: <Bjo...@si...> - 2003-11-11 08:20:30
|
I hope you will excuse my ignorance here, but I can't seem to find the OpenG package installer nor the pure zip files (only those with .ogp extension) B > -----Original Message----- > From: Jim Kring [mailto:ji...@ji...] > Sent: 10. november 2003 10:58 > To: OpenGToolkit-Developers > Subject: OpenG Toolkit Downloads > > > Hello All, > > I have updated the "OpenG Toolkit: Downloads" page... > > <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3 > A+Downloads> > > ...on OpenG.org with some information that helps end-users > understand the > distribution mechanisms. Basically there are a couple key points. > > (1) There are two different package formats: ZIP files and > OpenG Package > (*.ogp) files. Zip files are for manual installation and > OpenG Package > files are for installation with the OpenG Package Installer. > > (2) One can either download all the latest packages in a single > "all_packages" zip file (two choices a ZIP file of manual > installers or a > ZIP file of OpenG Packages), or download individual packages > seperately. > > -Jim > > > > ------------------------------------------------------- > 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: Michael Ashe@I. <eli...@im...> - 2003-11-10 20:27:50
|
Hi John, Strictly speaking, no. We can (and will) release OSTE without drivers, etc. However, a long term goal of the project is to allow people to download free executables and then run their hardware (within the limits of the features the drivers expose). The idea was to allow people to buy a few instruments, download an OSTE version (executable) and the OSTE compatible drivers/plugins, download a few plugin analysers, and then be able to to a lot of testing without having to learn (or buy) another language. If you then had to do something more sophisticated than the features exposed by the stock drivers, you'd buy LabVIEW (or VB, etc, eventually) and code up either more sophisticated versions of the drivers or go straight to a test module. The driver licensing gets in the way of that. Yes, the project is running, there is a new list on source forge. I'm a little pressed for time right this minute, but will get you info tonight, and yes, we'd like the help. Cheers, Mike *********************************** Michael C. Ashe Imaginatics Control & Test Systems 11 Quinley Way Waterford, CT 06385 Phone: 860-444-2141 Cell: 860-961-0876 email: mic...@im... *********************************** > -----Original Message----- > From: John Howard [mailto:Joh...@sp...] > Sent: Monday, November 10, 2003 01:09 PM > To: mic...@im...; > ope...@li... > Subject: Re: OpenGToolkit-Developers digest > > > Hi Michael and all, > > Regarding the OSTE, I am wondering if it is necessary to have any > form of hardware drivers incorporated into the OSTE at all. We > are using a home grown TE which uses VISA (VXI and GPIB) as an > "add-on", with calls through VI-server. As a result - the Test > Executive itself doesn't need VISA - even though the driver add-on does. > > By the way - is the OSTE project up and running yet? I am still > interested in helping out. > > Regards, > > John Howard > > >>> mic...@im... 11/08/03 12:20AM >>> > Hi Kevin, others, > > I haven't chimed in yet on this VISA issue, but it bears on not > only the OpenG Toolkit, but very heavily on OSTE as well. I would > like to distribute OSTE in executable form as well as the source > code, with drivers and code modules, but with NI's licensing it > might be pretty tough. Open(G)VISA would help a lot. OSTE's > grandfather was a military functional test system that was very > heavily based on VXI and GPIB. Without VISA or the older VXI and > GPIB drivers we'd be hobbled. Worse, NI could take OSTE, add VISA > and distribute for less than the $395.00 of an outside license. > > Any thoughts? Lastly, I think I am going to try to find and dust > off my old LabVIEW 3.1 and 4.1 versions to look back through the > old pre-VISA driver stuff. > > Cheers, > Mike Ashe > OSTE Project Manager > > ---- Kevin Valentine <k.v...@ve...> wrote: > > On 2003.11.07 17:10 > ope...@li... wrote: > > > Date: Fri, 7 Nov 2003 22:09:20 -0000 > > > To: "ope...@li..." > <ope...@li...> > > > Subject: VISA alternative > > > From: "Jim Kring" <ji...@ji...> > > > Cc: <rol...@ci...>, <chr...@ep...> > > > Reply-To: ope...@li... > > > > > > 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. > > > > > > -Jim > > > > > > > Wow, that is such a cool idea! Why not call it OpenG-VISA? > Covers it all: GPIB, RS232, ethernet, etc. Haven't seen the > info-lv thread (I just subscibed). Did a search for open source > visa and found one place: > > > > http://www.pnpi.spb.ru/~bazhenov/atel/English/whatVISA.htm > > > > They refer to Open-Visa which they claim to be an open source > version of visa. There's nothing more on their site regarding > this. Googled more on open-visa, still nothing. > > > > Checked out sourceforge.net found these: > > http://sourceforge.net/projects/linux-gpib/ > > http://sourceforge.net/projects/gpib-tcl/ > > http://sourceforge.net/projects/gpib82357a/ > > http://sourceforge.net/projects/freedaq/ > > http://sourceforge.net/projects/libgpib/ > > > > Am I correct in thinking that we would need these hardware > drivers? I'm guessing that anything that NI has produced, even > though open source, has the licensing restrictions you noted > above. If we cant' touch anything of NI's then that's fine. Looks > like there's enough out there for us to get started :-) > > > > How much work will comforming to the VISA spec involve? Went to > the vxipnp.org and dl'ed the spec (vpp-4.3). Suppose I can > answer this myself as I read through it (285 pages). Perhaps > you're right about breaking it up into two separate projects, for now. > > > > -kevin > > > ------------------------------------------------------- > 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: John H. <Joh...@sp...> - 2003-11-10 18:09:24
|
Hi Michael and all, Regarding the OSTE, I am wondering if it is necessary to have any form of = hardware drivers incorporated into the OSTE at all. We are using a home = grown TE which uses VISA (VXI and GPIB) as an "add-on", with calls through = VI-server. As a result - the Test Executive itself doesn't need VISA - = even though the driver add-on does. By the way - is the OSTE project up and running yet? I am still interested= in helping out. Regards, John Howard >>> mic...@im... 11/08/03 12:20AM >>> Hi Kevin, others, I haven't chimed in yet on this VISA issue, but it bears on not only the = OpenG Toolkit, but very heavily on OSTE as well. I would like to distribute= OSTE in executable form as well as the source code, with drivers and code = modules, but with NI's licensing it might be pretty tough. Open(G)VISA = would help a lot. OSTE's grandfather was a military functional test = system that was very heavily based on VXI and GPIB. Without VISA or the = older VXI and GPIB drivers we'd be hobbled. Worse, NI could take OSTE, add = VISA and distribute for less than the $395.00 of an outside license. Any thoughts? Lastly, I think I am going to try to find and dust off my = old LabVIEW 3.1 and 4.1 versions to look back through the old pre-VISA = driver stuff. Cheers, Mike Ashe OSTE Project Manager ---- Kevin Valentine <k.v...@ve...> wrote: > On 2003.11.07 17:10 ope...@li...= wrote: > > Date: Fri, 7 Nov 2003 22:09:20 -0000 > > To: "ope...@li..." <opengtoolkit-devel= op...@li...> > > Subject: VISA alternative > > From: "Jim Kring" <ji...@ji...> > > Cc: <rol...@ci...>, <chr...@ep...> > > Reply-To: ope...@li...=20 > >=20 > > If anyone has been reading the info-lv thread on NI VISA licensing, = you can=20 > > see that there is a huge demand for an open source solution for serial = and=20 > > parallel port I/O. NI only allows you to distribute 10 copies of your = built=20 > > application that uses NI "Driver Software". After that, they want = $395 per=20 > > copy! Sounds like a good openg project to me. How about OpenGSerp = and=20 > > OpenGPortIO? I don't have the background to code up the OS interface = or=20 > > sharedlib, but I can help with all other aspects of the project. > >=20 > > -Jim > > >=20 > Wow, that is such a cool idea! Why not call it OpenG-VISA? Covers it = all: GPIB, RS232, ethernet, etc. Haven't seen the info-lv thread (I just = subscibed). Did a search for open source visa and found one place: >=20 > http://www.pnpi.spb.ru/~bazhenov/atel/English/whatVISA.htm=20 >=20 > They refer to Open-Visa which they claim to be an open source version of = visa. There's nothing more on their site regarding this. Googled more on = open-visa, still nothing. >=20 > Checked out sourceforge.net found these: > http://sourceforge.net/projects/linux-gpib/=20 > http://sourceforge.net/projects/gpib-tcl/=20 > http://sourceforge.net/projects/gpib82357a/=20 > http://sourceforge.net/projects/freedaq/=20 > http://sourceforge.net/projects/libgpib/=20 >=20 > Am I correct in thinking that we would need these hardware drivers? I'm = guessing that anything that NI has produced, even though open source, has = the licensing restrictions you noted above. If we cant' touch anything of = NI's then that's fine. Looks like there's enough out there for us to get = started :-) >=20 > How much work will comforming to the VISA spec involve? Went to the = vxipnp.org and dl'ed the spec (vpp-4.3). Suppose I can answer this myself = as I read through it (285 pages). Perhaps you're right about breaking it = up into two separate projects, for now. >=20 > -kevin ------------------------------------------------------- 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/=20 _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li...=20 https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers |
|
From: Jim K. <ji...@ji...> - 2003-11-10 17:54:30
|
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 |
|
From: Jim K. <ji...@ji...> - 2003-11-10 09:57:37
|
Hello All, I have updated the "OpenG Toolkit: Downloads" page... <http://www.openg.org/tiki/tiki-index.php?page=OpenG+Toolkit%3A+Downloads> ...on OpenG.org with some information that helps end-users understand the distribution mechanisms. Basically there are a couple key points. (1) There are two different package formats: ZIP files and OpenG Package (*.ogp) files. Zip files are for manual installation and OpenG Package files are for installation with the OpenG Package Installer. (2) One can either download all the latest packages in a single "all_packages" zip file (two choices a ZIP file of manual installers or a ZIP file of OpenG Packages), or download individual packages seperately. -Jim |
|
From: Jim K. <ji...@ji...> - 2003-11-09 10:42:36
|
Chris, Thanks for the reply. BTW, I have added your email address to the authorized senders to the list, but if you are interested in joining the list you can do so at: <https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers> Regards. -Jim > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] > 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 > > > 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 > > > > > > > > ------------------------------------------------------- > 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 > |
4 messages has been excluded from this view by a project administrator.
