Darin

Funny, I had the reverse situation yesterday and I started wondering which is worse: instead of an unbroken-broken VI I had a broken-unbroken VI. Simple parsing VI with a set of sibling classes which parse different object types. All of the sibling VIs are basically the same except for a different cluster in unflatten from string, in fact, they were all made by copying the first child class. I end up with a broken VI which claims that (only) one of the sibling VIs is broken. Clicking the broken Run Error in the VI gives the ever-helpful empty error message. Ctrl-Run, Close-Open, Change Private Data and Apply, still broken. Diagram Disable the entire diagram, still broken. Save a copy of the class, add the new sibling to the parsing VI unchanged and it works.... Finally LV12 did its thing, by which I mean crash, and when I restarted the broken VI was now fine.... My problem is that I am stubborn, nine times out of ten problems like this are LV's fault and yet nine times out of ten I still assume it must be my fault. No definite opinion on whether I prefer broken-unbroken or unbroken-broken VIs other than they both suck.

Personally I would set the cursor to busy when a time consuming task is running.

You need A laptop. You seem to have at least one so when it comes to bang for the buck I lean to desktops myself. With a laptop you are always buying a monitor and a keyboard, with a desktop you are just buying the business end. I tend to go a step further, I scour places like EBay for used components on the cheap. If you know what to look for you can get great deals, usually by finding the lowest-end machine with an upgradable motherboard and over time plugging in better CPU, RAM, Hard drives, etc. It seems that more people have stopped undervaluing the old parts these days, so this is getting a bit harder. You may have fallen into a common marketing trap for laptops. The processor in you laptop could very well be underclocked to save power, the front side bus is perhaps a step slower then the desktop, and the hard drive probably has a smaller cache. You should benchmark the two (at least with Windows Experience) and see where the differences lie. In short, an i7 in your laptop is likely (a little) better than an i5 in your laptop, but not as good as an i7 (or perhaps i3 or i5) in your desktop. Think of the CPU like the engine of your car, and the body (laptop or desktop) is like the tires. At some point extra horsepower only spins your wheels it does not get you anywhere faster. And I would not place the desktop on the dining room table, I would probably shove it into a corner and run it headless using your favorite VNC software.

Try adding the object after you show the BD.

I typically save it in the temp directory and delete it. Not the most elegant, but scripting rarely is.

I also have described similar situations (I think on the NI forums). The main takeaway was that the function is in fact named Request Deallocation, so I guess "Request denied!" is a valid response. Actually I looked at it in some detail at the time and I seem to recall it worked like this: string arrays are stored as an array of handles to the individual strings. RD dutifully returns the memory used by the handle array immediately but the memory used by the individual strings is not freed. I could troll AQ and discuss the LV garbage collector, but there is not one so that memory is not going to be freed in the normal sense. I seem to recall that the memory is reusable by LV so it is not completely lost, but LV can be the RAM roach motel, bytes check in but they don't check out. The quick and dirty solution I have used the few times this has been an issue is to put the offending code into an executable which I can then run dynamically in its own context. Either as a one-shot process or as a daemon. Reclaiming memory was as simple as shutting down the process and restarting.

The true LV ninja would look at the code and determine the specific cause of the bug. It typically involves duplicating events, improper FP locking, or the #$%@#$% bug that unhandled dynamic events still reset the timeout. If only there were a tool that analyzed my VIs for these kinds of bugs...

I find the whole 'put it in a subVI' argument to be less than compelling here. There is only a tiny distinction between code on a BD and code swept under the rug and into a subVI, and with inlining there is even less of a distinction. But let's pretend I agreed with the notion that one event structure is better anyway. Do I really want a feature in LV built on the foundation which requires this artificial limitation? Especially one of the core features? On the bright side if they do this then AQ is the proven master of the "we restricted the syntax to do you a favor" spin and can write the white paper.

I'll try to dig something up showing throughput sloshing data back and forth between python, java and LV. It was very enticing, especially since my natural curiosity takes me into the depths of various protocols and file formats. Of my many spelunking expeditions AMQP was one of the best.

Been there, done that. I have G implementations of ZMTP (at least most bits I need) and AMQP (0.9.1 not the 1.0 trainwreck). I tend to use AMQP most often since my code is more complete (and there was more adoption of it when I wrote it), but they are both great. The brokerless nature of ZMQ can be great when you need it, turns out most times I was implementing a de facto broker and could have stuck to AMQP. Unfortunately the specs are really laid out seductively in terms of classes and methods so I gummed up the works by using a bit too much LVOOP (not to mention busted my carpal tunnels). Performance is ok, but as I de-LVOOP it is finding another gear. I create worker pools consisting of simple LV workers and similar C++, Java, or Python workers and see what share each worker does. LV is behind, but getting up there with the big boys. The LV9 to LV12 performance kick was also welcome here. The AMQP implementation gave rise to one of my new mantras: No LVOOP in a loop.

A single catch-all Event structure is a recipe for increasing the coupling and decreasing the cohesion of your code, we must have different metrics for maintainability and readability. That is a double-whammy in my world. I have my own icon editor which has been a systematic refactoring of the shipping version. Step 1 was converting the single ES to a group corresponding to the different tabs. Now tabs can come and go as I please. You may prefer to get slapped in the face when you click on the Event selector label, I say no thanks. And the timeout is so much more useful with a restricted set of events. I can have multiple time scales very easily.

There are many situations where I like to have unrelated events handled by separate event structures. Sometimes it is user events and app generated events. Often it starts out with mulitple event loops and eventually it morphs into multiple subVIs. Part of the reason I like to keep them compartmentalized is that Event Structures are like bear traps for code since until LV13 they resisted most efforts of scripting-based automation. At least having smaller structures made it easier to reuse code. Another reason they get multiplexed is that maintaining state for one event case meant stringing a wire across every other case, or doing some bundle/unbundle or LVOOP craziness. It is much nicer to have a class/typedef cluster for state data which is logically related to the events in an event loop as opposed to a hodgepodge based on the combination of events contained in a given loop. This idea would improve things a lot if we got stuck with one event structure: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/An-output-terminal-for-feedback-nodes-that-mirrors-the/idi-p/927458 Now local state can be kept local and I will have fewer wires in a monolithic event structure. Bottom Line: I see no fundamental reason to limit things to one ES per BD. It smells like one of those easy-way-outs that may solve one problem but may add more than that it return. I'd need some convincing that the problems of code mutation to avoid breaking code, or that the problems of breaking old code are worse than the current difficulties.

Oscillate it (P). Critically damp it (PD). Trim the offset (PID). I am a stickler for anti-windup as well. I have found that to work great to get things very hot, very cold, very magnetic, and very stable. To me the problem is not that the underlying physical system is crazy, because surprisingly many are approximated very well by relatively simple transfer functions. The problems I encounter usually involve conditioning the feedback signal so I am not chasing the noise while not adding an excessive time delay into the feedback system (that is a real bandwidth killer). If something will blow up and blowing up costs $$$ then you had better model the heck out of it. Otherwise I would study the math on the back of an envelope to estimate a range for each parameter and then tune away. I liken these things to the Wright brother's plane, hard to fly, but much harder to explain how to fly it.

I use my own pipes library, it should be equivalent to the OpenG version, but I will install it and double check that it works. I have no problem using scipy and numpy all the time.

HTML link got garbled. See my post in Darren's nugget on arrays of clusters of arrays. Date was 5-9-2012.

I use pipes myself to pump commands to stdin and read from stdout of the python process. You have to do the string parsing if you want to make sense of the python output in LV, but it is simple to pass commands as if you were typing away at the keyboard. I am mobile right now, but you should be able to dig up the old OpenG pipes library. If you are on a linux box then LV has the pipe library built in.

Introduce OOP to a LV programmer and you get much happiness. Introduce LV to an OOP programmer and you get much frustration.

My original file is 10.1 kBytes and the downloaded one is 4.16 so it appears something is stripped out. to recreate: 1) drop a CLFN, choose 'LabVIEW' as the library name and click run in any thread. 2) make the output parameter a 32-bit signed integer 3) add a string input parameter with default settings. 4) wire and enjoy. I kind of like it sometimes when debugging myself. I am always closing a BD window and killing probes.

Not CIN specific. just select LabVIEW in the CLFN, mgErr is typedef'ed as an I32 in extcode.h

Uno's are great, cheap, and plentiful. If I were choosing a model to introduce students to, that would be it. I use the Due more myself, mostly because it coexists in my 3.3V ecosystem. It is so easy to plug 5V into a 3.3V input and most of these cheap boards are very intolerant of it. For students it is good to be on the safe side. Added bonus is that the microcontroller is socketed on my Uno's which makes them easy to replace. And the Uno's USB performance is quite good these days, and the issues before are mostly using firmata in firehose mode (spray data until a buffer overflows), the digital i/o toggle mode is quite robust in my experience. Usually I can set a pin and then query the pin to verify the setting. And in this case you are right, I envision the firmata sketch(ships with the arduino ide) installed on the arduino and the other code (LV, python, java) on the host computer. The A students could program the microcontroller directly for extra credit.

Well, thanks to the LabJack ads which are now following me around the internet, I see that it is $108. That's a lot of arduinos, and more than I paid for my USB-6009 on EBay. And if python were an option, pyFirmata is available, and while it is still missing a few of the latest firmata changes, driving a digital port is its bread-and-butter.

There must certainly be a firmata library for java by now (a fine exercise if not), and that would allow an Arudino to easily become your USB digital i/o module. With Arduinos running me about $6 on Ebay (not that I need more bidders...), that seems to fit the low-cost bill.

I am dead serious. It gets you out of the tetris mentality, it makes you give every node a little personal space which makes wire routing easier, it fits in nicely with objects and type defs. I actually turn icon view off sometimes myself. I'd like to be able to use more of the icon space in the header, and I wish I could mark pairs of terminals (say error in and error out) as one passthrough terminal so I do not have to have separate lines for them. Usually I leave the chained connections in the top anyway. I'd also like to be able to color code the yellow background area. I do not know where Express VIs enter, other than they turn off icon view. I will guess that you use the term derisively, but that says more about the use of the technology rather than the Express VI technology itself. I like the configuration aspects, but do not like the subsequent hiding of the configuration details. They are quite close cousins to XNodes, to me bashing one is akin to bashing the other. But that is way off-topic.

Allow me to toss a hand grenade. As a baby step toward that end I suggest (I am being serious) that you turn on icon view for terminals and use it. Keep an open mind and try to make it look good. Wire bends? Yes there will be more on average, but they are longer which is easier to follow and much less annoying IMO than those 1 and 2 px jumps. They take up more space? Yes! This has two benefits. It drives down the density of your BD, and triggers that urge to create a subVI earlier. Helps curb mission creep inside a VI. Second benefit: lower density leaves more "slack" on the BD for when you really need to add something. Tight-packing means that adding a single node can literally affect every other node on the diagram. Perhaps that tall stack of terminals can become a type-def cluster. Bonus: NI insists on resetting this setting with each release of LV, just sit back and enjoy it instead of cursing every time. Now, once you have accepted the joys of less dense, more focused subVIs, it is easy to move from icon view to control view. The more focused subVIs are easier to test, maintain, and are much likely to be reusable. Every node you add tends to increase the specialization.

First of all, this thread pretty much makes me want to vomit all over my keyboard so I take it in small doses. Front Panels make a little more sense to worry about since it is higher on the substance-style scale. Once again let me post my pipe dream, how is this for debugging your BD? We don't need no stinking Front Panels.