gleichman

QUOTE(BrokenArrow @ Apr 9 2007, 06:45 PM)

With THAT many bug fixes, they should have called it 8.3

NO!

8.3 = $$ (for those without a subscription)

8.2.1 = Free

QUOTE(ars_stowers @ Apr 9 2007, 05:00 PM)

Using the OpenG builder, I've been attempting to build a project that calls Dynamic VIs (my plugins). Each dynamic VI needs to call some VIs used in the main program. Is there any way to make dynamically loaded VIs call back to functions that are static VIs in the main application build? I've been getting Error 1003 when I try to do this, and it isn't an issue (as far as I can tell) with vi.lib files or anything like that, but rather the VIs called by my dynamic VIs that are part of my main program.

I would think about creating extra copies of the needed VIs or name mangling them with different names to create copies, but they need to be the same VIs because I'm using them for memory (non-initialized shift registers) as well as for the actual functions they perform.

Sorry if this is totally unclear, I've tried to be as clear as I know how. If you don't understand, ask questions and maybe I'll be able to give you a better explanation that answers your question.

I am a bit confused.

Error 1003:

LabVIEW: The VI is not executable.

You mention that this happens with projects that use the OpenG Builder. I assume that this means that your program works in development mode, but not as an executable. Is this true? The error code seems to indicate otherwise. Have you checked all of your dynamic VIs to see that none of them are broke (broken run arrow)?

There should be no problems sharing VIs between normal and dynamic code. I have done this for many years.

QUOTE(gleichman @ Apr 9 2007, 01:51 PM)

Traditional NI-DAQ VIs were removed from my 7.1 installation.

A friendly application engineer found the fix for this problem.

http://digital.ni.com/public.nsf/allkb/52EA1C0398769358862571C60074FF74' target="_blank">http://digital.ni.com/public.nsf/allkb/52E...62571C60074FF74

I had no problems during the actual installation. Total time to install was about two hours.

In the two hours since installing, I have found some problems.

• The report generation llb "NIReports.llb" was over written over the standard llb. Make a backup of this file before installing if you use the Report Generation Toolkit.
  
• Traditional NI-DAQ VIs were removed from my 7.1 installation.
  

Well, now I know what I will be doing this afternoon.

• Mindstorms NXT :thumbup:
  
• Wii :thumbup:
  
• Eleven year old assistant :thumbup:
  
• Yard work to avoid :thumbup:
  

QUOTE(Jim Kring @ Mar 26 2007, 04:30 PM)

The symbols for items 39 and 40 are swapped in the Listbox Symbol Ring Constant. Please see the attached example VI and annotated screen-capture.

This has been reported to NI in the latest beta program, so hopefully it will be fixed, shortly.

http://forums.lavag.org/index.php?act=attach&type=post&id=5304

http://forums.lavag.org/index.php?act=attach&type=post&id=5305

Would it be wise for NI to change this? These symbols have been in this order since they were introduced in LV8.0. If they changed it, it would break all code that used these symbols and worse yet it you would only know it if you read the release notes and remembered that your code used these symbols ... no broken arrow. The only viable solution would be to add to more symbols in the correct order and that would certainly cause some confusion.

QUOTE(Aristos Queue @ Mar 26 2007, 06:22 PM)

Search in the palettes for the "First call?" primitive. Wire that boolean output to your case structure. That prim will return true the first time it is called, but false thereafter. If you stop the VI running and restart, the prim resets.

First call works well if you only want the case called only once during program execution, but if this is a subvi that needs to be initialized each time it is called you should use a shift register.

Have you looked at the "Configuration File VIs"?

This bug causes typed data entered the time before last to disappear. (Does that make sense?) Here's how it works:

1. Click on cell 1 and enter data.
   
2. Click on cell 2 and enter data.
   
3. Click on cell 3 enter data and then click outside of the listbox.
   
4. Data in cell 2 disappears.
   

To perform this magic trick, your code must have the following.

• Set the "Edit Position" when the listbox is clicked on.
  
• Trap the "Edit Cell?" event.
  

I've attached a simple example (LV8.2) and cross posted to the NI forums (no CAR and no responses).

Download File:post-151-1170292612.vi

Where's the burning river?

At least we have water.

I have an application with moe then 2000 vi's, when i want to update an enum typedef labview crashes!

A work around is: open only the enum typedef, change and save it and after that open the big application.

I've had a similar problem with Type Defs embedded within Type Defs (LV 8.2). My solution is to open all related Type Defs and then make my changes. If I follow this procedure, LabVIEW does not crash.

The online help will show whether you have an array or a subarray when you hover over an array wire.

That's a cool feature that I didn't know! This would make a good nugget for Darren.

Thank you for the detailed response. After reading your post, I made another version of my test VI "Method 2" that did not transpose the array, but instead indexed the column inside the For loop. This new VI gave the same bad results as before, so it does not appear to be the fault of the transpose array.

Download File:post-151-1169307909.vi

It's good to know that this will be fixed in the next release and for now I have a work around.

That's a bug with TDMS. TDMS Write will handle subarrays either correctly or incorrectly, depending on what array dimension the "sub" applies to. Apparently, the "transpose array" you are using on the output of the "item names" property puts out the kind of subarray TDMS Write struggles with.

There are 2 related issues you might need to be aware of:

- Several TDMS functions have problems working with subarrays wired to "channel names".

- TDMS Set Properties doesn't appreciate subarrays for either "property names" or "property values".

All of these issues are fixed by now. I ran your VI with a current LabVIEW dev build, and all three cases work just fine.

For now, the workaround for all of that is to turn the subarrays back into regular arrays, which is what the additional for loop is doing in the third case. If you place that for loop right behind "transpose array", the whole VI is going to work.

Sorry for the inconvenience.

Herbert

I made my first attempt at using TDMS files yesterday and I had some unexpected results. I was using TDMS files to store data from a multicolumn list box control. When I wired the ItemNames property to the data input of TDMS write, the resulting data file did not match the data coming out of the property. Only after running the data through two for loops did the data save correctly. The following images and VI illustrate the problem.

The Data:

Method 1: Single write

Results:

Method 2: Wrap the write in For loop and write one column at a time.

Results: The same.

Method 3: Add For loop in the For loop that does nothing.

Results: Expected data.

Download File:post-151-1169298761.vi

Is this my bad, a bug with ListBox data, or a bug with TDMS?

It's very impressive, but it ain't NXT. From what I saw in the video, the many controllers used to run the assembly line are the older RCXs from Mindstorms 1.0 - 2.0. Using NXT controllers would probably have made the project much easier, but very expensive.

Hmmm ... I wonder what I could make with my two RCX systems and my son's NXT. But first I need to finish installing a new light fixture.

I don't know if this should be in the Rube Goldberg section but it is implemented with NXT.

It gives Fieldpoint a run for its money.

Enjoy.

B.

I just got this in the mail since we had our NI-Week 2006 BBQ there - I thought I'd pass it along

Or you can view their catalog online and not get a crick in your neck www.saltlickbbq.com/. I'm still working my way through the bottles of sauce that I bought there at NI Week. I thought for sure that the sauce was going to end up all over my clothes since the ban of liquid carry-on happened during NI-Week, but it all made it home safe.

I could sure go for some Salt Lick brisket.

I'd believe another honest engineer from your own company if they said you had had them on your desk previously, but I would have a hard time believing you, even if I saw them myself during a visit to VIE in MI. I would suspect you had put them on the day before just to mess with someone.

I'm not a VIE employee (but hopefully an honest engineer) and I have seen a large picture of the Queen hanging in his cube the last time I visted (about a month ago). From my experience with Chris's minions, I don't think the picture does much to reduce the volume of nerf projectiles. In fact, it will probably get worse real soon. :laugh:

I think we have lost track of the original subject ... The mis-casing (is that a word?) of LabVIEW. I received two resumes today, both which perported to know "Labview".

maybe you could use a cascading contextual menu instead. See attached example

Download File:post-731-1159806566.zip

This will work. :thumbup:

I can get rid of my ring controls all together and use a list box for the left click events and to store the results.

Thanks for the example.

Like a custom right-click menu? You can do those in 8.

Yes, like a right-click menu, but as a left click on a ring control.

I'll start the ball rolling (pun intended) with a nice cup of tea...

It's hard to top the Honda commercial from a few years back called the cog.

I have a UI that uses a ring control. The problem is that usability decreases as the number of items increases. It would be nice if I could categorize the options kind of like the Windows Start menu. Has anyone done something like this?

and pretty much sums up my favorite US city...

Ouch!

Although there are too many areas like those depicted in the video, I don't think this video sums up the city.

I work for a German auto supplier, and many of our vistors from Germany are quite shocked that most of the Detroit area is much nicer than our reputation.

This function is generally used (as it is in your example) to be a counter reset. If you feed an index into X and a reset value into Y then the output R will count up with the index until it reaches Y then it will reset and start counting from 0 again. The output Q will give you how many times this has happened.

Example:

Save data every 200 loop iterations.

X=i (loop index)

Y=200

IF R=0 THEN save data

Ok, I just couldn't help myself. Here is the mouseover 'brat' just so you can see how it's done.

And for all that attended, thank you very much. I was overwhelmed by the turnout; people standing in the back and even sitting in the aisles.

Thank you for posting the smart cursor brat. I have been trying to recreate this since I saw your demonstration. I made a similar "brat" a while back that is less efficient because it polls the mouse position, so I wanted to give your version a spin. Unfortunately, you forgot to bundle "Tool - Get Parent.vi". I know this is just the indexing of the call chain as discussed in the session, but you might want to add it to the zip. My bigger gripe is that you have password protected "TRef Traverse for References.vi". I would REALLY like to see under the hood of this VI.

Thanks again for an insightful presentation.

Alan

Google has a new feature that shows trends in searching. Google Trends

Google Trends aims to provide insights into broad search patterns. As a Google Labs product, it is still in the early stages of development. Also, it is based upon just a portion of our searches, and several approximations are used when computing your results. Please keep this in mind when using it.

Here is what it shows for LabVIEW.

It's not the trend I expected.