asbo

I think I went through the same trial at one point, not for speed, but because we were having trouble with displaying the report in our UI and didn't want to buy a license for each rack. I doubt the ADO code is still floating around but I'll have a look and see if I have any complete examples left over. Easy starting point for you, though: drop a new Automation Open node, right-click it, and choose Select ActiveX Class > Browse. Use this dialog to find the Microsoft ActiveX Data Object class. There should be 5 or 6 objects you can create (Connection, Recordset, Command, and the like). Now that you know where to get those, googling "ado excel" will give you plenty of information on getting started.

Then I have to ask - why are you using Excel at all? If you have no need for formatting, why not write to a standard CSV/TSV/whatever? Just want to make sure you're not skinning that cat unnecessarily Opening and closing Excel are almost certainly the longest parts of your process. If you want to hide this from the user, open Excel while your app load initially and close it when you exit, hanging on to the reference in the interim. And there's no need to mess with user32.dll, Excel has a Visible property. Since that's an add-in, I expect it has (more) direct access to Excel functionality, possibly through VBA or something like that. Since there's no ActiveX layer to go through, it's much quicker.

It's pretty easy to get through WMI: Set objSysInfo = CreateObject("ADSystemInfo") strUserDN = objSysInfo.UserNameSet objUser = GetObject("LDAP://" & strUserDN)Wscript.Echo objUser.cn but I don't know a slick way of getting that information back to LabVIEW outside of writing it to temp file. ref: http://www.windowsitpro.com/article/tips/q-how-can-my-batch-retrieve-the-common-name-of-the-current-user-.aspx

ADO will be faster, but at the expensive of formatting options. If all you need to do is dump data into a spreadsheet, ADO is probably the right way to go. I don't think you can really modify files using ADO, so if you're starting from a template that may be a deal-breaker. The automation interface is for just that - automating tasks (even if it's just importing data) that you need the Excel feature set to accomplish (charts, highlight, find, sort, and so on). It would be interesting to see how much faster ADO was, though. Also, do you have Excel visible while operating on the spreadsheet?. I've noticed that tends to slow it down significantly.

I don't think the use of 'opportunity cost' is fair here - sure, one idea might get implemented and another might not, but I expect that it's rarely one idea OR another gets implemented. It may seem that way to us, but that's just perception (I hope). Is there an idea you wanted pushed through that is comparable in the (perceived, at least) level of complexity of wire alignment? The block diagram cleanup aligns wires a-plenty, so there's probably not going to be much wheel-inventing to implement wire alignment tools.

I don't know what version of the Report Generation Toolkit LabVIEW 7.1 puts you are, but in v1.1.2 (LV2009) it looks like the RGT won't call Quit on Excel if ActiveWorkbook is non-null after it (RGT) closes the report file - which means, in theory, if you have any other files open, one of those should become the active workbook and stop Excel from closing. I don't think OOP was very popular by 7.1 so I have no clue what code you're looking at - dig into the the Dipose Report VI and see what's going on. You can use the method above to kludge your version of the RGT if it's not already doing something similar.

Are you sure the data coming back is intended to be human-readable?

That sounds a little bit like the behavior you get when you choose the wrong port speed. Have you confirmed what baud rate the device is communicating at?

Sounds like you had a thrilling weekend Benchmarks like these always interest me, it's neat to see how we can tweak implementations that seem trivial but have staggering effects.

I agree, in the interpreter situation, you're going to have loads of case structures. You're definitely right, a subVI is the proper way to do things and that's really what I suggest, especially since interpreters can be a little difficult to read. If the code is already written, you shouldn't need more than 5 minutes to create the subVI. Having to labels the wires will give you a chance to review your logic as well. Squishing down code is only a good choice when you know it's perfect.

I imagine a batch file here could work just as well (if you don't want to jump through the hoops of writing your executable).

Personally, I rarely have a 'plan' for my layout when I start, but often will do a bit of reorganization on-the-fly as I place nodes. That way, the clean-up is progressive and I'm not left with a big wire-y mess when the functionality is finally done. As LogMAN mentioned, you can select a rectangular area with the mouse (using the pointer tool) but you can also use Shift+Click to add or remove individual objects to the selection. Another handy shortcut I use is to hold Control and then click and drag; this expands the diagram from the point you begin your selection outward in the direction(s) you drag. You might have to give that one a try to get what I'm saying

Maybe it really is 0x500 It could be that's not an automatic promotion, or it was and somehow got disabled? Hard to say. In addition to deleted posts, it could be a synchronization issue from when LAVA 1.0 posts were counted to start all of us off with the same post count as before - I know the guy who helped pull that off and his SQL skills are questionable ...

I imagine the count by your avatar is "posts ever" and in your profile it is "posts now" - the difference comes from posts having been deleted.

Yeah, I've seen something of that nature before with a while loop and a case statement - cover all the cases you think you'll need. It is definitely a kludgey solution, but a solution nonetheless.

Yep, I don't think you're going to be able to find drivers just for that device. Maybe it's worth an e-mail to NI? But by the time you get a response, you could probably have just downloaded and installed the full package anyway

You could use a SystemExec call within your app to create the network share, if even just while you were actually going to do I/O: `net use [driveletter] [sMBpath] /user:[username] [password]`. When you're done, just call `net use [driveletter] /delete`.

Here's a good starter from NI: http://zone.ni.com/devzone/cda/tut/p/id/3198 It would be a way, for example, that you could take ShaunR's implementation and have it appear as a single control/indicator on the block diagram and have the code that manages the boolean's state to be hidden from the user.

Sounds like you'll need three numeric controls for input and one numeric indicator for output. You can drop these from the Controls > Numeric palette on the front panel. Most of the nodes you'll need to code your calculation will be on the Functions > Numeric palette on the block diagram. Take a stab at it and post back what you come up with.

We need feedback on our feedback!

One step further would be to take a approanch like hooovahh's and wrap it into an XControl implementation - this is what I thought of when François hinted at 'more complex code'.

This is what I've always used, given that I was always using MySQL for PHP web apps. It's a little clunky but definitely functional. I imagine that one of the desktop applications will be more feature-rich and comfortable use.

This is the LabVIEW Simulation Interface Toolkit, right? If you're still receiving licensing errors, you're probably still calling one of the toolkit's VIs somewhere. How exactly does the toolkit ask for a valid license? When LabVIEW starts, or when you actually run your code?

Ooooh, good call.

Practically copy-paste from mine You should wire your Sequence ref through the first for loop and close it. You probably won't ever have a problem without doing that, but it's just The Right Thing To Do.