Dan DeFriese

Try: http://opengtoolkit.cvs.sourceforge.net/viewvc/opengtoolkit/pipe/

There is a symbolic path, [iNSTALLDIR], that you can use in the installation builder for this purpose. See attached.

Just out of curiousity... What's the use case for applying password protection on the VIs? I've never really thought about this before. ~Dan

No I've never done it but you should be able to iterate through your VIs using the LockState.Set Invoke Node. There is also a setting for applying a password to source in Source Distribution build spec. Okay just created and example which will set a password on all VIs in a directory recursively - BE CAREFUL what you point it at Batch Password Example.vi

My imagination is limited so I selected the context help - it sends you to '(Incomplete) Beta Function'. So I'd guess that either it dropped off someone's radar at NI or there was a problem with the implementation and someone forgot to remove it (and dropped off the radar ever since!).

Hey Jon, There is a little task manager tool that was discussed a while back. Maybe it can help you. http://lavag.org/topic/14921-labview-task-manager/page-2 ~Dan

I've never seen the lvlib resort to absolute paths, but if it is modified while in the LabVIEW directories (vi.lib, instr.lib, user.lib, etc...) it may get saved with symbolic paths instead of relative paths. As in this example from my instr.lib folder: <Item Name="Aardvark Convert Error.vi" Type="VI" URL="/<instrlib>/aardvark/aardvaru.llb/Aardvark Convert Error.vi"/> <Item Name="Aardvark GPIO Set.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Set.vi"/> <Item Name="Aardvark GPIO Direction.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Direction.vi"/> Could your source have been in these LabVIEW directories? ~Dan

The simple answer it that clock speed is the only contributing factor to performance. In either case, it appears your application needs some attention with regard to efficient programming techniques. My first step would be to run the program in your development environment and use the Profiler (Tools -> Profile -> Performance and Memory) to find which parts of the program are consuming the most resources. ~Dan

Sorry I didn't realize this is a homework assignment. In that case, you can learn about TFTP and implement your own solution by reading RFC 783 and RFC 1350. This will also give you an understanding of what chunks are. Good Luck! ~Dan

There's a TFTP example on the NI website: https://decibel.ni.com/content/docs/DOC-8301 No need to reinvent the wheel.

This is not a bug. Rings are not bound to the string values like they are in an enum. This is why you can change the strings in the ring, but can't change the strings of an enum at runtime. LV's Help explains it better. See: "ring controls, compared to Boolean and enumerated type controls " in the LabVIEW help.

I fail to see how that is a problem.

I couldn't agree more. The best thing I took away from the CLD is that my approach was way too complicated for what I was being asked to do. My submission was good-enough to pass, but I didn't complete all the features. I've really concentrated on the KISS principle ever since. Thanks NI!

From the manual's example code in QBasic. OPEN "COM1:1200,E,7,1,DS,RS" FOR OUTPUT AS #1 I see that the port settings are Baud Rate = 1200 Parity = Even Data Bits = 7 Stop Bits = 1 ...and there may be hardware handshaking "DS,RS" (I've never actually used QBasic... just seen it once on the History Channel!) Are these the settings you're using?

Have you looked into to pointing the user(s) to Signal Express? It sounds like you're reinventing the wheel here.

The Resolve Confict dialog(s) are forced upon me occasionally when I move stuff around intentionally. That feature upsets me so much I have to go get a cup of coffee after 1-10 minutes of arrow-enter . Can we vilify that feature?

Why should we have to stop? I don't know about "disabling" a feature (except that damn conflict dialog), but being able to configure which toolbar buttons are visible seems very reasonable to me. MS Office has provided this capability since as long as I can remember. I don't care for the BD Clean-up either so I deleted the CTRL + U menu shortcut in the options to prevent inadvertant use on my system.

From your code it looks like your trying to open a reference to your VI using the full path. As I recall you should only need the VI name when opening a VI reference from the executable.

You don't need code for this. I read the Snapple Fact the other day: The average person take 28800 breaths per day! But seriously, we can't do homework for you. Show us what you've done and where you think you need help. ~Dan

Sounds like you could use a subpanel control on your main VI (top-level front panel) to select between your 3 subVIs. Look at the "Subpanel Viewer.vi" in the Example Finder. (Help -> Find Examples...). ~Dan

I couldn't open the other example since I'm still on 8.6, but here's a quick example that I banged out a while ago for a team mate and was still on my desktop. Well evidently I'm not permitted to upload a *.lvproj file. But you should be able to add it to a project an run it. Sample.vi

The 'Advanced' page of the installer properties allows you to specify an executable to run after the installer completes. In the past I've used this feature to lauch the 3rd party installers. (I create a small .exe in my project which gets placed in the TempFolder by the installer. After the NI stuff gets installed this temp.exe runs and calls the 3rd party installers located on my install CD.) It's certainly not perfect but it usually works for me.

Thanks for expaining. Personally, I'd prefer a standard messaging architecture. When a VI exits unexpectedly (assuming this is what your trying to catch) I'd want to no why. That is, the error value on exit. While I can see how a built in event would be easier, I'm not sure if it would be more useful than queues and notifiers to my typical usage. ~Dan

How would this event be more useful in managing spawned tasks? (As opposed to using and messaging primative queue, notifier, user event.) If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless. I don't mean to knock your idea. I'm just missing how this would be useful.

Well, even though it’s not true. I sometimes pretend it is. I certainly take no offence since NI hardware just seems to work better and more reliably than the cheaper crap people bring into the lab. Even those poor C\C++ programmers down the hall agree, eventually.