asbo

Stagg54 is referring to the hidden tool used to diagnose the source of insane object messages. Check out the article on the LabVIEW Wiki.

I'll try to remember to bring CDs with me and if I remember (and have a compliant relative), I might be able to actually test it in the development environment anyway. Any idea if LabVIEW can be as deeply-rooted on OS X as it is on Windows? I don't want to mess up someone else's computer.

I think I have Snow Leopard VM somewhere. If I find that, I'll let you know.

Your PNG file is actually causing an exception in what I assume are CLNs to functions in the LabVIEW library. You should submit a copy of the PNG file to NI support so they can correct their library. I'd be interested in seeing the file if it's something you can make public.

If you can (or want) to build a test application that I can use with just the run-time, I can test it on another version of OSX this weekend. I'll have to check to be sure what version (I think Snow Leopard), but let me know if that's valuable to you.

It's an instrument control and data analysis program for a mass spectrometer. There are different windows for viewing data in the time domain opposed to the mass domain for example, and other windows for instrument control, sample queue management, etc. All the windows interact in various ways, and depending on context they can force each other to the top of the z-stack, but simply activating them never does.

Makes sense - I've written multi-screen applications (in Visual Basic) which behave exactly that way. I think the MDI environment is really intended for grouping several windows which are immediately and always relevant to each other, ala Visual Studio (there's an option to make all the windows floating instead of lock into the parent, but the specific name escapes me). Thinking about it, it practically makes the whole shebang a bunch of SDIs which still benefit from taskbar grouping.

If speed/space is the limiting factor in writing out to a temporary file, a RAM-disk may be a happy workaround for you.

Excellent responses thank you. I never considered MDI, but the behavior is definitely consistent with that UI model.

I was asking because this MDI behavior runs counter to another application that my users will often have running side by side. My application will bring all its windows to the front as soon as you use any of them, whereas the other does not enforce this behavior. The inconsistency is annoying. I personally have no preference between either model, I just don't like how each application behaves differently.

What's your other program? It sounds like it's probably MDI-esque, but implements a custom windowing scheme so as to avoid the behavior you're having problems with.

So the LabVEIW development environment is based on MDI, without the benefits of it being an MDI?

Well, if you go by the Windows implementation of the MDI, it's doing everything as it should. If you consider a more purist definition (several related but independent windows), I would agree that LabVIEW is doing it wrong. Based on how often I have VIs open, I wish NI had found a way to go the latter route. I would even argue that giving focus to the block diagram or front panel should not affect the z-order of the counterpart window.

Use named queues. Each data source binds to a specific named queue and the consumer is able to select the correct queue based on its needs. If your data sources will all have different data (eg, Type A, Type B, Type C), you'll either have to find a common container format to exchange data in and have routines to correct identify the Type of data to process it correctly. Alternatively, you have one static loop for each Type of data and go from there.

LabVIEW VIs are MDI children of a hidden window which lets them all be grouped together correctly by Windows. As far as I know, there is no way to disassociate them from each other or the parent window while staying inside the same image (executable). Built executables are also subject to this.

That is to say, this is a Windows constraint which is enforced because LabVIEW uses a MDI environment.

I finally looked at the VI you linked originally. It's extraordinarily close, just wire a constant timeout to the event case.

Is there a way to make your timing code proactive instead of reactive? That is, time the LED states in the code which actually changes the LED states.

A parallel loop which uses an array of the references of your LED controls could build an array of timestamp and state for each control. It will be more difficult and messier to try and use terminals or locals.

Are you actually watching a physical LED or do you mean an LED indicator on the front panel?

If it's the former, what are your criteria for on/off? Current? Luminance? Based on that answer, you're going to want to use different hardware to detect the change.

If it's the latter, you can use an event structure to catch Value Change events. The event case will automatically provide a "Time" terminal. Be wary, though, it is not directly comparable to Tick Count or Unix Time (off hand, I don't exactly remember its significance beyond relative comparisons).

Edit: I see your snippet now, so I'm assuming the latter case. However, it's not entirely clear what you're going for. You just want to time the duration between user input or something? If it's going to be staged (multiple sets of inputs) I would probably use an array of control references. I would still use an event structure instead of polling.

Don't turn the device off? You should describe what your ideal outcome is. What you probably should do is conditionally disable plots on your graph.

I know that on more than one occasion, I've wanted to do this exact thing ever since projects were introduced (that is, use conditional compilation symbols with more flexibility). The workaround I've always seen and used myself was to place the constant in a subVI and place the subVI where necessary. Thinking about it now, I don't know if scoping these constants will always be beneficial - what happens when you load the VI outside the project? You can also argue that the sybVI method can be more readable because it allows you to use a glyph to describe the constant (but that can go either way per developer).

The argument you can, from the standpoint of compiler optimization, could be awesome, but I never really considered it from that angle.

Either way, I kudos'd the idea because I agree that the feature needs a refresh to unlock some valuable potential.

I was pondering the latter option and wondered if that VLC would be able to pull enough information via the HWND to know what boundaries to draw to. I need to stop thinking about this before I start trying things...

Writing ActiveX Controls if there are other solutions is only for real masochists . Go the DLL path, that gives you a lot more control in the debugging process, avoids an entire level of obscure Windows 3.1 imposed limitations, and a few more levels of intermediate bullshit, and last but not least if done with a little planning in mind, you can port it to every single platform that LabVIEW and VLC support without to much effort.

No doubt On the DLL interface, what is the rendering interface? The nicety of the ActiveX control is that it gives you a bounded space on your front panel for display. I haven't seen this sort of thing with other DLLs.

That's fairly common in the pacific northwest area. I assumed it was a nation-wide trend. I take it your neck of the woods is different?

Anyhoo, the one immutable and unrevokable law regarding any public policy is the law of unintended consequences. What sounds like a good idea today will be identified as the root cause of some crisis 20 years from now.

Indeed. We have trash pickup and recycles pickup and trimmings pickup at home, but public trash facilities are always a combination bin. I haven't actually been to the northwest, but I've been number of places along the eastern seaboard, some in California, and places in-between and I haven't seen anything like that. Large metropolises like LA, Chicago, and NYC would be critical to accept this kind of policy and, as far as I know, none of them have really tried.

America benefits from having significantly more surface area than European countries, which is probably why our oversea friends are much more concerned with what they do with their waste products. Us, we can just dig a hole out in the countryside and bury it, and we do that a lot. Our population is still growing rapidly, but I think it will be a while before we really start to suffer the consequences of this.

Since I need to create a task for each device, are there any ideas on how to implement this in perhaps a "For Loop" and create an identical task for each connected device?

I think you've kind of spelled it out right there. Since it's a task, you'll have to create global virtual channels configured how you like (but it sounds like you already do) and then use a Create Task node inside a loop which indexes off an array of those channels.

If you want it to work with VLC, just download the source code and rewrite it to work with LabVIEW ;-)

It can be tough enough to debug an ActiveX control that's already written ... I wonder how painful it is to debug writing one yourself?

How about something like this...

http://www.robotshop...tm_campaign=jos

Very cool! Way too slow for what I'm doing, but I'll keep it in mind, thanks for sharing.

So yes, if you're following that's a software-based trigger with no hardware-based data buffer and is pretty much how you should never do data acquisition. However 5 ms is a very long time for a computer and it does work remarkably well considering there's no determinism built into any of it.

Yowza. May God have mercy on your soul. I have to give you kudos for adversity in the face of extreme pessimism, however. I would have just buried a PCI FPGA card in the PC and called it a day

I'm not sure why that's not working for you. You should probably post your VI, just for clarity.

An alternative, though not as "correct" of a solution, would be to have a parallel loop constantly reading as much data as possible (if you can get that to work) and then dumping it onto a queue which is processed by another loop. The consumer loop would have to be able to figure out where packet boundaries are and I don't know how tenuous that would be for your application. If you wanted to add complexity, you could package the UDP data with a boolean that lets the producer hint at whether it's a packet boundary or not.

Are you routing the error 113 back into the read node? The majority of LabVIEW nodes do not perform any significant function if there's an incoming error.

I had totally forgotten the VLC even had an ActiveX control. With both v1 and v2, LabVIEW 2011 SP1 crashes without a word.

I think the ActiveX component of VLC is all but a legacy component at this point, based on some of the documentation I read on the VLC site. Still, it would be very cool to embed VLC in a VI.

I suspect you might be getting a *warning* that there is more data than you read, but an error does not make sense, as ned said.