crelf

Interesting...

Welcome Blake - great to have you here! I've added you to the NI group - should show up as such soon.

That might be the case if you wire out two or more of the decimated arrays, but not in the BD above where only one of them is wired out.

An array is an array - don't they all have dimSize at the front?

That's a great way to get into OO - start using it as a super-cluster (with encapsulation, instantiation, etc) and then, once you're comfortable with that, move into inheritance. I've heard some ppl say that OO is nothing without inheritance, but that is so not true. That said, inheritance does make OO totally rock! From what you've explained, I'd say yes. The admin client class is just like the client class, but has some different functions, so you want to override the parent class (client) with the child class (admin client) methods (VIs). Of course, you only need to write the admin client class methods that need to override the client class methods - LVOOP will use the child methods as first priority, but if they don't exist, they will traverse up the class tree to the next parent class and use that method instead. If the method doesn't exist in that class, it'll go up another level, and keep on going until it finds one that does exist, and use that. It's quite elegant, and delicious to see it all work

Unless you're some uber-architect-God, you'll design something that works for what you need right now, and maybe even add in a method of passing stuff around that you don't even know about yet. Then, after it's in use for a while, someone (including you) will want to make it do something that it's not quirte designed to do, and you'll have a question: redesign (and all the work required to retrofit the work that's already been done) or adjust (hack) the elements already in the design to perform outside of their original function (you can usually do this pretty quickly, and due to production pressures or otherwise, you decide this is the best route (you justify it to yourself by saying "I'm thinking outside the box" rather than thinking you should redesign the box). You might got through a few iterations of this until you end up with an architecture that is so crippled with edge cases that you finally decide it's time to re-design (hey, you've learned a lot of lessons, right?), and then you start the cycle again. Or do you? The production PCs need the new features, you don't have any downtime ro redesign, so you cut corners. You end up with an architecture that's better than the previous one, but it still doesn't quite have the expandability that you'll need in a month, a year, etc. You've invested an amazing amount of time (and a crazy amount of money) into developing a software system that you could have just bought off the shelf (which is cheaper, has much higher quality, and more features than you'll need in the next couple of years, is maintained by someone else, has a support base of thousands of people around the globe, I could go on...) In short - spend you time wisely: work on the parts that are important to your product and your business - let someone else take care of all the other stuff. I don't know you or your business, but I'm assuming that your product isn't a test sequencing software platform, right? For example: you use LabVIEW - why don't you write your own version of LabVIEW in assembly? Because it just doesn't make sense to do that. So why are you writing your own, less functional, version of TestStand that you're going to need to continually support? (Unless it's job security ) By the way: TestStand really isn't *that* difficult to learn. It's like LabVIEW - you can get in on the ground floor, create some sequences, get stuff running. Then, as your knowledge matures, you can expand your software domain. Take a course, get a consultant in for a couple of days to walk you through it (you might even be able to get NI to give you someone for some time), get the course books and work through those if you don't have a lot of money (or find it difficult to convince upper management that it's valuable). The people that complain that moving to TestStand is too hard because their boss won't pay for it aren't explaining the true value of COTs Vs custom to their bosses right (or, perhaps, their bosses have their heads fair up their own arses). All this comes down to COTS vs custom, and it's something we've debated here so many times. Use what's appropriate, and, in my experince, custom sequencing engines are rarely the right way to go. I'm not saying that TestStand is always the answer, but I'd bet a beer that it's the right medium- to long-term answer for you. LOL

It's a wonderful wonderful place to be As an aside, anyone hear about the new "Alice in Wonderland" movie coming out? Depp and Burton - here we go again...

Here's a VIE-itnernal VI that we use (amongst others) when we're adding files to our packages (we dynamically build chm help files and link them from the VIs that we build in the package). You need to call it during the post-build phase, otherwise it will corrupt your package. As always, the code I post is at-your-risk only. Note: I don't have any inside knowledge of the vip file format - it might change at any time, and using this VI might screw up your packages. This code is not supported by JKI, or anyone else (including me ) VIPM.AddSupportFilesToPackage.vi

Right - the contigious part doesn't have anything to do with whether it can be inplace or not - it's about the space (and the datatype of that space(s)), not the values.

OK - now I'm really confused - why would there be a allocation dot on the output of the decimate? The output is still a 1D array of SGLs - it's just got fewer elements.

No worries - I don't need to know anything about LabVIEW's internal memory to be cute I can understand why the inplace structure doesn't have it yet, but I'd expect the normal manual conversion to have it

Ohhhh - I get what you mean. Um, in that case, they are indeed both 32 bit, but they're not the same datatype. I agree that it would be nice to see some implaceness here, but it's certainly not something I would have expected. More importantly, why would you want to do that? Can't you just use the I32 convesion outside of the structure and get implaceness, or are you trying to demonstrate the root issue that would normally be applied to something bigger?

Both types aren't 32-bit, at least not yet...

Right - sounds like what you want is just a group of Booleans?

I think so too - they give us RSS people context to the threads

Do you have Outlook SP1? Looks like the previous version had this issue: from here: This seems to mostly be an issue when you're using both exchange server and RSS feeds.

I'd convert them to a timestamp datatype and then work on them.

That's pretty! I'd still like to see the slight yellow glow in the background...

That's sad, but certainly not uncommon. Take it from someone who has been where you are, several times before - learn about TestStand and bring it into your life. Sure, you can do a lot of stuff from scratch with LabVIEW, but history suggests it will probably all fall apart sometime. Maybe not today, maybe not tomorrow, but soon. Use LabVIEW for the encapsulated tasks that you can't do with TestStand/IVI/VISA/DLLs/SQL/, and TestStand for everything else. I know it's the same message that you've heard many times before, but maybe that's because it's right. As for your suppliers, maybe they aren't using it correctly or to it's full feature set. There are poor TestStand architects, just like there are poor LabVIEW architects. I'm not trying to say that TestStand is the be-all and end-all of test software, but if all you have is LabVIEW, everything looks like a VI

Not at all In fact, I think this is a really important discussion, and the varied answer are, well, all right. As I said, it really depends on what you're trying to achieve.

None of those options are really better than any other - depending on what you're trying to do. The first option is the best for performance (memory and speed), but the FP nodes will only be read from/written to once. The middle one has slightly worse performance, but if it's important for the user to interact with the FP between loops, then it's a good solution. The third one is fine too, although it will wait to get the data from the FP until it enters the "run" case - giving your user a chance to change the FP control before it goes in there - it also updates the indicator as soon as the subVI has run. In summary, the answer is "it depends" (I have a sense of de ja vu). If this is a headless subVI then you want to go for option 1. If you need operator interaction (them twiddling the control) then you need to look at either 2 or 3. Note: I'm assuming that there are no locals or property nodes that access the value property of the FP nodes in other cases. On a second look: the diagrams you show don't really look like state machine architectures - they're more like functional globals. In that case, I'd suggest you have the FP control in the state that uses it, and the FP indicator in that state that uses that. There doesn't look to be any reason to have them anywhere else, because no other states (?) use them - they all rely on the data in the USR. Maybe I'mnot interpreting the diagrams correctly... It is, indeed, better for readability of the diagram, but it can lead to unexpected behaviour. Especially if you think about outputs: if you have an output outside of loops/structures/etc then the value passed to it may be different to that if you had it inside the only structure that really needed to access it. For example, if you create a subVI with the usually-appropriate error case around it, there's no reason (other than asthetics) to have all of your inputs outside of the case - they should be inside the "No Error" case (except for the error clusters of course ). If you have other control outside, you're tempted to have all your indicators outside to, and then you have to handle what values go to them, even when the case that usually handles their value is never executed. That said, sometimes it makes sense to do that: like when you need control of values. In summary, the answer is "it depends" (I have a sense of de ja vu).

You guys are just jealous

A big thanks to Lisa K. Wells from Product Principles for offering up a LAVA/OpenG NI-Week 2009 BBQ door prize: Free Marketing Advice for your Technology / Engineering Company Like to be told what to do, and/or drink Texas margs? Then you'd love to win this! One hour of marketing advice and counsel from a marketing and product management consultant who specializes in technology companies. If you don't need marketing guidance, there's always a quick copy-edit or a variety of other services. If you don't need anything of the kind, the consultant will buy you your choice of something from the LAVA Store. The session will be provided by Lisa K. Wells: previously a 5 year veteran of National Instruments, author of the first edition of "LabVIEW for Everyone" and original "LabVIEW Student Edition User's Guide", and founder of Product Principles. Redeemable at NI-Week 2009 or by phone the following week (if you choose the in-person session at NI-Week 2009, it can be combined with Lisa's favorite beverage: tequila!)

Ha