asbo

Some ideas I've stumbled across: - Dump everything into a subVI and paint the VI's icon to look like a wire. - Put everything in a sequence structure, turn off Auto-Grow, and resize it to hide what you don't want seen. - Paste a plain-white bitmap over top of everything. Like jdunham said though, if you're looking to protect code, use proper methods like passwording the BD.

QUOTE (PaulG. @ May 6 2009, 09:06 AM) I've used these before and I think they're fantastic - with a few short comings. A) There's no way to "clean" an INI file against a cluster. If your typedef changes and you're using an older INI file, you'll have deprecated entries floating around that have to be removed by hand. B) It's not easy to get a list of entries missing from the INI but are present in the cluster - one of the methods will throw an error if the two don't line up and I ran into this. I toyed with solutions for these for a bit, but have bigger priorities so I never really came up with anything solid.

labviewnoob, go to the Help menu and select the Find Examples item. NI has a phenomenal number of examples showing how to accomplish many different things in LabVIEW. Give a man a fish ...

What format is the file? Perhaps you could attach it to post for us to look at?

This is just kind of a shot in the dark, but I would say that #1 is better for speed and #2 is better for memory. #1 only calls VTD once but does have to allocate the n-array buffer ned mentioned. #2 calls VTD many times but only allocates one array (and it can pre-allocate it, at that). Unless you're running on a P133, the speed difference is likely negligent. You can test this by passing in a very large cluster (1000+ elements) and see what kind of times the profiler gives you. Without knowing more about the cluster in question, I'm not sure which method I would choose. If you don't know, you can see where buffer allocations occur by going to Tools > Profile > Show Buffer Allocations.

I believe that per NI, that "best" method is to use directly linked property nodes. I feel like this was a question on the CLAD or something. My preference would probably be Option 2, just because it's going to be much cleaner overall. I don't know why this is considered worse than using directly linked property nodes. While you may be able to get away with not closing your references (LabVIEW will probably garbage collect them of its own accord) it's absolutely best practice to close them yourself.

QUOTE (dblk22vball @ May 1 2009, 12:01 PM) I don't know that there's any functionality for this in LabVIEW, but you can do it from the Windows (XP and below) side of things by going through Control Panel -> Display -> Settings tab -> Advanced button -> DPI field. About 200% or so look pretty touchscreen-able.

QUOTE (jlokanis @ Apr 29 2009, 09:24 PM) You can bind the service to a user account (instead of the default Local System Account) which should give you access without needed to include that VI ... but I've never had to configure service logons programmatically.

Here's a prod in the right direction: you can find loops under the Programming > Structures and various timing facilities under Programming > Timing on your palette.

But they're just so cute ...

QUOTE (Michael Aivaliotis @ Apr 24 2009, 04:11 PM) I got an MSDN shirt just like that once. Some of the wrinkles actually made it through the first wash ...

If you have an initialization sequence/state of some sort, that would be a great place to just pre-fill the headers; unless you're not streaming data to the file per acquisition, in which case you can use Build Array to prefix your data array with a row of headers like crossrulz described.

I see what you mean about the floating point; I suppose it would only really be useful for cases involving zero and having a floating point input. For example, (-inf,0] and (0,inf) - the second case would exclude zero - with an input of 0.01. Since it has to be typecast to be used by the case statement, will it be coerced to 0 or to 1? Obviously, my intention would be that it be coerced to 1. Maybe I should just change the suggestion to be "Use floating point in Case Statements"

QUOTE (Darren @ Apr 24 2009, 11:45 AM) Have you guys ever considered offering extra credit?

I looked around and was surprised to find this hasn't been mentioned anywhere. By default, you can create numeric ranges by setting the case to be, say, "..0" to include zero and any number less than zero. I think it'd be handy to have exclusive ranges as well. Yes, there was always alternate ways to implement the logic, but that can get messy. Can't come up with any good notation for it, though. Maybe "1.,10" is the same as [1,10)?

What kind of table are you using that it takes a dynamic data input? A normal table takes a 2D string array. If you typecast both the numeric and the time stamp to strings, you can use a Build Array to create the proper input for the table. You may not actually need the cluster - your circumstances aren't very clear. You should probably post a screenshot of your VI.

Create a cluster that contains both your numeric measurement as well as the time stamp associated with that measurement.

QUOTE (LVBeginner @ Apr 23 2009, 02:46 PM) I think there's still some kind of configuration issue at hermes' end -- can you browse to the page in your browser? If so, you might have to fake a UserAgent header or the like. I get the security policy error you mention when trying to browse to the page, however.

You could use an alternative approach like the attached to update the timestamp on the file.

QUOTE (crelf @ Apr 22 2009, 06:24 PM) QUOTE (neBulus @ Apr 23 2009, 06:45 AM) In modern versions* of LV that is a waste of time. The for loop does that "for" you behind the scenes. In either case, I would leave it up to the developer to decide whether the data structure is large enough to necessitate that. If you keep giving out complete answers like that, crelf, you might find yourself out of work ...

Are you sure you want to be dependent on a DLL? You can use the native Move node to implement exact same logic. I tried to move a file onto itself (as I mentioned before) but LabVIEW was ever so kind enough to inform me that the destination and target paths are the same. :thumbdown: Conclusion: Windows needs a /dev/null/.

Maybe I'm not thinking in G enough, but I would have just used an indexed For loop with a shift register and a Build Array. Your solutions are a little more concise, though.

You should start by giving much more detail about what you're trying to do and what you've tried so far.

There are a couple ways you could do this with a single state machine - your choices are depend on your preference of Q's or string arrays. The important part, though, is to have two of whichever you prefer (or maybe even mix the two if you're feeling crazy). The idea is that one Q will manage the discrete steps and one will manage the automation steps. Initialize the discrete Q with Init or whatever initial preparations you need to do, then have your Default state be something to the tune of "DQ Next Automation Step". You'll need to have a few extra steps like "Start Voltage Loop" and "Next Voltage Loop", but doing it this way will let you have the opportunity to pause, change settings, whatever in between steps. If I have a chance later, I could build you an example of what I'm talking about, but I don't have any code ready which I can distribute.

Jeez, I was wondering what kind of insane situation one could be in to require the circumstances you described. That's harsh stuff ...