jzoller

I agree with the comments on the sequential state machine: its use is primarily as a teaching tool. The rest: nonsense. A procedural state machine (PSM) doesn't break dataflow (certainly not the way locals, globals, refs and property nodes do). A PSM does allow much more flexibility over how the dataflow occurs, and that admittedly does increase complexity. However, saying there are too many states is like saying something is "too pink": purely stylistic. After all, changing the structure of well written code doesn't result in any less code, or necessarily any more readability. Particularly where decision making is involved. Better criteria for state machines: Are the states well factored? Single responsibility? Grouped by purpose? Well named and well commented? Is the code properly contained in sub-vi's for re-use? Are the states given some forethought, or just thrown out as they occurred to the developer? Can you shoot yourself in the foot by calling them in the wrong order? The only time I've had difficulty with errors in PSM's is when they're interacting asynchronously with each other. I'm still not particularly convinced that deep hierarchies have anything to offer besides complexity and brittleness. Do you happen to know any good references on the subject (seriously )? Coding in C... nah, too harsh. Coding in Python is closer. Joe Z.

I've got a utility that's written in LV2009. Some of my users only have the 8.6 (or 8.6.1, or 8.5, or 8.2...) runtime engine. They aren't likely to upgrade anytime soon. Every time I release a new version, I need to back-port the code to prior LV versions and rebuild by hand, retargetting for different build locations each time: Error prone and time consuming. Has anyone ever seen a solution that might automate this mess? Or at least help? Thanks, Joe Z.

No.

It obviously refers to vi.

I once worked at a place where IT insisted that the testers couldn't be on a separate sub-network: they had to be on the main network. This worked ok until they found a set of computers on the network that didn't have antivirus, and didn't have the latest updates. Of course, they immediately pushed it out to all of them, and went home happy in the knowledge that their network was secure. It took a couple hours to figure out why the Windows-based, $80k+ scopes all stopped working on the same day... Joe Z.

Agreed. Because of how databases work, it destroys your query efficiency. --- I got a bit rushed on my earlier answer, so... here's my personal database rules of thumb. Maybe they'll be helpful: Write data twice. Once as simple raw text to the local hard drive, and once to the database. Each test has a timestamp or ID that uniquely identifies it. Split text files by day or week so they don't get too large. Every so often, the database compares its records to those on my tester(s), and match up any that were missing. The database schema should not exceed two tables on the first pass design. Make it complicated sometime later. For specific tools, I would probably use MySQL (with plans for an Apache web server) for a low cost version, and SQLServer (with plans for an IIS web server) if I could afford it. Joe Z.

Problems to solve in advance: What are you going to do when the database is down? What are you going to do if the test station doesn't have a network connection? How are you going to back up (and restore, if necessary) the database? Don't get too caught up in the SQL side before you work these out. I know from personal experience that it's painful. Joe Z.

Not sure how Microsoft got into this... they probably employ more testers than any other company on earth. For a high level description of their process, check out this pdf from MS research. It has some nice numbers on the impact of TDD, as well. Joe Z.

It's worse than that: they do it to "make it better", or "more generic", or "more elegant". The best of reasons, but soon you end up with an overdue Observer-Decorator-Factory-Factory architecture and 6 levels of abstraction, when a polling loop would have worked just fine. LV developers tend to be somewhat more prone to duct tape than, say, Java developers. I suspect it's because so many LV users are engineers and scientists of other disciplines, where code is not the goal. Joe Z. Netscape's failure is fascinating, and pretty well documented. Among other things, they decided to re-write their browser from scratch, "the right way". It ended up more than a year late, during which time Microsoft took the entire market. Maybe they needed more duct tape Joe Z.

I admit it: I like Joel On Software. Besides, this article describes a goodly number of the best programmers I've met. Joe Z.

http://forums.ni.com...hread.id=443021 Normally, I try not to cross post, but I think this requires a more official NI response that is usually seen here. Any contributions would be most appreciated, though! Joe Z.

And of course, you won't ever sell enough while the price is closer to $4.3k US. And no, I don't know how to cross that gap... or if it should be crossed. I wish NI had an ISV program (https://partner.microsoft.com/40066412, for instance), but, as far as I can tell, they've chosen to forego that market. <shrugs> I develop in C# on my own time now. I'm sure NI will never miss me. Joe Z.

I've built a couple XML function sets. It's a good-and-bad technology. Positives: ->Everything mentioned above. ->I love XPath support. Negatives (which may not affect you at all): ->Everything mentioned above. ->File size bloat: there's a lot of overhead in most XML tags. ->Memory: Most (all?) libraries with LV use the DOM system, which means the entire file needs to be put in memory. This can be prohibitive if you're storing a lot of data. ->Brittle structure: simple changes to the XML schema can really mess with your code. Using a predefined standard like ATML may avoid this. ->Validaton: If you decide that you need validation, it can require a painful amount of work to get things just right. ->External libraries: most XML writing and parsing is going to require dragging along some non-LV library (ActiveX, LibXML, .NET, etc). ->Possible memory leaks: many XML libraries require a lot of references to be opened, and it's not always straightforward when they should be closed. ->Searching is relatively slow: Again, in order to search, you need to read in the file, then traverse it. This is much slower than doing something like a fixed offset column search. Joe Z.

Open Query XML Document for Multiple Nodes.vi (from the example finder), and delete the error line immediately after the for loop. Save what you're working on... and run the XML VI. LV apparently fishes around for a moment, then goes away. Joe Z. x-post to http://forums.ni.com/ni/board/message?board.id=170&message.id=437600

OOP. Depending on how you prefer to learn, you may want to grab a good book and stick to "low fidelity prototypes" (pencil & paper) rather than learning the oddities and corners of LVOOP. Joe Z.

Since this actually works if you run the selection backwards, I was hoping it would be a nice low hanging fruit (as my project managers like to say) for NI to easily fix. I wish I could dispute this, but there's still the mentality that "new features sell new customers". I don't really think that's so true anymore, given LV's level of maturity. On the other hand, I've yet to see marketing put "with over 200 bugs fixed!" in a major product announcement. Hopefully, the Idea Exchange doesn't get too cluttered with bugs. Maybe the idea to post is for a LabVIEW Customer Bug Ranking system... what's causing the most pain for end users? Thanks all, Joe Z.

MCL = MultiColumn Listbox Broken since... erm, 7.1ish? To see the bug, select the first element in the MCL, scroll to the bottom, and shift click the last element. It pegs a processor core, too. To see the correct behavior, restart the VI, scroll to the bottom of the MCL, select the last element, scroll to the top, and shift click the first element. I'd hate for it to fall off the bug list. Joe Z. x-post to http://forums.ni.com/ni/board/message?board.id=170&thread.id=436150 MCL_Bug.vi

Any possibility that you could use a web service instead of a direct .NET call? This would essentially wrap your .NET call into a local process, which can hand off safer payloads of XML (or JSON or whatever) across the network. It can be quite a bit simpler as well... though, if you have a restrictive IT department, it can run into human problems due to the need for a web server Joe Z.

LV 8.6, dynamically calling a VI with an XControl from an exe with the debugger attached. The build failed to bundle some things into the exe... nothing new, but the error messages are nice c:\builds\penguin\labview\branches\Saturn\dev\source\linker\xlinker.cpp(739) : DWarn: GetAbilityVI should never have to actually load the VI; Nick Neumann was wrong. Go yell at him now! c:\builds\penguin\labview\branches\Saturn\dev\source\panel\xctlVICalls.cpp(353) : DWarnInternal: Expected async ref, something's gone awry! x-posted to: http://forums.ni.com/ni/board/message?board.id=170&thread.id=435384

That's close. The system I'm thinking about has embedded rules to deal with how front panel items are rearranged when the screen is resized. That's the impression that I've gotten so far: it's a difficult problem. I suspect that the diagram cleanup code was worse, though

Does anyone know if a flow layout method for front panels has been attempted? For instance, Silverlight's: http://msdn.microsoft.com/en-us/library/cc645025(VS.95).aspx. (I need to stop learning new tools. I keep finding features that I want!) Thanks, Joe Z.

Maybe crelf was just madly posting to LAVA...

For ascii: http://zone.ni.com/reference/en-XX/help/371361F-01/glang/string_to_byte_array/ If you need integers rather than U8's, you'll need to convert to them. Using http://zone.ni.com/reference/en-XX/help/371361F-01/glang/to_long_integer/, for instance. Joe Z.

I'd be glad to guinea. Joe Z.

Getting ready for the exam myself. I thought Darren's blog had a nice, practical approach: http://labviewartisan.blogspot.com/2009/02/labview-certification-preparing-for-cla.html Joe Z.