gmart
-
Posts
148 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by gmart
-
-
QUOTE (Yair @ Jan 29 2009, 11:42 AM)
I would say that in the strict sense of "what is a password?" this is a bug. For the purpose of the argument, suppose I open a web browser and log into NI. Does that mean that when I go to LAVA I should be logged in automatically if I use the same name/pass combo? Suppose that someone decided to lock their VI and they just happened to choose the same password I did. That would mean that unlocking my own VIs would unlock theirs as well, even though I would probably not think of trying my password on their VI.Obviously, most people who really care about protecting their code probably choose a password which would be unlikely to be used by anyone else, so in the real world this is more an ease of use feature which allows you to unlock a group of VIs together.
I see your point, but I think a better analogy is that when you log into your Amazon account and select the web site to remember you, a cookie is placed that lets you log back in again without having to enter your information (including passwords). Obviously, a password entered in another app should not apply to LabVIEW. Within LabVIEW, I am guessing (I do not know for a fact) that the caching is for ease of use. While "better" security might be to ask for passwords at all time, it makes operations such as mass compile or common development actions could become unwieldly. Could two VIs from different developers have the same password? Yes. I think that scenario would be rare though (so don't make your passwords "12345"
). -
QUOTE (neBulus @ Jan 29 2009, 09:24 AM)
Bug?Based on the fact that we have an option undr tools (?) "Clear Password cache" NI did put some thought into keeping the password in a cache. Ibeilive this is what makes it mposible search an entire hiarchy and only have to enter the pasword once for all VI protected by that password.
Just sharing my thoughts,
Ben
Once a password is entered, it stays cached until you restart LabVIEW or clear the cache.
-
Check for any network printers that can no longer be accessed. LabVIEW looks up printer settings when the VI Properties dialog comes up. If a network printer is no longer accessible, then the dialog times could take while before it times out.
-
QUOTE (bluesky @ Oct 17 2008, 11:56 AM)
My service request number is 7212358. NI tech support confirmed that this was a know issue.bluesky
Thank you for the information. There appears to be a slight slowdown in general, but not an across the board 2x difference. Some applications have been reported to be slower by this factor, but it is on a case by case basis. Thank you for reporting this.
-
QUOTE (bluesky @ Oct 16 2008, 06:40 PM)
Norm,I started a Service Request for the same issue. According to NI this is a known bug with Labview 8.6 Build times have more than doubled between Labview 8.5.1 and Labview 8.6
bluesky
Do you have the service request number? I am not aware of build times slowing down by 2x between versions. In your particular situation, do you have build times for both 8.5 and 8.6?
-
QUOTE (km4hr @ Oct 16 2008, 11:19 AM)
I work for a university so perhaps I have it already. How would I know? I'll check with our license coordinator.Thank you all for helping this newbie (1 week experience) with what may seem like trivial questions. I hope to get beyond the struggling stage shortly.
thanks
You can create a new LabVIEW project (File>>New Project...) which will have a Build Specification node. When you right-click on it, you will see a list of build types you can create. If the application builder is present/licensed, you will see an option - Application. You can get more help regarding build specifications by selecting Help in the right-click menu.
-
QUOTE (Vladimir Drzik @ Oct 15 2008, 07:49 AM)
Thanks for the suggestions. I am trying to follow the non-locking model, allowing multiple checkouts for text files. However, LabVIEW's SCC integration always makes exclusive checkouts. Which effectively prohibits me from using merging together with the SCC integration. Can you think of a way how to get around this?Vladimir
Typically, you can configure this within the SCC provider's client. If you are using the Perforce Command Line provider, in the Tools>>Options Source Control page, the option to not lock files is located as an advanced option.
-
-
QUOTE (Chris Davis @ Aug 29 2008, 02:57 PM)
I checked, and Michael is right. The bigger question is, does the built in icon editor support more than just 48x48 256 color icon creation? In 8.5 that was the most it would support. I don't have 8.6 (yet) so I can't check...In 8.6, the built in icon editor does not support icons larger than 48x48. Fortunately, there are now many third party icon editor programs that do a good creating and editing "Vista" style icons.
-
QUOTE (Darren @ Aug 29 2008, 09:50 AM)
I understand your concern, but if we just receive a bunch of INI files full of the same tokens (because everybody stuffed their files with tokens everybody else uses), the study provides NI with no useful information, and this benefits no one.So do what you want, but I feel that the best way for this study to benefit the LabVIEW community would be for everybody to submit the INI files they actually use.
-D
Plus the fact that we have your INI token that you care about, places it in the ">0" bucket :thumbup:
-
QUOTE (Yair @ Aug 28 2008, 01:53 PM)
YES!!!George, can I please get the award for the most stupid CAR ever? It doesn't have to be a cup or a medal. A nice plaque will do fine. :laugh:
Regardless of the intelligence level of the CAR
, crashes are never a good thing. 
Now just because it's CAR'd doesn't mean it might not end up being filed under the "who in the their right mind would make a 10000 frame stacked sequence structure AND THEN replace it with a flat sequence" bucket. That, truly is an honor reserved for a very few.
-
-
Analysis support is a component of the Run-Time Engine. The installer has an option to include (the default) analysis support. You could verify in the Advanced Installer settings that the "Analyze VIs Support" is checked. You could also try reinstalling just the 7.1 RTE (which I believe you can download from ni.com).
-
QUOTE (Darren @ Aug 21 2008, 04:36 PM)
Not so fast...before the defense rests, you should call your first witness, Darren, who has advocated Flat Sequences as a perfectly legitimate UI programming structure for many years (when was the 7.0 release?), for the very reasons you have cited.-D
P.S. - Stacked Sequences, however, are pure evil. Just want to make sure there's no question on that.
This discussion reminds me of a NI Days presentation I did where almost every customer told me that they don't use local variables because NI "told them" not to. Instead many were using control references wired to a property node to read/write the value property. I explained that that method was much much slower in execution. Many were shocked. I stated that locals do have their place in LabVIEW code.
So the same can be said about sequence structures - flat or stacked. They are not intrinsically evil (they're just drawn that way). They are a tool that should be used properly.
So I agree with Darren and Aristos on the Three Button dialog. Yes, it could be implemented another way, but the current implementation is not an abomination. What was an abomination (please forgive me Aristos
) was what that VI looked like *before* a flat sequence was used 
. -
-
QUOTE (Ton @ Aug 15 2008, 11:39 PM)
Well they got a very nice website.This 'customer success story' indicates there is support via the MS SCC interface.
However on the website there are no other references
Ton
I found a download page for the AccuBridge for Microsoft SCC integration here - http://www.accurev.com/download_ab_2008_2.htm#note3
Assuming that is their support for the Microsoft SCC interface (pretty good chance), in theory, it should allow usage of Accurev from within LabVIEW.
-
QUOTE (Val Brown @ Aug 16 2008, 03:31 PM)
I actually solved the problem by a back door process. I saved a top-level VI from one project (that didn't have the build specs I wanted) into the project that did have the build specs I wanted to use. A little bit of editing of the overall project to duplicate the virtual folder structure and I'm done.I'll try the attachment process again so I can generate the error and post the exact error message. I'd really like to know how to do attachments and I suspect I'm just not following the correct procedure here for the forum.
There is no built in mechanism to copy build specifications between projects. Since the build specification information is saved in the project file, you could perform a Save As on the project file which will copy the build spec information. One challenge with copying build spec info to another project is that files in the target project may be different than the source project. What would be the best way to handle that? Would the expectation be that the build spec should work or that the user would need to "fix it up"? In general, it is not desirable to create new items that are immediately "broken" so that has been a hurdle to having this feature available.
-
QUOTE (jdunham @ Aug 13 2008, 04:50 PM)
So If I don't want to check out the callers, because I don't want to recompile just yet, can I get any work done, or will I constantly be asked to save changes every time one of the callers leaves memory?You will be asked to save the caller when the caller is in memory. You won't need to save it since LabVIEW will automatically apply the change the next time you load. You will want your final released version saved since automatic recompiling will cause performance to be impacted. This behavior is not specific to using SCC.
-
QUOTE (jdunham @ Aug 13 2008, 02:49 PM)
How does the SCC plug-in handle times when you change a typedef and several hundred VIs automatically recompile?There is an option in Tools>>Options>>Source Control where LabVIEW will include a list of callers of a VI that are in memory when checking out a file. So in your example, when you check out your typedef, if the callers of the typedef are in memory, those will be added to the list of items to check out. Something to be aware of. By default, the source control dialog box is not displayed during a check out operation. So when callers are in memory, you may get a warning dialog stating that other files will be checked out. If you do show the dialog box, the callers will be listed in the dialog box. The same behavior happens for subVIs (for the use case where you change the connector pane configuration for example).
-
-
QUOTE (Tom Bress @ Aug 12 2008, 07:34 AM)
The list on the NI website says that you need a low-cost third-party plug in to use Subversion with LabVIEW, but this statement is incomplete and somewhat misleading. What it means is that if you want to access the SCC functionality of Subversion from within the LabVIEW development environment then you need a plug-in. But if you read Jim Kring's blog posts on the subject, as well as the comments of others in the LAVA forums, I think you'll see that the beauty of using TortoiseSVN is that you DON'T do your SCC from inside LabVIEW. TortoiseSVN makes it easy to do your SCC from your desktop without opening an SVN client program. Bottom line: you can use Subversion and TortoiseSVN for free, effective SCC without any other plug-ins or programs.The text in the knowledge base states This integration enables LabVIEW users to access the source control providers from within the LabVIEW development environment. That statement does not imply that you can't use external tools to perform source control (as is done with Tortoise). Also, using the integration in LabVIEW gives you functionality such as prompting to check out on edit that you wouldn't get by using an external tool.
The selection of an SCC provider depends on your needs balanced with cost. SVN is a good package and is very popular in this forum. Internally, NI uses Perforce. Perforce has a license model that is essentially free for a 2-user version.
-
One thing to keep in mind regarding the change to the Report Generation Toolkit. When you build an application that uses VIs that are part of the toolkit, you will run into the name collision issue where some files will be placed outside of the executable.
-
Someone needs to start a pool to see how long it will take for some bored TSA employee to post the images to YouTube or somewhere else. Anyone who has stock in the maker of the scanning machine should be ready for that day.
-
QUOTE (Norm Kirchner @ Jun 17 2008, 08:07 AM)
http://developer.mozilla.org/devnews/index...0-utc-10am-pdt/
High noon Central time.
vi to exe file
in Application Builder, Installers and code distribution
Posted
QUOTE (Antoine Châlons @ Jan 30 2009, 07:47 AM)
To clarify, in order to build applications (i.e. EXEs), you need the LabVIEW Professional Development System or LabVEW Base/Full with Application Builder. For LabVIEW Base/Full, Application Builder is an additional component that is purchased separately - http://sine.ni.com/nips/cds/view/p/lang/en/nid/10731