asbo

You are absolutely right, I'm thinking of disconnected typedefs. Please leave me to my madness.

Moreover, if you click through to the full editor using the "More Reply Options" button, you'll have the ability to attach files, including images.

You could try posting some example code to rattle something loose.. I remember reading through this and thinking that way was "good enough."

I didn't mean a bad module so much as a design problem with every module or its driver. NI I/O Trace may reveal some interesting low-level detail; if you go to NI, it will almost certainly be a useful diagnostic tool.

If your end user does not have a development license for LabVIEW, they'll need an executable build in order to run your code (and even then you may have other runtime licenses to consider). There is no "interaction" between the two types of builds. At least in the old days, an EXE was just a source distribution which got wrapped in an executable and bootstrapped to use the runtime engine - not sure if it's as simple now. Since you mention dynamically calling VIs, my guess is that you're not including all of the necessary VIs to run your code. You should probably post the errors you're getting in both scenarios to get more help.

Since sequence files can end up being quite large - my largest neared 0.5MB in binary format with lots of steps with code modules and it made the Sequence Editor slowww - the counter is likely just a lightweight way for anything operating on the sequence file programmatically to hint that the file might need a re-save. The alternative would be trying to track all changes in memory, which evidently the TestStand engine's architecture does not lend itself to.

This might be a bug with the module - have you bounced this scenario off NI?

I think that the change counter is session-based; that is, every time you load the file, it starts at zero and spins up based on edits made by the user.

You could package your installer to automatically check and start the service. I don't know when a deployment takes place during an installation, so it might not be possible with the NI installer, but we've used InnoSetup to great effect in the past to meet custom installer needs.

Why do I Receive Error -1967362042 (0x8ABC7006) When Deploying a LabVIEW Library?

I've seen this plenty. To help me sleep at night, I pretend that the case structure once held functional value and through the course of because someone just forgot to refactor.

You should post your code. What happens when you try to transfer the range? Is an error returned? Since this isn't LabVIEW-specific, have you googled on non-contiguous selections?

And as an added bonus, people think it's way creepier when cameras are looking down at them!

Where? Product pages load with a default tab selected.

Hmm. Out of ideas for now. Once you're able to link the resizing to a pattern or stimulus, maybe that'll point to something specific. Is there anything weird about this setup? Multiple monitors? Remote access?

Do you ever manipulate the panel size programmatically? Do you have "Maintain proportions of window for different monitor resolutions" turned on? (VI Properties > Window Size)

If you click "More Reply Options" on this page, it will take you to the full post editor, which has a panel for uploading attachments. I took a peek at your VI - it does depend on the lvsound2 library. As I mentioned before, my workaround was not elegant; I just multiplied my acquisition duration by a constant to get the right output duration. Do me a favor and report this to NI (http://www.ni.com/support) so they know someone else is running into this problem.

I'm pretty sure the Express VI you're referring to depends on the library I mentioned. You should follow James' suggestion and post your code.

Your use of Pick Line is absolutely killing you. I get a throughput of about 400KBps - maybe a little bit more than you, but not awesome. Your 300MB file will scale out to 12 minutes if the algorithm is O(N) (which it isn't, because Pick Line won't "remember" where you are in the string). I didn't look closely at it before, but think about what you're doing conceptually: first, you parse the whole file for lines, just to get the count. Then, you iterate n times, seeking within the string to pull out just one line. Messy. So, save yourself some trouble and just build an array of lines while you're counting and index off that array for your next loop: This just about doubles the throughput to 800KBps. Not bad, now you can process that 300MB file in 6 minutes instead. But you know what? We can do better. Pick Line is still a klutzy approach to this problem. So, instead, we're going to split up the data up beforehand and not care how many elements there are, because LabVIEW will handle it all for us. I'm using an OpenG VI here, String to 1D Array (but the concept is very easy to implement with Scan String for Tokens if you can't use OpenG): That little guy lands at 50ms, a 6x speed up from the last stage and a 12x speedup overall; about 5MBps. 300 MB in about a minute. By removing the disk read and header/footer time from the benchmark, I got around 30ms of data processing time, which equates to a bit over 8MBps and 40 seconds processing time for 300MB. On-the-fly handling of the header and footer would not be difficult to implement. You know your markers for each, and once you get the header you know exactly where the footer is going to be. If you really need throughput, give it some thought. However, you're probably not on a 8MBps link, so your bottleneck is now probably the network.

I would recommend reading the file in 128-byte chunks and processing that chunk right away. That way, you also know exactly where to look for your ".." and have one chunk of string that's easy to manipulate/subset, if necessary. To improve disk/computation parallelism, you could implement producer/consumer loops.

I know some other boards do this I wasn't sure if LAVA was in that circle... I have a habit of merging double posts that I see. You make a point about divergence that I haven't really considered, but I would counter that different conversations should have different threads (and that's what the mods here tend to enforce as well).

Well, your algorithm doesn't really make sense to me - you're pulling off a 1 character string, turning it into a byte array, and then operating on the array... not sure if that's supposed to be an optimization or if there's functional value I'm missing. But I get that you're offsetting the ASCII value based on two different constants. If you convert the whole string to a byte array (and then index off that), you will see a speed improvement. I don't see what defines a "line", but I would handle the ".." a bit like you've done the escape character. You'll need to add lookahead logic and then wrap everything in the loop in the case structure to add a "no-op" for the second period (or the first period, if you want to make it more complex). Unless, of course, ".." is never a legal substring, at which point I would just do a search and replace on "..".

It might be because you're not a premium member. I thought the window was like 5 minutes, but I'm not positive. Test double post... Nope, mine get combined as well. The IP.Board feature is called automerge and an administrator can disable it if so inclined. I don't know what it's set to right now, but I have definitely seen double posts within an hour of each other.

If you should change your profile to say LabVIEW 2012 if that's what you're using now. I can't view your code, I only have LabVIEW 2011SP1.

I have use "bomb-proof containers" quite a bit with typedefs in general, especially with external DLL calls where the struct might need some initialization. I've also used non-auto-update disconnected typedefs to implement backward compatibility with file formats before, which would be a lot more painful (save, rename, replace) if the feature was removed.