asbo

Would it be possible to use a relay-based solution? The NC path would have your passive impedence and you could wire the USB6211 to NO and then flip the relay as part of your initialization.

I don't know if there's another way to modify your configuration, but you can absolutely install MAX without a LabVIEW license. It's bundled with the NI DAQmx drivers, so run the installer for that and you're good to go. You can find a list of MAX-related downloads on ni.com.

I'd heard hearsay (and I honestly don't remember from where) that the CLA and CLD were getting easier. Take this with a grain of salt, YMMV.

Yeah (sub 100 measurements), which might validate using that method. I was hoping the compiler would make the difference completely moot, but I guess it's pretty dang close. Subroutine priority gets them even closer together, so it's probably a good tradeoff.

I hadn't noticed the code even used that (I've always manually done a FindWindow() call to get the HWND), but yeah, that's one of the super secret properties.

That solidifies one part of it ... I expect that if I'd opened up the help file, it would have been right there waiting for me. Thanks nonetheless. Does anyone have any feedback on the balance of my questions?

Match Pattern uses regular expressions and in PCRE $ is still the end-of-subject anchor. PCRE does have the option to mean EOL, but that's not the default behavior. You did raise a good point about check the length first (I thought that it should be faster) but it seems the original VI wins out by a tiny margin. Weird. MD5 Hash Benchmark.zip

My impression is that this feature allows you to debug a built executable the way you would VIs, to some extent (see block diagrams, and the like). Since the disable structures are on the block diagram, I would think would have to be included? This may not force subVIs in disabled cases to be built and linked, however.

Ah, okay, I like the idea, but there should obviously be an OpenG implementation of that trace event so that everyone can use it.

I'm having a go at implementing some of the Windows Sockets API and run into the same issue Rolf talks about in this post: Quote Just one more comment. The error handling with WSAGetLastError() is probably never gonna return a meaningful error. (WSA)GetLastError() retrieves a thread local storage value set previously by another function. That assumes that the previous function and GetLastError() are called in the same thread and without any other function in between that could set that value. Since the CLN's are set to execute in any thread this is absolutely impossible to guarantee and in my experience actually almost never happens either. Not even setting both CLNs to execute in the UI execution system would be able to guarantee proper operation, since theoretically there could still execute another call to an API that influences this value, between when LabVIEW calls the recv() function and when it eventually calls the WSAGetLastError(). My issue is a little more fine-grained, perhaps. If I have my two CLNs SomeWSACall() and WSAGetLastError() on the same block diagram, happy days - I get my socket error code. However, I wrapped that WSAGetLastError() call into a subVI and now it doesn't work! Evidently, using a subVI ensures that something, somewhere makes a call to WSASetLastError() in the UI thread. I did open a support issue with NI about it, but I expect they'll tell me what I already know. Why is it that we do not get the fine-grained thread control for CLNs as we do for VIs - or is it that "execution systems" in LabVIEW are not explicitly threads? Though I'm referring to specific functions, this is really more broad - I will probably be working with several other Windows APIs in the future and it would be helpful to have a complete grasp of the nuances here.

That's a good point. Also, is it critical that you get 100% delivery of the waveform? UDP is faster than TCP because there's no ACK involved, if you can tolerate the possibility of missing parts of the waveform.

It runs fine for me as well. I would recommend an uninstall/reinstall or repair of your RTE installation.

You don't need the config VIs, then. You can use LabVIEW's native Read from Binary File and Write to Binary File nodes to manage your files.

There's a knowledge base article on NI's site that talks about this: Do LabVIEW TCP Functions Use the Nagle Algorithm? The article includes an LLB which has the TCP_NoDelay.vi you need.

Have you tried removing the MathScript code and recreating it? This probably won't tell you what's wrong, but it may be a solution.

You mentioned attachments in the first post, but there aren't any...

Does that mean in order to use the (proposed) task manager, you'd have to install the DETT?

To fix the weirdness beneath the title bar, maximize the front panel before setting it back to standard. Toolbar.vi

Ahh, that makes sense. Looks good!

For a long time now, me and a couple other guys here have dreamed of being able to drop a "black terminal" which will literally take any type without coercion. I saw AQ's post when he first wrote it and I was excited to see that we're getting closer to having that feature. I wish I knew more about how it was written.

My only complaints are that of verbiage: * "Strict Character Case" vs. "Strict Capitalization" * "Is an MD5? returns TRUE if Input String represents an MD5 hash, otherwise it returns FALSE." * "Valid characters are ..." vs. "Expected characters are ..." Other than that, thanks for dedicating the time to this

Your list so far is a solid start. The only additional function think of offhand is to work across projects/application instances, but I haven't messed with VI server enough to know if that's even feasible. I'll think about it some more and see if I can come up with some other good features.

Allow Diagram Disable Structure and Conditional Disable Structure to be replaced with a Case Structure Add the ability to replace a disable structure with a case structure

Between your VI and my BDWin.Open.vi he's got a good bit of legwork done for him.