asbo

This smells a little bit like an X-Y problem. Can you clarify what you're ultimately trying to accomplish?

Have a look at the Programming > Graphics & Sound > Picture Functions palette. The [Get Image Subset] VI sort of does the opposite of what you want, but you can look at the block diagram to see what it's doing, and see how you can perform your own manipulations on image data.

The Vision module also has a lot of image manipulation capabilities, but is not included with the base LabVIEW install or license.

For what it's worth, I've been using the dot to browse for a very long time and never had issues with getting to the right post. Based on where those links point, I don't think it could be a client-side problem, but I don't know for sure.

One side effect is I see flickering of the images when resizing slowly. I added a defer front panel at one point but that didn't seem to fix it.

This doesn't work because LabVIEW doesn't control the rendering anymore, it's moved into dotNET's domain.

I feel your pain. I am no GIMP or photoshop wiz either, which makes certain things quite difficult. I am running into this more lately, where customers say "I want it to look like .NET does" but they want to use LabVIEW for the sake of quick development. I understand the NI "branding" that comes with a LabVIEW-looking UI, but I think it is important for NI to make some headway on this front to allow us more modern UIs. To be sure, the silver controls were a step in the right direction (though I still find them to take up way too much space). But, when I drop a .NET control and see the ridiculous amount of functionality available, I realize LabVIEW definitely is still lacking.

In terms of aesthetics, the system controls get you 90% of the way there. WRT functionality adjustments, I think LV will always be lacking because it's such a low value-add.

I don't think VIPM plays any role in selecting the correct reuse for a solution. The ability to do that comes down to familiarity with the tools in your reuse library, and more importantly, have it all installed/available so that tools like Quick Drop can point you in the right direction when you're fishing for nodes.

Shot in the dark, but maybe Wine could work on Linux?

That would be very strange; the 32-bit and 64-bit IDEs are all but guaranteed to produce different binaries, but I can't speak with confidence about it. You could clear your cache, compile a VI in 32-bit LV, pick a file to watch, then open it in 64-bit LV and see if that same file is messed with again.

It sounds like the device is either damaged or not connected to your computer properly. I'd recommend reviewing NI ELVIS: Resources for Measurement and Instrumentation and NI ELVIS II Manuals to make sure you have it set up correctly.

I'm not sure that would work - it looks like it's cPCI. Do they have a PXIe version?

Oops, good catch - I overlooked the express part. I don't see a PXIe version, but I've been successful in the past getting custom hardware quotes from Pickering. However, it doesn't look like Pickering does *any* PXIe equipment, so you'll probably have to check out some other vendors. You may end up having to fork over some cash for NRE.

How about a breadboard?

You may be interested in: site:lavag.org openoffice

You should post some sample data that you're trying to analysis as well as the code you're using. Otherwise, any advice is going to be shooting in the dark.

Not that fancy (it's LabVIEW doing the work )

I meant because you were already using Windows 8.

Well, aren't you fancy?

I think there's supposed to be an attachment on your previous post, any chance you still have the relevant snippet?

Yes, you would have to synchronize your LV2 with your FP control/indicator. Likely the biggest slowdown you're facing is that operating on controls/indicators can only work in the UI thread, while most code can work (often in parallel) in various other threads.

I vaguely recall someone posting about doing something like that before; at least related to not wrapping. An XControl would provide the encapsulation you need, I think, but XControls are not necessarily for the faint of heart.

Are the value non-sequential AND non-contiguous, or just non-sequential? If it's the former, play with values in the unassigned spaces between values and see how it handles coercion.

neil does beg a good question, however - seems like an awful lot to dig through for a user. Maybe it could be broken down into three or four separate rings and selected in stages (e.g., the Add A Vehicle pane on advanceautoparts.com)

No problem! You're lucky I actually had a 64-bit RTE installed (though I have no idea why...)

If you're on a 64-bit machine, the 32-bit RTEs will show up under HKLM\SOFTWARE\Wow6432Node\National Instruments\LabVIEW Run-Time\. If you're not on a 64-bit machine, there will be no HKLM\SOFTWARE\Wow6432Node.

This checks out my machine:

I would have no qualms about querying the registry, though I might go as far as testing the validity of the Path value.

WMassey: I removed your attachment because it has your e-mail address in it.

Why not make the substitute receiver send a message on the same queue the sender uses and let the substitution command be handled in sequence by the current receiver, which guarantees that you don't have to add extra logic to check if the current receiver is "busy." This assumes each command is atomic - that is, the sender doesn't say "DoAcquisition" and then poll "DataReady?" or "GetData."

A question that might have allready been answered. Do I have to make all the SubVI's within a reentrant VI's as "reentrant" or not. I tried it both ways and I didn't really see a performance difference.

If you don't, the reentrant VIs will block on whatever VIs are not reentrant. Instinct says this will only become a problem when you forget that you did it that way.

If I understand your idea correctly, I'm not sure if this would solve the problem of knowing when a particular file is finished without holding all the segments in memory. Currently, each segment is sent back to the main VI with the file path that the segment should be stored to. This way, if a segment belonging to a different file comes in, then a new file is created based on the path name provided.

Whether or not you store to disk is irrelevant as to whether you can track if a file is done. The Download File VI can still maintain a list of all the segments it expects and all the segments which have reported done. The Download File VI doesn't need to hang on to any of the actual data (let the segment downloaders write the file themselves, if you like). When the segment reports done, remove that segment from the working list of remaining segments.

if you want to do it easily in LabVIEW get the RGT, if not do the ActiveX work. You'll be better off in the long run with the RGT since everyone has a need to export to Excel and you'll just wind up recreating the toolkit.

I've only ever used the RGT for outputting Excel-format files. It has the capability to read as well?

I think the question is more about moving the additional non-waveform elements of a cluster type into the attributes of a waveform type.

Personally, I'm going to guess that the overhead of type conversation/flatting into the attribute tree will actually slow down your code and probably consume a bit more memory. Not mention the ergonomics point you already touched on.

If you know your waveforms get passed around a lot, it might be a good idea to look at DVRs so you can ensure copies are only made when absolutely necessary. After that, focus on anywhere you extract data from the waveforms and make sure you're touching as little as necessary for whatever operation is being done.

LabVIEW doesn't support the XLS format natively, so you'll need to google around on Excel automation. It's accomplished by using an ActiveX object to communicate to Excel.

FWIW, I just fixed all my sound problems (both input and output) by upgrading from LV2011 to LV2012. lvsound2.dll seems to be the same for both (exact same # of bytes, anyway), so it seems to be something in LV2011 that just doesn't play well with sound.

Do you, by chance, add or remove devices during your application's lifetime? I had a big problem with that on a tester which paired and unpaired BT audio devices. I can't remember if we ever tested it on LV2012.