Ed Dickens

Has anybody tried to open this tool in either 8.0 or 8.2? I get an "Fatal Internal Error" and LabVIEW shuts down. Ed

The quick and easy answer to your original question is... there is no quick and easy answer If you're already familiar and comfortable using C and don't really know LabVIEW that well, you'd be better off sticking with C. LabVIEW Embedded does make it easier for the non-embedded programmer to program an embedded target. But why go through another learning curve if you don't have to. And the $10,995 price is a huge investment if this is just a single small project. On the other hand, if you struggle with C and know LabVIEW pretty good, then a switch to LV E might not be a bad choice. Development time can be significantly less and you have all the nice LV debugging tools. There are some differences between LV and LV E as far as application optimization, memory usages, array and constant handling and a few other things that can bite you if you don

I've been experiencing this same problem. I have several charst and XY graphs on a couple tab controls. The mentioned workaround does help, but it something that needs to fixed. Ed

We've already talked and looked into subversion. We haven't ruled it out yet, but we want to try a get everybody on the same system, and the majority of the company (they all code with words, it's really wierd ) is currently on VSS and most of them like it, or at least say it good enough for they use it for. I guess the one big issue we're having with the CVS and why we just haven't made the switch is so far, our IT guy has not been able to get it up and running so we can try it. Though we've all been so swamped lately we really haven't had time to try and work the issues out. Ed

Has anybody used StarTeam with LabVIEW? What I'm really wondering about is does it handle LabVIEW's file format better than MS VSS. Our company is considering switching from VSS to something else and StarTeam is the leading candidate because our biggest customer uses it. Thanks Ed

The "polarized" method for the "Polar Express". That makes sense. Ed

I'll keep my eyes open. I'm trying to get Phillip to give me the "insiders" tour of the campus, so you never know what I'll spy. But as Ben said, I may not be able to post what I see in pubic. Ed

The type of control/indicator does not make a difference. They are all treated the same. If I do need to use a property node from some reason, I always set it up so that it is only written to when it needs to be. This way you get the overhead hit when needed instead of every iteration of the loop. Ed

Just curious here, but could you use the controls "Caption" or "Label" or as your identifier? What are trying to accomplish? Ed

Here's a quick demo VI to show the difference. This isn't actually the best way to do this because they are fighting for processor time when all three are running, but you'll get the idea. In general, ALWAYS wire directly to the terminal when you can. If you have to update the value from somewhere else or need to write to a contrl, you should use a Local Variable. You should only use a Property Node>Value if you have to change some other property of the control/indicator. No use in taking the hit for the property node than the hit (though not much of one anymore) for the local. The artical linked above is a good explaination of what is going on in the background. Ed Download File:post-47-1144765353.vi

I have an update from the app. Eng. (Eric Sulzer) that's been working with me on this. The behavior we're seeing in 8.0 and 8.0.1 is an intentional change from 7.x. In LabVIEW 7.x, type definitions wil update non-datatype information (such as item names and values) once and only once when switching between datatypes. In LabVIEW 8, however, a conscious decision was made to not do this update, so that is why we see the default enum values after you replace an enum with a ring. If you do wish to carry over non-datatype information when switching datatypes, it is recommended that you simply change it to a strict type def, save and update, and then switch it back to a regular Type Def. So this actually isn't a bug, it's the corect behavior for 8.x. Ed

I've run into a bug in 8.0.1 involving type defed Ring Controls. The problem is if you create a Ring Control with non-sequential values, make it a Type Def, change the type defed Ring to an Enum, then back to a Ring, the values in the already existing instances of the control will not contain the correct values. I've already reported this to Support and I'm waiting their answer. The steps to reproduce the problem are below. I've been able to reproduce this on two different PC's both running LV 8.0.1. Create a blank VI and drop a Ring control. Open the Control Editor for the Ring and change it to a Type Def Edit the Rings items to add 3 or 4 items and uncheck the "Sequential Values" checkbox and change the values to something other than the default 0, 1, 2... I was making a ring to define custom error codes so I had 5001, 5002, 5003... Save the control, apply the changes and close it. Then I decided I wanted it to be an Enum (I forget why), so opened the Type Def, replaced the Ring with an Enum, saved, applied and closed. Then I remembered the Enums values are 0, 1, 2... so that's not going to work for my error codes. Re-open the type-def, replace the enum with a ring, edit the values back to my error codes, save, apply close. Turn on the digital display of the control on the VI and you'll see the values are 0, 1, 2... instead of the values from the type def. Open the type def and verify it contains the correct values, it does for me. Now, open the type def again, drag the icon to the front panel to create a new instance of the control and it contains the correct values. So now you have two instances of the same type defed Ring control that contain different numeric values. Make the Digital Display visible to verify this. Now, change the Type Def to a Strict Type Def and everything contains the correct values. I do not see this problem in LabVIEW 7.1. Can somebody check 8.0.0? I'll update when I hear back from Support Ed

Thanks Bob, next time I see you, I owe you a beer. :beer: These VI's do just what Jeff said to do, they're just already built for you and have all the correct waveform attributes spelled out so you don't have to remember them. Pretty handy. Ed

Well, so far I've seen no major issues on the first of these PC's. My 1000+ VI test application on the first station ran all day yesterday without a hitch. I'm just starting to build the second application for the second one, so I won't know for a while. OpenG Commander installed OK if that means anything to any one. I forgot about the "No bold text on required subVI inputs" problem yesterday and didn't look to see if the first PC had this problem. It's at a different location so I can't check right now, but the second one has lost it's bold text. Ed

Just curious if you installed the 8.0.1 patch and if this is the first time you opened the Finder since then. Ed

UPDATE: Renaming the ini file may not completely fix this problem. NI support sent me an updated "_exfinder.llb" that explicitly sets the language to English. This file is located in the "Help" directory of the root LabVIEW 8.0 directory. They say they still don't know what caused it, but they do have a plan to fix it if that makes sense. The updated _exfinder.llb is attached if you happen to run into this problem, but I would only use this if you use the English LabVIEW as it forces the Exmaple Finder to English and ignores the token that normally sets this. Ed Download File:post-47-1142269920.llb

I've got two identical desktops that I'm applying the patch to this week. There's nothing on them except WinXP, Office, LabVIEW and the needed drivers. We'll see how that goes. Ed

Thanks Jeff, that's what I afraid I would have to do. I thought maybe there was a function to set this name like the Set waveform attribute function for waveforms. Ed

I'm surely missing something obvious here. Is there a way to set the "Siganl Name" attribute in a Dynamic Data wire that contains multiple signals? Thanks Ed

My splash screen is fine. One thing I did notice late yesterday is in the Context Help window, the "Required" inputs on VIs and Functions no longer show up in Bold text. Anybody else see this? Ed

The Example Finder may show up in a different language. Somehow, the token that sets the localization settings is getting set for the Example Finder. The 8.0.1 patch may trigger this. Reported to and confirmed by NI. They have created a bug report and are investigating. A workaround is to rename the Example Finder "NIExampleFinder.ini" file found at "..\National Instruments\Shared\Example Finder\1.0\BIN". The Example Finder defaults to English if this file is not found. NI Dev. Zone thread Ed

And let me guess, your LabVIEW installation is French? OK, probably not and it's probably just me. After looking at the ini file a bit closer, it contains all the localization information, not just French. That just happens to be the first section. So something is telling it to use the French section. I just talked to support and they have not seen this happen yet and the French version of the 8.0.1 patch hasn't been released yet. :headbang: UPDATE: Support has confirmed this as a bug, but it may not be directly related to the 8.0.1 patch. See the 8 Buglist for more details. It's been available for quite a while. It's called CVI. Ed

Has anybody else opened the Example Finder after applying the 8.0.1 patch? Everything else is still English. The Example Finder ini file is French as well. Ed

I'm not sure how long it took. I started the mass compile around 7:00 and at 11:00 it wan't finished yet. It was done the next morning. This is on a P4M 1.6GHz laptop. I also noticed there is an 8.0.1 RealTime RTX update an 8.0.1 PDA update, but only via the FTP site for now. RealTime RTX 8.0.1 and a Readme ftp://ftp.ni.com/support/labview/labview_.../Windows/8.0.1/ PDA 8.0.1 and a Readme - Now supports some of the enhanced Windows Mobile 5 OS features - See the Readme for info ftp://ftp.ni.com/support/labview/pda_module/updates/ Might be few more if you look around. Ed

I use them to programatically switch between different UIs. The tabs are hidden in the executable. Application configurations options on one tab, main program controls on another, file I/O on one, usually a hidden one with stuff the user doesn't need. It varies from app to app. I'm creating a new application for a test station right now that I will use two Tab controls on. The test stand has two separate, but identical test stations in it and they want to be able to be running test independently from each other. So I'll divide the panel using two tab controls. I thought of using the splitter, but I don't want to have to cram everything onto a single panel and it needs a password protected "supervisor" screen to setup test limits and script new tests. Tabs work good for that. Ed