Jim Kring

Hankey San

Shouldn't you be finding easter eggs in LabVIEW, today, instead of bugs?

(it is Easter Sunday, afterall)

Stephen,

Your post gave me an idea....

It might be nice to add an option to the Show Buffer Allocations dialog for Subarrays. Here is an artists rendition of what this might look like:

Thanks,

-Jim

QUOTE (Justin Goeres @ Mar 20 2008, 09:04 PM)

I don't think that works. Or am I missing something?

I reproduced the code in your screenshot (or at least I think I did), and when I run it with

Array

=

{0,1,2,3,4,5,6,7,8,9}

Decimating Factor

=

3

Justin,

I did some testing of LabVIEW's built-in decimation function. It truncates the trailing (remainder) elements. I have no idea which is the preferred behavior. One one hand, it's nice not to lose data (so you wouldn't want the data truncated), and on the other hand if you are going to create several subarrays with the decimated data, it's nice to have them all the same length (so you would want the data truncated).

So, I would probably add an optional argument to this VI called truncate remainder.

-Jim

Thanks for the nice article, AQ. I learned a few new things

I've been using Jott for several months now and think it's an indispensible service. I've even got Jott on the speed/voice dial of my cell phone, so I don't even need to press any buttons to dial it :thumbup:

Hi everyone,

Thanks for the TALM nomination and for all the kind words. The LabVIEW community, especially LAVA, has been a great resource and outlet for my LabVIEW passion. The people who make up this community are a pleasure to work with and have as friends and colleagues -- how would anyone not want to be a part of it?

Thanks,

-Jim

PS - crelf must really be a glutton for punishment -- I start pressuring him to get to work on his OpenG toolkit candidate and then he nominates me for an award

Here's a fix for the remainder > 0 bug:

Download File:post-17-1206073613.vi

QUOTE (Daklu @ Mar 20 2008, 12:42 PM)

Keep in mind, however, that I am the local "expert," having used Labview for all of 1.5 years. Most of the users here have not heard of OpenG nor would know what to do with it if I sent them a link.

So, what are you waiting for? Let's get them up to speed about OpenG -- start them off on the right foot, early

QUOTE (Norm Kirchner @ Mar 20 2008, 09:13 AM)

Quick, remind me why we don't want to use NI's?

Hi Norm,

In an effort to keep the discussion in one spot, I have responded to your question on the OpenG thread, http://forums.openg.org/index.php?s=&showtopic=820&view=findpost&p=2070' rel='nofollow' target="_blank">here.

Thanks,

QUOTE (Justin Goeres @ Mar 20 2008, 07:55 AM)

Here's a bit of code that allows you to decimate dynamically:

It requires the OpenG Array library.

Example File: Download File:post-2992-1206024896.vi

Justin,

That looks like it might make for a good OpenG candidate

-Jim

Eugen,

I'm looking forward to seeing your blog and tutorials. It sounds like this is something that you are very passionate about. One piece of advice that would give you, is to focus on creating something special/unique that you are passionate about and strive to do it better than anyone else.

Cheers,

-Jim

There is a great discussion happening, as we speak, to debate and improve the design of a new candidate VI for the OpenG Toolkit called Average 1D Array. The discussion is happening here. If you like using the OpenG VIs and want to help improve them, this is a great opportunity.

QUOTE (Justin Goeres @ Mar 19 2008, 10:47 AM)

All that having been said, some scores do matter. For instance, I beat Jim at Galaga last year .

Losing to Justin did hurt. But, when I saw a guy roll the score counter at 999,999 I felt very small

QUOTE (Aristos Queue @ Mar 17 2008, 07:40 PM)

No such document exists. No one has asked for it until now. But I can summarize it pretty easily: If the property/method would cause a change that would be saved with the VI, that operation is not allowed on a clone. No "make current value default", change control to indicator, changing labels/captions, etc. They're called "reentrant clones" for a reason, and I don't think you've been led astray. Again, if you don't want clones, use .vit files.

File a documentation bug report if you want this documented in a future LV version. It won't be an easy thing to document -- there's no line item for that in the configuration of new properties and methods, so someone would have to run each individual property/method and determine whether or not it worked on a clone. That's pretty tedious work that probably wouldn't get a lot of priority.

If modifying tip strips is editing a VI, then how come we're allowed to do it at run-time? IMO, the design of the tip strips feature is flawed (design bug). I can understand how changing the default value of a tip strip should not be allowed in clones, since default values are necessarily persistent. However, changing the tip strip's current value should certainly be allowed, just as we can change a control's value, run-time menu items, context menus, etc.. It seems to me that any VI/Control property which can be changed at run-time that is also considered a modification that can't be performed on a clone should be broken out into default value and value. :2cents:

QUOTE (Michael_Aivaliotis @ Mar 17 2008, 04:36 PM)

Yes! I won the bet.

PS. This is bad and is definitely a crappy limitation.

I agree. If performance is the issue, then there should be some setting that toggles between these two extremes: clones used for programmatic functionality vs. clones used for user interfaces. Rarely do I care about gray areas in between these two extremes (except when debugging instances).

QUOTE (Christina Rogers @ Mar 16 2008, 06:50 PM)

Duplicating my response to Jim's comment on my blog directing me to this thread:

Jim, I see that you've already submitted a bug report (thank you!) for the problem with the "All VIs in Memory" property. I hereby officially confirm that this behavior is a bug. The referenced VI is fully loaded into memory when the Open VI Reference completes execution, but the All VIs in Memory property is filtering it out of its list incorrectly. I looked up the CAR and the developers investigating the problem have found a workaround: "Place an empty sequence structure immediately after the open vi reference." I apologize for the inconvenience, and hope this helps!

Thanks for confirming and for the work-around. I've updated the CAR# in my original post.

QUOTE (Justin Goeres @ Mar 16 2008, 10:58 AM)

If anything, I would've thought 8.0 would be overrepresented here, since anyone using it would have plenty of time to browse LAVA while they're waiting for LabVIEW to launch .

Hmm... do you think that the/a reason NI went to 8.5 instead of 9.0 is that people stopped upgrading to X.0 releases after 8.0?

QUOTE (tcplomp @ Mar 16 2008, 03:01 AM)

But LabVIEW 8.0 is just 2.5 years old isn't that a little bit too early?

A long time ago, when LabVIEW was on a X.0, X.1, Y.0, Y.1 release pattern, we decided that when LabVIEW released a N.1 release, it was probably OK for OpenG to switch development to LabVIEW (N-1).1 (for example, when LabVIEW 7.1 was released, it was OK for us to start using 6.1). When 8.0 was released, it was really buggy. This mean't that a lot of people didn't upgrade from 7.1 to 8.0. And, most people gradually upgraded as 8.2, 8.2.1, 8.5, and 8.5.1(?) were released -- but, they skipped 8.0 and went to 8.2 or greater as quick as they could. I think the fact that 8.6 is getting close to release means that it's probably OK to jump to 8.2. And, there is enough significantly new stuff in LabVIEW 8.2 that it makes pretty compelling argument for OpenG Developers to add new stuff. And, cool new OpenG features/tools will attract more people to use OpenG.

I think it's important to also re-stress the fact that this change will only effect new released of packages. All our existing code that uses OpenG in older versions of LabVIEW will continue to work.

QUOTE (Michael_Aivaliotis @ Mar 15 2008, 08:03 PM)

Michael,

Seeing the profile data would provide some interesting statistics. I'd be interested to see the LabVIEW version bin count for Primary, Secondary, and Tertiary LabVIEW versions used, with users filtered by some total post count and/or recency threshold (to ensure that the quality/freshness of data is good).

But, we should keep in mind that there is no fool-proof way to ensure that the profile data is fresh, except for new users (unless the profile data is stored in new database records each time the data is modified or there is some other profile modification time stamp).

Also, the profile contains Primary, 2nd, and 3rd LabVIEW versions used. It doesn't really ask the question: Which LabVIEW version do you use when starting a new project?

I'd be inclined to think that the answer to this question would likely be the highest LabVIEW version in the combined set of LabVIEW versions used, for each user. For example:

for each user in allUsers:	user.max = max([user.primary, user.secondary, user.tertiary])

-Jim

QUOTE (crelf @ Mar 15 2008, 12:57 PM)

It's a juggling act. I think it's noble to strip down to the lowest common denominator and support the earliest version possible, but I'm not really interested in keeping v6.1 (or 7.1 either) just to support anything I create or edit for OpenG. Personally, while I'm not going to actively go out of my way to make everything in the latest version, I'm equally not going ot go out of my way to use the oldest possible version either. I'll be aiming at 8.x from now on, but I won't be necessarily sticking to it (eg: if it makes sense for me to use LVOOP, then I'll use 8.2, etc)

Here is my analysis of the initial poll results:

• 90% of people are using 8.2 or greater for new projects
  
• nobody is using 8.0 (must be buggy)
  
• 6.66% are using 7.1
  
• 3.33% are using 7.0
  

I think that its probably safe to start using 8.2 for OpenG development. This will greatly simplify our process, since it's damn hard (in many cases) to support 6.1 and 8.x at the same time.

Certaily, we'll want to wait until more people have a chance to respond to the poll -- there are only 25 people who have voted, since the poll was created yesterday, and most polls on LAVA tend to get anywhere between 75 and 125 votes.

QUOTE (Yen @ Mar 15 2008, 11:20 AM)

We still use 7.0 exclusively, but we plan on moving to the newest version soon and will then only use 7.0 to support existing projects.

It's good to hear that you are upgrading -- you were on my list of concerns

As usual, I am curious about how people use LabVIEW -- please take the poll (above) and let me know your thoughts. This time, I'm interested in your opinions, because I want to know how best to support OpenG users. Right now, almost all OpenG libraries are compatible with 6.1 or greater. But, that means that we can't easily support certain new data types like the time stamp, 64-bit integers, or LabVIEW objects. I'm curious how many users we might stand to alienate by starting to use new versions of LabVIEW for subsequent package releases. Keep in mind that you will still be able to use existing versions of packages that support 6.1 or greater. It would only be newer releases that would be limited to newer versions of LabVIEW and these new releases would likely come, as a result of needing to support new data types and LabVIEW features.

QUOTE (Aristos Queue @ Mar 14 2008, 10:36 AM)

The only class I've put in the palettes myself is LabVIEW Object, which is built in and so the draw code knows how to draw it. The red/black pattern is just the random pen that happens to get selected when nothing has been specified, drawn at 8 pixels wide, which is the "hey, notice me, there's a problem" width when nothing is specified. ;-)

It kind of reminds me of a Flying Toaster...

http://lavag.org/old_files/monthly_03_2008/post-17-1205517813.gif' target="_blank">

QUOTE (Aristos Queue @ Mar 14 2008, 07:42 AM)

Tomi! Jim! I feel like you let me down! Here it is, 19 months after the release of LabVIEW classes, and only now someone tries to put a LabVIEW class into the palettes?

Don't worry too much -- I'm kicking myself just as much for not noticing this one.

The following bug exists in LV8.2 and 8.5. If you add a VI to the palettes that uses any LabVIEW class other than "LabVIEW Object", the Context Help for that VI, when you hover over it in the palettes, draws a funky 8-pixel wide red and black wire, as shown here:

http://lavag.org/old_files/monthly_03_2008/post-5877-1205504715.png' target="_blank">

Wow! That's news to me. I guess that I'm just used to accessing LVClass members from the LabVIEW project environment. I don't really ever think to put them in the palettes.