shoneill

That's why I thought it sounded familiar. I'm pretty sure my problems are also linked to the separated compile code and the cache. I personally tried deleting the cache, but after making one or two edits the problem just came back. If I make it to NI Week this year and I'm bald, faulty deploys on our RT system will be the reason. I really do feel like tearing my hair out at times, it's extremely frustrating. Debugging on FPGA is a walk in the park in comparison. One topic plodding around in the back of my head: Wim, What are your locale settings? I presume, like here in Switzerland, you have a comma as a decimal separator? Maybe there's a bug somewhere where some string somewhere isn't paying attention to the system decimal point? If so I'm switching locale tomorrow.....

Do you have inlined VIs? Have you forced a full compile (Ctrl-Run)?

Ooh, this sounds familiar. I have been running into issues with very similar symptoms recently. My code is on a RT system and I have noticed extremely weird behaviour when deploying. Sometimes it will simply NOT deploy the current code from the Object cache, even if I force a recompile of the top-level VI. What I have obeserved is that if I edit some sub-VIs in a different context (a project with only one target so that objects are not locked for example), these changes do NOT get automatically detected in the original context (even after closing and opening again) The fact that my sub-VIs are inlined may or may not be relevant. I have had situations where my testbench would run a function absolutely according to spec but when deployed (Save, close Testbench project, open main project, compile, deploy) it would behave as an older version, even after forcing a recompile of the entire hierarchy. I managed to "fix" it by placing a global write in a specific sub-sub-sub.vi in the proper context. Then it compiled properly and deployed correctly. I have the feeling that some "other context" edits are getting obscured somehow int he system. But don't ask me to reproduce it, I've been trying for years. Each time I try to pare down the code to get an example running, the problem goes away. I'm running LV 2012 SP1 with separated source code.

Indeed, not wiring the instance can have some awkward side-effects. LaunchingLVCompare.exe from a SVN client for example will try to open it in the CURRENT context. Running LVCompare on an FPGA target is not something I've yet managed to get working.....

I thought of something like Teamviewer before but I'm not sure if there's any way to query the mouse pointers individually from software or not (as opposed to the OS handling two different pointers transparently).

I don't think this will work. I think Windows automatically sets all mice connected to control the same cursor. I am unaware of a way (Aside from programming USB directly) to get the information from eachindividually into LabVIEW. But hey, maybe (in fact, almost certainly) someone knows more than me.

I really don't think serendipity is the correct term for what we are talking about. We're talking about people looking to learn, not stumbling across something by accident.

Regarding the situation with information communicated under NDA or anything similar I think the vast majority of us are clear about this. Unless you happen to also be under NDA (which I am) you legally should not be a recipient of the information. End of. I don't think a discussion on this level is worth the effort. The legal aspect is relatively clear. There are at least two videos of the CLA 2015 meeting which probably fall into this category. The easiest point to address is the idea that non-CLAs will somehow not be capable of properly understanding the messages to be communicated by such videos. On a purely technical note, I don't think the level of the presentations is such that non-CLAs would have a hard a time identifying, following and understanding the true idea behind them at all. Full disclosure: I detest elitism. The argument from authority does not sit well with me. It makes one side angry and the other side blind. If the CLAs wish to pursue this route than I see dark times ahead for the community. If anything the group should probably be more transparent than any other, setting the example for others to follow. Information has no ego. With many internationally reknowned universities offering much of their courses online for free, the approach to sharing knowledge seems to be changing. It's now quite possible to watch a 17-video series on how the physiology of the brain affects our every day experinces and how these developments were evolved and what consequences they have for psychiatric disorders. For free. Do these universities worry if the people watching them can understand the information? No, they don't. Why should we?

"I prefer that the CLA presentations not be generally posted." AQ, you mean publically posted or posted in general (i.e. posted to a limited group vs posted at all)? Speaking for myself (speaking for others tends to get me into trouble) I very much enjoy the CLA videos even though I'm not even CLAD any more....

Tell me about it. I spent a few weeks last year testing different things on the 3D picture. I have previously (in college and for no other reason than pure curiosity) read books on 3D graphics (Open GL). Pretty high-level stuff, no function calls. Reading up on the current state of Open GL (I was in college when Open GL was the only 3D kid on the block! Yeah, that statement really carbon dates me!) I notice there are many many OpenGL features missing from the current LV implementation (like multipass rendering, full texturing support and so on)

I can't recall the property right now but I think it has to do with with the "blending bin" you place the text objects in. There's Opaque, Transparent and so on. Make sure you set the text objects to the correct blending bin and it should work.

I can't find anything about this in the release notes..... am I blind? Never mind, it's in the readme.txt but not in the release notes.....

Generics are also a compile time determination. This is why the suggestion is basically asking for generics. This "little smarter" is pretty much what generics have to offer. This is in contrast to LVOOP which has an unknown type (but known ancestry) at compilation. Variants (or at least their contents) are also unknown at compile time. I've yet to dabble in XNodes. While I share your desire for these advanced features, I don't want NI doing another quick hack whose negative side-effects we'll be fighting against until the end of time. Xcontrols anyone? That's a great example of a cool idea just implemented wrongly because they looked at the problem with far too narrow a view. (This is simply my personal opinion on XControls) At least for the type adaption part of your request, that's exactly what generics should solve. The others are different topics. AFAIK, Xnodes will never be made public and I'm sure NI has their reasons for that.

Well, reading that thread I have to re-quote AQ That's exactly what went through my head when reading this post on LAVA. I'm also a bit confused about generics being a thing for the far future versus his claim in this thread about it being do-able..... Surely it's one or the other or has something fundamentally changed since then? This is the part I am most confused over. Could it be that generics are soon to enter the LabVIEW world?

Eh? This seems like a weird construct to me. I'm not sure what to think of this. Makes me think of a limited set of generic datatypes.

Holler.

I downloaded from the link you provided and my LV wouldn't open it because it said it was from a newer version.....

Hrm. Code is saved in a newer version than I currently have access to. I'm assuming it's LV 2014, but I only have 2012 installed.... Looks like I need to power up a VM. That won't be happening today, but I WILL look at it when I have time. Thanks.

I'll give this a try this evening. Are there any logs generated during install which might help track down any problems which occur?

Not having another PC to test on, I really can't say if it's specific to my PC or not... I tried uninstalling and re-installing, it still does not show up in the tools menu.

No answers? Bummer.

This package isn't working for me. It doesn't show up int he Tools menu after installation and even opening the lvproj in the vi.lib folder doesn't find components it needs because it's expecting items to be in a subdirectory when they have actually been renamed. I'm using LV 2012 SP1 (32-bit) on Win7 Pro 64-bit. As an example, it's looking for a Class C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test VIs_LVTM\Test Class\Test Class.lvclass but I can only find C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test Class__LAVA_lib_LVTM.lvclass I have VIPM 2014 installed.....

User Events. Create and register for the events int he top-level VI and pass them to the parallel processes. Then you can also scale up to 3,4 or a thousand objects and they can inter-comminucate. No LVOOP required for this aspect.

I've looked at them and it seems really to be some bug or at least undocumented behaviour. The FP of one VI seems to return an offset of 1pproximately 120 pixels in the vertical. The Panel method "CvtPaneltoScreenCoordinates" suffers from the same problem (but might be an easier method to get what you want as it automatically takes into account the title bar and so on). Ah, I found something interesting: Click on the bottom right corner of the FP with scrollbars visible and choose Properties. When you exit you will see that the selection box for the panel is way off. Could it be that the origin of the pane was changed programatically and some internal state got messed up? Here's the picture

Any routine I write to insert something into a sub-panel first checks the state of the FP and if it is in an incompatible state, I change it to "hidden" before inserting. I also remember to remember the state so that when removing it I can reinstate the old setting. I generally have a few sub-VIs to do this work for me. Ps I don't close the FP because that can lead to really problematic situations where (AF aside) the VI is actually exited upon setting the FP to being closed. I have (in the past) also taken a reference (Open VI Reference) of the VI first, set the FP to close and then inserted it. Explicitly opening a reference to the VI (in the case it has been passed as a parameter instead of opening it within the sub-panel calling VI) prevents the VI from being stopped.