asbo

Search LAVA for posts related to unicode, you should be able to gain some insight from previous discussions on character sets. At this point in time, it's not a terribly simple process. Perhaps post a snippet of what you're doing so far? Search LAVA for posts related to unicode, you should be able to gain some insight from previous discussions on character sets. At this point in time, it's not a terribly simple process. Perhaps post a snippet of what you're doing so far?

The bold section is only true if every step in your sequence is reporting. Otherwise, the array index correlates to the nth reporting step in the sequence. BigAngryHillMan, rather than having to dig through ResultLists, why not use a PostStep callback? You might consider using at the PostResultListEntry callback instead.

Are you just trolling or does 2009 actually outpace 2011? I haven't used it enough to know ...

Very true. Your suggestion makes better sense now. Has anyone written a framework to turn a polling VI into a User Event? I think it could be made generic enough to have some good use cases, though it would probably need to be class-based in order to use strict typing on the UEs. Could be fun to develop.

You could clone your library to have RT and non-RT versions in your user lib. It might make a little more management work, but it'll prevent LabVIEW from recompiling for each platform. Separating compiled code from source won't actually fix your problem, it'll just move the problem out of your SCC.

If someone has a real aversion to the polling method, it might be just as well to make a parallel event loop, registering for the same events you would in your main loop.

Unless clients will only need a subset of hardware and you want to deal with the challenges of managing overlapped sessions, you'll have to write a queue-style system where clients must wait for a turn to use the hardware.

Bump for my edit, in case you miss it.

My first stray thought is to make sure that the C++ code isn't padding the struct - I believe the default is 8 bytes, so your 4-byte int has 4 empty bytes appended (presumably for DWORD alignment). Use the #pragma pack(1) directive to enforce this. If you put the directive right before the struct definition in the appropriate header file, every function which relies on the struct will pack it properly. If, for some reason, other parts of the C++ require different packing, you can call pack() again right after your structure definition. MSDN documentation on pack(): http://msdn.microsof...1(v=vs.80).aspx It looks like you can alternatively use align() in the declaration of your data type for the same effect. I have only ever used pack() before, so I can't vouch for this approach. If you can't change the C++ code right away, you can just pad your cluster in LV from {int, dbl, dbl} to {int, int, dbl, dbl, dbl, dbl}. The duplicate of each data type should be garbage or empty. Edit: Thinking through this, your second double should have some value - but maybe your default packing isn't 8.

I did play with it briefly, converting a few simple contain VIs to C code. I remember the C code seeming overwhelmingly complex, but that's mostly to be expected. I can't remember if I compiled it or not, but I'm leaning towards no. Have you tried a screen recording app like FRAPS? That might let you catch what's going on in the window. I can see your target is Linux, have you tried compiling for win32 and checking the results?

I reported this bug to NI - they're already aware of it, but for reference it's filed under CAR 183817:

If you don't mind the suggestion, adding an 'r' prefix to the revision would make that very clear. Thanks!

Unfortunately, I don't have any experience with VISA driver generation. Of course, my first suggestion is to get in touch with NI and ask how to better diagnose this issue and if they've seen it before. A situation where a generated driver is used on multiple identical devices may not be that common and could have some issues. Also, you could use NI's I/O Trace to log everything that's going on with VISA - I don't know if this will catch what the driver is doing, but an I/O trace is usually something that NI requests to troubleshoot hardware-related issues. Additionally, you could check the Windows Event Log to see if there's any information there - again, I don't know if the driver will report there, but it's worth checking.

This bit me recently - a PXIe chassis got ordered which has (I think) 3 PXIe slots and the other 5 are hybrid. The problem with PXIe cards is that they're more expensive and literally none of the hardware in this system needed the bandwidth of PXIe - there's one lonely thermocouple card that's PXIe for no good reason. In any case, a coworker went to add a PXI card to the chassis (in one of the PXIe-only slots, as it turns out) and couldn't figure out why Windows wasn't picking up his new card. In my particular scenario, I think that the wrong chassis was ordered - which was a result of not enough thought going into what hardware was needed. I don't see a scenario where an all-hybrid chassis would be helpful unless you're going to be constantly reorganizing hardware.

More importantly, going through the effort of trying to write targeted questions will help you advance your comprehension of the problem and the tools available to you. I often find that if I'm stuck on a problem, drafting an e-mail to try and explain it to a co-worker as though they know nothing about the problem will help to straighten things out. And if it doesn't, I've got a perfectly useful e-mail to send.

On the surface, it doesn't seem like a VISA issue, more like a device driver issue. Are you using the latest driver from the manufacturer?

On the code repository page for this tool, the download link lists two files: Code_Capture_Tool-2.1.4-1.ogp and Code_Capture_Tool-2.1.4-258.zip. Are these different releases? I don't understand why the ZIP file is marked -258 when the package is marked -1.

Shameless! I'll consider it ... But wait! The CCT dropped a wire... Bug?

You should use the Index Array node: If you're looking to reduce the diagram footprint of this section of the code, use a for loop and an un-bound property node. Let the For loop index an array of all the control/indicator references as well as the array of values: Turns out you can't make a snippet use linked references, even if you include the terminal. Right-click each of the terminals in the snippet and create a reference. Replace each of the reference controls with the reference constant.

Sure: Doing A with N strings or doing C isn't really possible because clusters have to be defined at development time, and N is a variable that's (apparently) not known then.. I don't know if I really grasp what you're actually trying to do, so posting some code would probably be a good idea.

Is there a controller in the PXI chassis? If there is and I'm understanding what you want to do correctly (maybe a diagram of the data paths would be more clear?) you have the controller in the PXI chassis publish its DMA contents on the network, via shared variables or some other protocol.

Oh, you didn't specify your queue data type was an array; that would implicitly require chunks of contiguous memory, yes. There are Windows API calls you can use to evaluate the memory of the system, but you'd have to do some trial and error to see if you can find which counters are going to help you predict this scenario. I don't know of any way to predict out-of-memory conditions with reliable accuracy. There's always some calls to resize the working set of LabVIEW, which I've found works more reliably to reduce memory footprint than the request-deallocation method (but there may be caveats to doing this since LV has its own memory management). There's a thread about it on the NI forums.

I'd be surprised if queues needed contiguous memory (I'm picturing a linked list implementation), but there's certainly no upper memory limit that I know of per-queue. What's more important, of course, is how much memory the rest of your app was using. How much memory was free on the PC at the time you got the error? The scenario you're describing was on the Win32 system, right?

As an exception, I wanted to throw out that I had an instance some weeks ago with calling an external executable (a C-based Windows 32-bit executable written by me) with System Exec.vi which would always return LabVIEW's error 2 ("Memory is full"). The situation required a relatively quick fix, so I added in the cmd /c call and it worked. I'd like to go back any figure what's going on; the EXE itself is a mere 8KB and only depends on one atypical component (bthprops.cpl).

So what behavior are you actually seeing the main window? You can click buttons and the like but they don't actually do anything? I don't have any better ideas than Yair, but if you have to work around this issue you can use the Controls[] property of your panel and just disable everything before calling the subVI.