todd

I vote for the lvclass, ctl, lvlib and vi files to be "locked-no password" during the Post-Install Custom Action in VIPM (or VIPM pro has a checkbox that does this).

Just a NIC: http://en.wikipedia.org/wiki/Network_card Be aware that some functions (such as UDP and TCP VIs) may require static routing (C:Userstodd> route add ...)

I bet that was purpose.

Are you sending the nested actor's VI ref to the parent for insertion into the subpanel? If so, I suppose the caller's insert method doesn't do anything else? Even so, is there a chance the caller is busy with other methods and doesn't get to the Insert in a timely fashion? I tried putting config file reads in pre-launch init, for a while - then I stopped doing that. My pre-launch inits are very lightweight, now. Lately, I send the subpanel ref to the actor in its class data before calling launch. If the nested actor sees that it's a valid subpanel, it inserts itself. Otherwise, it opens its FP - or remains headless. A subpanel ref can be sent in later, if needed.

You should have several from me from last night . 2012 kept crashing, then hanging. Forcing recompile on each Actor Core.vi, saving all, mass-compiling (for good measure), and restarting LV eventually got it working again. I think the troubles began when I changed some reference controls in a STD that is part of the private data in one of the actors. (I can submit this project to NI, if that's useful. Maybe if I get a repro, first.)

At least there was a price! (One of the sites didn't even list a price. Always look on the bright side...)

There were bugs with PNs early on, so I avoided them - and it stuck.

Every post you make has a link to yiigo.com. You must really like their code! Even if you haven't checked the cost and licensing conditions. I don't see any mention of cost other than requesting a quote.

How about making a child class for the user, put the class data in the parent, and require the accessor to call parent node?

There are USRs in the ptbypt. That will be a problem. There's a good explanation of how to address this on pages 45-47 of this document: https://decibel.ni.com/content/docs/DOC-30870

Theory and simple example code complement each other. Maybe one way to go is to show a simple implementation of a particular concept in each AOP style: AF, AA, QSMLH (queued-state message-loop handler). As to the multiple choice question: all of the above. Actually: 2.a+e: A few simple sample actors, where each one has a different type of helper loop: no loop, self-messaged loop, free-running (timeout) loop, etc. 2.c+d+b: A few simple message types: raw-queue producer-consumer (data only), queued message (command + data), AF message. MAYBE self-addressed messages: pass a notifier with the queued element, etc. Have I used the word "simple" enough? Keeping the code simple makes it easy to understand quickly. Then, switching between the different methods allows the theory to stay in my mind. After seeing Jack D's events presentation, I understand why people were saying such good things about him. He showed many ways to make things happen, and they were all simple. The cooler example is too involved to quickly understand - the theory would get lost under the wires (unless one already knows AF, in which case simple code can teach the theory just as well as more complex code). If you want, I'd be happy to code up some simple AF examples that correspond to the functionality of some AA examples (maybe AgAc, instead?). Plenty of people can do it better than me, but I can handle simple!

"Just looked now. There are only two frames. Exit and "No Event", Default." Try "Project -> Create Project", instead of "File -> New"

Cool, thanks for posting this! It reminds me a little of the panel handling in ALOHA. I'm in the (background) process of writing an AF child that encapsulates all the panel handling (and announces data streams).

"The biggest problem with showing example code is people fixate on the implementation details instead of the principles being taught." "My perception is most people learn LV largely on their own." "... I do sometimes worry about the consequences of teaching my competitors how to be better programmers." These statements have convinced me to not ask for code. This morning I was thinking, "Well, how will these lone-rider developers learn to manage their breathing on long shots if they're busy shooting snakes from the hip." (Then I had some coffee.) I learned LV on my own (if reading info-labview and lava during 6i counts as alone). Theory was great, but example code was golden. Only after seeing the data flow through the wires did the theory turn into something useful. "I put that quote in my sig because I thought it was funny." It is funny. When I mentioned it earlier, I was whining (on the inside) about Staab not sharing his presentation. He posted a top-level actor launcher, once, that I learned a lot from (read: totally stole). I haven't provided anything to the community, so I'll quit waiting for other people to show me how to code. "Believe it or not I don't hold back information I think would benefit other developers in the community." Lapdog taught me a lot, too (thanks!). Presentations are all about the audience. Talking theory is useful, unless I don't know how to turn it into wires.

Just watched the video, Dave. I liked it! It is a good summary of the terms and thought processes that you and others have discussed here on Lava over time. It made me feel good to be able to understand what you were talking about. As for improvement, I agree with Neil that examples would do a lot of good for spreading around "proper" AOD. Thank you for allowing the talk to be published. I'm a bit oblivious to the job-security aspect of "Never tell everything you know." I'd rather work myself out of a job by doing it well or by teaching someone else to do it.

Point of clarification: an event that is registered with an ES that DOES NOT have a case in the ES (unhandled), will not reset the timeout. In 2012, events that were registered but unhandled would reset the timeout.

If Wikipedia is to be believed: http://en.wikipedia.org/wiki/Flow-based_programming FBP was invented by J. Paul Morrison in the early 1970s, and an early implementation of this technology has been in continuous production use at a major Canadian bank since that time. http://en.wikipedia.org/wiki/LabVIEW LabVIEW project begins April 1983

This is a Site Feedback and Support forum question. http://lavag.org/forum/5-site-feedback-support/ Michael has mentioned in some posts that there's a dead-man switch that he needs to kick every day to keep lavag up Actually, he said if lava's down, ping him somehow and he can bring it back - can't find the post where he mentioned it, though.

http://lmgtfy.com/?q=labview+run+as+service

That's error 1. LV: argument error. I tried to recreate the error, but couldn't get to gmail from this part of the network.

Aha! jlo got (at least) one in. Is it above or below the attribution? http://zone.ni.com/reference/en-XX/help/371361K-01/lvupgrade/labview_features/ Application Builder Enhancements Automatically Selecting NI Software for Installers When you build an installer in LabVIEW 2013, LabVIEW automatically selects installers for the drivers and other software components required by the built application. Use this feature to reduce the possibility of building an installer without the right components. To disable this feature, remove the checkmark from the Automatically select recommended installers checkbox on the Additional Installers page of the Installer Properties dialog box for the installer. [idea submitted by NI Discussion Forums member jlokanis] Creating Directory Versions in Build SpecificationsIn LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box.

No math, but here is a fun (brief) discussion of gyroscopic precession: Some math: http://en.wikipedia.org/wiki/Precession

Running the profiler slows down the code.

Is it one of the devices that has a SAR ADC, so more than one sample is needed?

As long as the code that's deleted is BAD code.