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.

If you're concerned that someone may choose a VISA resource that does not correspond to a serial port, or to the wrong serial port, then you need to check before you start your loop. You don't show the rest of your code, but a simple state machine could be used for your architecture. You'd have an "Init" state where you mess around with controls (as you appear to be doing below the loop), a "open serial" state where you check the port and verify you're connected to the right port, and a "close" state where you close the serial port, and do any cleanup.

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.

Additional comment: you can replace the big Concatenate String with a Format Into String function.

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.

C:NI%20Certifications%20Exams%20Preparationcld_sample_exams_englishSimple%20Latch%20-%20Unlatch.png

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

If you divide your code across execution systems instead of leaving them all at "Same as Caller" you should see the work distributed across more threads, and probably better performance and higher CPU use.

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.

Nope. Why do you need a cache for prefs? (let the OS do that) Kind of defeats the object.

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.

No. I use a database (SQLite) nowadays for preferences.

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.

Just tried using DataSocket with the NI FTP site and received no LV error; the file name appears on the server, but I can't open it...

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

System info:

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.

If LV ran the call in a separate process, would it be able to share memory? I don't think it can... even if LV allocations could be shared with the process, allocations from that process could not be shared with LV because those allocations would evaporate when the process exited. That would be a pretty hefty penalty for calling libraries if all strings and arrays triggered data copy.

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.

Thats because proberbly some intern machine code results are cached.

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

Actually since about LabVIEW 8.2 they sort of are through the badly named Callback functions.

LabVIEW 7 didn't have that but CINS had a CINAbort function that could do that, if properly implemented.

I didn't count "signal-able" as the same as abortable.

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?

... but the real solution is ...

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.

But beware: if one of your threads closes the task, and then another tries to access it, you can get the old unnamed task error, I think. I'm pretty sure I've done this bellyflop at times.

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

I have also seen some good ideas with not much attention. LAVA is a decent sized community, and if we collectively see something we want in LabVIEW, NI will notice hopefully implement it. Let me be clear I'm not saying we should all band together and vote for one thing, I'm saying that if an idea is truly a good idea, and it doesn't have much attention, post about it here and let the community decide.

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.

It used to. Now you have to wait for LV to finish scratching its arse (yeah I'm looking at you serial port VIs)

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