asbo

I guess the way I envisioned it, the IDE should break the wire at development time, not just no-op at run-time. Only the latter would be too subtle, I think. This is a perfectly good use case I think didn't think of because I don't do this This was intended to be the caveat to my "scan every input VI" method. If LV isn't already tracking which VI opened the reference (and I can't really find a compelling reason that it would have needed to before this feature) then I don't see an ideal solution for resolving where the reference was opened.

Thanks - kudos'd.

The funny thing is I went and tested it to be sure I didn't have the two switched, used Shift with the key combinations, and then wrote it down wrong. Thanks for catching that.

In order for the function to decide that the reference was created within the class, it would to check every single member VI to see if had an input of this reference type. What if it makes sense for the class to accept an externally opened reference and keep it in its class data for a time? I think that the simpler (albeit more tedious) solution would be to never expose an elementary reference type; you'd have to always wrap it in a cluster or class. It's a cool idea, but I think it would be a lot of work to implement under the hood and still allow developers unusual flexibility like the above.

We're utilizing TDMS for for results, but I really like the idea of SQLite of error/warning/whatever logging. Has anybody tried to tie the two together? I think you can stuff a blob in a TDMS, so you could include your database in the TDMS if you wanted, but that seems a little hacky.

The shortcut for All The Way To The Back is Ctrl+Shift+J. All The Way To The Front is Ctrl+Shift+K. I use these often. Be mindful of when you have controls/indicators/decorations mixed with containers (like a tab control), since the Z-Order instead the tab control is completely separate from the Z-Order of the FP.

Only slightly related, but a guy here has a Windows 95-based logic analyzer. All told, it works better than you'd expect.

USB hubs are something to look out for - too many or certain brands or unpowered hubs can introduce weird problems into your instrumentation. It's best to get your devices as close to your PC as possible. An NI article addressing your issue - Termination Characters in NI-VISA: Instruments Using Multiple Termination Characters

The multiple calls isn't an issue - that's the fundamental reason batch files exist. I was trying to get at the fact that you might be able to move some of your logic from LabVIEW into the batch file, eliminating the need for multiple call-and-returns. If that still isn't making sense, post a flowchart of your process and I'll see if it'll work in MS Batch.

A batch file may still be a viable option - if the Mecurial executable properly sets exit codes, you may be able to handle looping logic within the batch file.

K.I.S.S. award goes to ...

It opens like any other VI for me. I placed it on the BD of a new VI, Ctrl + double clicked it, and got its BD. Arg 8 does indeed appear to be flow control. More than anything, it sounds like you're not configuring your port correctly. "[E]verything is locked" is a little ambiguous - LabVIEW freezes? The VI stops reacting to user input? The VI stops reading data from the device but is otherwise responsive? And what do you mean by a simply command - do complicated commands fail? It looks like the device has a particular message format, I would verify you're sending those commands correctly, including the right termination character. If you think you have everything correct, post your code (which you probably should have done in the first place). No one has your device on-hand, so we can only offer general advice.

Hmm. Is using CMD a necessity or a crutch? You could create the target process yourself and read its output using pipes (or a slightly denser example from Microsoft). You can use the console functions to create a console and then read/write at will, but I'm not sure how easy it is to make that console a shell session.

I haven't tried it, but I bet you could use Defer Panel Updates to mitigate or remove this problem altogether.

Likewise. It might be set by certain graphics drivers, or the fact that the T61 is a widescreen, or any other number of things. I have also installed Win7 on a laptop and had this setting default to 100%, so there's some kind of criteria.

There's a property node within the Configure Serial Port VI. Can you view the block diagram?

I spent a lot of time trying to use Bluetooth functions from LabVIEW. My solution was not to use the built-in nodes, but to use CLNs to call the Windows API to accomplish functionality. Some functions are difficult to integrate because in a couple instances direct C-to-LabVIEW ported code would behavior differently. For some of my functionality, I ended up relying on a System Exec call to the compiled C code because I couldn't make LabVIEW behave. What functionality are you looking for?

The Font Size seeting is the DPI setting.

Assuming you're on Windows, use google to find out how to change your DPI setting.

Maybe this is too obvious of a question, but can you move your typecast out of the loop (either delay it or do it before the loop, based on your circumstances)?

Can I ask, what's your concern with the buffer allocation? In case you're operating under the same assumption I was, a buffer allocation is not the same thing as a data copy.

To make sure we're on the same page, the "read only" property isn't what I'm referring to, I mean the actual file system security permissions:

Are you an administrator on your machine? IIRC, LabVIEW generates a bunch of VHDL code to pass to the Xilinx compiler and stuffs it into a folder off of C:\. I have FPGA installed right now and C:\NIFPGA is catching my eye - make sure you have recursive Full Control permissions on that folder.

This is pretty standard - every calculator or software I've ever used only used degrees if you explicitly asked it to. Radians are less intuitive for us meatbags, but I imagine there's a technical reason our silicon friends default to them.

Having to do workarounds like this makes me wonder why a VI property isn't added to force a FP to be included. Is it just a legacy thing or is there a technical reason?