asbo

I wouldn't want NI to spend development time on something like this. This is something that could easily be tacked onto the CCT, for example.

This is good practice and I agree with it, but it might be overkill, depending on what OP is doing. I would be satisfied with making the improvement ShaunR suggested wrt checking the error output and letting the loop terminate after one iteration based on that. Amen! Anytime I concatenate more than 3 strings, it's time to pull out the Format into String node. It usually helps eliminate upstream code as well, as it would in this case.

You need to upload images before you can link to them.

Conceptually, I don't think the Sweep Collection belongs in the Measure hierarchy. The Sweep Collection itself does not need any of the functionality provided by parent or child; it accepts an array of Sweep objects that it can operate on. Only /those/ objects care about the Run/Measure functionality and need to be in that hierarchy. In this same vein of thinking, I would likely have also pulled the Sweep logic out of the Measure hierarchy. I might even go as far as requiring every Sweep to be handled through a Sweep Collection, not to be dealt with directly.

Yikes. Lots of overachievers in 2011.

Another tangential resource, does have some related info IIRC: NI LabVIEW Compiler: Under the Hood Because the default for every VI is "Same as Caller", the top-level VI will have this same configuration (unless you change it). I believe (though can't substantiate it right now) that parallel activities will be scheduled amongst the available execution systems if no preference has been set. I'll see if I can figure out where I got that from. It would be great if someone from NI could specifically address that point.

By "no longer valid," you mean all the nodes disassociate with the library? I've seen some re-linking issues when bouncing between versions of Excel. Do you possibly have different versions of the ActiveX control installed that could be swapping around?

I think this is possible through scripting? I feel like someone was trying this on the forum not too long ago. However, the type itself needs to be a constant on the BD at run-time, so if the scripting solution doesn't work, you're hosed. Can you describe the problem you're having better? Go for the cause, not the symptoms.

Were you using the Vision Development Module or the Vision Acquisition Software? The VAS supports both Windows and real-time targets: http://sine.ni.com/n...g/en/nid/207702. I didn't see anything right away for the VDM, but I've only used it on Windows. I'd be surprised if you found support for any of the platforms you mentioned.

Because an in-memory lookup is faster than a query + potential hit to disk? Obviously, it works just fine for you, but it just seems wrong to be querying a DB to retrieve a setting - there is actual CPU legwork to be done via the DB route whereas with a FG/whatever, it's just memory retrieval (which, yes, I'll admit could potentially be paged to disk as well). I'm absolutely not saying you're wrong, but it is a weird paradigm to me.

You would still use a FG as a cache, right? Rather than query every time you need a setting?

Cool! You better wire that error through, though.

You can't open it because NI allows write-only access to /incoming for anonymous users.

What's your point? It still takes time to execute a memory allocation, regardless of how much you have. It is very normal for a memory-intensive VI to execute magnitudes faster on a second run.

Urgh, excellent point. It might be possible to dance around this with memory mapping or virtual allocations (in Windows, anyway). It would be an interesting problem to try and solve, but I trust that if it hasn't been done yet, it's either not worth doing or can't be done. What you say is true, though; anything short of actually separating the IDE from the debugger/RTE/whatever is just a bandage. It would be really cool if we could do that, but it doesn't surprised me that the two are so deeply intertwined at this point.

It's more likely related to a (lack of) memory allocations.

Right - don't those just allow you to call another function in your library? In almost every use case I've had where I wanted to abort, it's because the DLL is misbehaving/unresponsive (and naturally has no signalling routine). If LV were to fork (or CreateProcess or CreateThread or however you'd actually implement it) and then call the routine, wouldn't that be a pretty effective way to sandbox the call and make it abortable?

In this case, I'd qualify "real" as the most cost effective solution. Unless there are serious infrastructure issues, the development time it would take implement this on the LabVIEW side will be many times more than the 15 - 20 minutes it would take to create FTP credentials and a network share.

Thanks for the insight, AQ. I'm going to write a test case to look into the desktop behavior of this, just out of curiosity, but the point you make about RT use cases makes a lot of sense. Later: In LabVIEW 2011 with DAQmx v9.3.5, you *do* get the task name as part of the error message, in a fairly retrievable way. Further, you can probe task wires to see the task name and you can typecast/coerce task wires to strings to retrieve the task name. Somewhat disappointingly, a property node can no longer retrieve the name. I don't have a RT box available to me, but I still expect AQ's guess to hold true.

If that's true, that's really annoying - the wire of the task has the name of the task in it.

For a while now, there's been a thread for Idea Exchange promotion and every now and then you see someone post their own thread about a specific. In general, I think people around here are pretty vocal but it's more rare that someone comes up with an idea that buckets of people can get behind.

This would be a pretty cool pet project, but if it were what I was employed to do, I wouldn't really be satisfied until it ran.

Maybe you should post this on the Idea Exchange?

You might consider checking out libcurl. They have a C binding, so you should just be able to drop CLNs and go nuts with it. I have had excellent luck in the past using libcurl (via php) to automate HTTP/HTTPS transactions.

Sometimes I dream about a world where LV could abort CLNs.