crelf

QUOTE (Mark Yedinak @ Apr 7 2009, 02:46 PM) I don't know when (or if) it changed, but my understanding has always been that efficiency is best starting with the node, then local variable, then the property node. I agree with shoneill - use locals if all you're doing is reading/writing from/to the FP item, but if you're doing anything else through a property node then you should use that instead (also nice to use with the error clusters as well, but make sure you set the "ignore errors" setting appropriately.

QUOTE (loserboy @ Apr 7 2009, 08:48 AM) No worries - anytime. It should be pretty straightforward to expand it to include traversing tab control containers.

QUOTE (rolfk @ Apr 7 2009, 02:17 AM) I did similar, but with a C128 - an extra 64 bytes of pure power!

QUOTE (shoneill @ Apr 6 2009, 05:44 PM) You'd need to know which sequence structure you wanted to convert into a state machine - probably by label - and it should be okay from there (it wouldn't necessarily be easy, but it'd be straightforward - just copy the code from each sequence structure pane in oreder into a case, wire up shift registers where tunnels are wired between panes and voila! It'd be pretty neat to be able to get into the hooks to be able to add "Convert to State Machine" when the user right-clicks on the sequence structure border

QUOTE (shoneill @ Apr 6 2009, 02:37 PM) Absolutely - it wouldn't be too difficult to implement.

QUOTE (raymyster @ Apr 4 2009, 03:50 AM) Maybe we're getting hung up on the term "beam" taking us down the laser route. How about a couple of http://en.wikipedia.org/wiki/Photoresistor' rel='nofollow' target="_blank">ligth-dependant resistors?

QUOTE (pdc @ Apr 6 2009, 11:12 AM) Sounds like a bug to me - let NI know.

QUOTE (335x @ Apr 5 2009, 11:47 PM) Sorry, but you're out of luck

QUOTE (flarn2006 @ Apr 5 2009, 10:11 PM) Pin the palette, click "View", select "Change Visible Categories" and make sure they're all selected (this bit me a few weeks ago on a new install when I had gobs of stuff missing).

QUOTE (bsvingen @ Apr 6 2009, 04:56 AM) Herein lies the root issue: you are confusing undocumented and experimental. They are not necessarily the same.

QUOTE (Kutulu @ Apr 5 2009, 02:33 PM) Yes.

QUOTE (Yair @ Apr 5 2009, 02:17 PM) I totally agree.

QUOTE (Yair @ Apr 5 2009, 01:58 PM) OK - is this a real application, or an academic exercise? I'd assumed the latter

QUOTE (Jim Kring @ Apr 5 2009, 01:58 PM) Yep - you might as well call me thepiratebay

QUOTE (Jim Kring @ Apr 5 2009, 01:22 PM) That's exactly what I was thinking about while I was typing that Specifically, the linking to infringing content.

i. Use TestStand.

QUOTE (Yair @ Apr 5 2009, 01:00 PM) h. Use a flat sequence structure that is arranged so that the BD only needs to be scrolled in one direction (left/right) which clearly shows the order of the code (remember, fixed order) and allows reasonably easy debugging for specific points in the code? Anyone got more options? We could set up a survey question on this thread...

QUOTE (bsvingen @ Apr 5 2009, 12:30 PM) I don't think that's anything to do with the ethics of the company that developed the engine. To make it boost it's output by 50% (just like if you use any of the undocumented features in LabVIEW) you would have to go hunting for them. Essentially, you're using the product outside of what you were told will work, so you're assuming the risk of using an undocumented feature. One of my mantras is "Just because you can, doesn't mean you should", and if you're working with undocumented features of *anything* then the risk is yours, and yours alone. Another example - you buy a hammer and then crush someone's skull in with it. Can you say the hammer manufacturer is to blame because you used the hammer for a purpose for which it wasn't designed? I sure hope not, although some days it seems that is the direction the world is going

Try this out - it's from one of our old internal reuse libraries. The dat file is "=" delimited text-based. It's not something we've done much work on in a long time and I know it's not feature complete, but it might help you find the direction you're looking for. It just searches through FP nodes for English labels and then replaces their respective captions with the corresponding selected language's equivalent. As with all the code I upload here: all care, no responssibility, so use it at your own risk.

Let's separate the context of this discussion into two groups of software so I can comment intelligibly: Product This is when you iteratively develop a product over several versions that you then sell (either internally or external). Usually, you sell it to several different customers (although this is not always the case). You develop the requirements based on your own market research. You're not aiming to meet a set of specific requirements from your customers, but more an experience that they want to have. Examples of this include LabVIEW itself. I think that it's perfectly fine for anything to be added and undocumented to products - they're your internal brain-child, and as long as you can sell it to those who sell it to the end customers, then go for it. As you're iterating the product, then you might want to add some sub-features that a future feature will rely on, and not expose those sub-features to the user just yet - perfectly fine (as long as those sub-features don't screw with the expected behaviour of the current version - but that's a topic for another thread). System This is software that you're developing usually to an external customer's specifications. In essence, they tell you what it needs to do, you design and develop it to do so. Examples of this: the one-off test systems that system integrators make, to test a customer-specific UUT in a defined way. The software engineer has latitude in how it is developed, but not what it does - of course, during the requirements gathering stage of the project, any test engineers worth his salt will explore the UUT-specific test world with the customer to help them get the best information (not data) from the system and suggest innovative and appropriate methodologies for getting that information. Systems are a very different kettle of fish from products - you're generally developing on the clock directly for an external customer. If you've got your process right, you'll have well defined and properly written requirements that you shouldn't stray from - the customer is expecting a system that does what they asked for - nothing more, nothing less (if you deliver them less then that's an obvious issue, but if you deliver them more you can get into a lot of hot water too - but that's an issue for another thread). Of course, there are situations where you have hybrids of the product/system models, but that's a topic for another thread. Wow - that's a lot of "another thread" topics QUOTE (bsvingen @ Apr 5 2009, 07:01 AM) Right - and I think, in this case, that is the responsibility of the end-user. If you know that you're using undocumented features (and, truth be told, we usually do because we've gone digging for them), then you're introducing a risk. It's not NI's fault that you chose to use them - it's yours. That said, I use undocumented features in my architectural designs all the time - I know that they're risky, but I also use them for their feature pay-off. It's my risk, and I'm willing to take it. QUOTE (bsvingen @ Apr 5 2009, 07:01 AM) The only ethical correct thing to do is to document everything, also unrevealed and untested features. All undocumented features should be removed. *shaking head* No, no, no. Well, yes if you're talking about a system, and no if you're talking about a product This argument has little to do with ethics. LabVIEW will do what it's documented to do. If you don't want to take the risk of using undocumented features, then don't use them - stay within the bounds of the documented ones. It's your choice. Having NI remove all the undocumented ones is ludicrous. I assume that the amount of work that would be required to fully document them all is ridiculous, and if they tried to remove them all then the documented ones would be crippled (there are plenty of documented features that rely on undocumented features). Irrespective of your position on whether you think it's an ethical argument or not (which, as an aside, I don't) then the practical end point you're pushing for is an end to LabVIEW. So, if you want to continue the discussion intelligably, then I suggest you make it a theoretical discussion about software in general, or discuss a specific system of your own (but then you get into the product vs system dichotomy I mentioned above).

Thanks for the link Norm:

QUOTE (jcarmody @ Apr 4 2009, 07:38 AM) Sounds like you could use a http://forums.lavag.org/-t13407.html&view=findpost&p=59675' target="_blank">sequence container.

QUOTE (hooovahh @ Apr 3 2009, 03:50 PM) I'm wondering if some data remains on the PC that remembers the USB device number. Does the COM port number change if I plug it into a different USB port?

I can imagine that, if shift registers were added to sequence structures, it'd be confusing when working with unintialized shift registers.