Omar Mussa

I know there are many of us using Parallels on this forum.  I recently had a VM go into a blue screen of death spiral and it forced me to find a feature that I didn't know existed.

 

ProTip: If you right click on a Stopped (must be shutdown, not suspended!) .pvm file, you can select "Open With --> Parallels Mounter.app" and it will mount the drive on your Mac.  You can copy/manage files on or off the drive without starting the VM.

 

I think this will save me loads of time in the future, and I hope this helps someone else as well

I think this is a repost for me but I'll just re-raise that on some of my VMs, ctrl+shift still works, but on others it doesn't - I have no idea why.  I tried comparing settings and low level settings to no avail.

 

I'm running OSX 10.10.1, Parallels 10.1.1, Win7 x64 VMs running LabVIEW 32-bit.

Are you compiling it locally or via Cloud Compile?  I had that happen a few weeks ago - switched to local compile - for whatever reason it 'worked' then I switched back to Cloud Compile and it continued to work - no idea why - the code if anything is more complex than it was at that point and I'm no longer having issues (no matter where I compile).

Sounds like a very good application for LabVIEW.

Here's a simple example of implementing this.

foldermonitor.PNG

 

BTW - the problem with doing the array checking for this operation is that it can become a pretty big performance hit to poll the folder and list all files and search for all changes, especially if the number of files grows large.  Plus, you may need other features (like file removed or file updated) and you end up with more and more trouble when you try to recreate that functionality.  I think the .NET solution is the best long run solution for this problem (as long as you're on a Windows platform).

I didn't look at Ton's attachment but I have done this in the past using a .NET System Filewatcher Object and registering a callback VI for when the .NET event fires.  It works pretty well, the only challenge was that the callback was called in a LabVIEW context that you can't debug directly.

Hi Omar. Thanks for your response - yes I read your presentation thoroughly!

 

I have tried previously adjusting the service's rights to interact with the desktop but it was still no go. I can only think that some other policy is blocking my ability to do this. Given we have a VLA and are checking out development licenses from the server rather than a local license I had wondered whether it was this activity that was being blocked in this scenario.

 

I didn't use the VLA with my CI Servers so that could be the issue.  If any dialog was blocking the execution, then you're basically stuck if LabVIEW is running as a service with no UI.

 

I have ended up running the TeamCity agent as an application rather than a service; things work fine this way. It's not ideal but would welcome any other ideas.

 

PS. Any idea when VI Tester will be updated to LV2012++? Nudge, nudge!   

 

 

Re: VI Tester, check out the LabVIEW Tools Network - you might find a nice surprise

I presented on this topic and it was posted here:

http://blog.jki.net/news/niweek-2012-fire-and-forget-bulletproof-builds-using-continuous-integration-with-labview-video-slides-now-available/

 

You can debug a windows service by making the UI visible and seeing what is blocking the app from running this way:

administrative tools -> services -> right click -> goto properties -> under Log On tab check allow to interact with desktop

 

That should help.

LabVIEW 2013 has a subtle feature that I recently 'discovered' that has made debugging reentrant VIs so much better.  Basically you can now browse for re-entrant clones (or for the re-entrant master/original) from the Tools-->View Menu.

 

 

Greg,

 

I'll be at the CLA summit and have been using Git and would like to chat with you about how you're using GitFlow ...  I plan to use GitFlow on my next project which is starting soon.  Would like to try to sync up there.

 

Thanks in advance!

I haven't tried with TestStand but basically my approach would be to try to use the TestStand command line API to do any integration tasks.  However, I'm not 100% sure what is exposed via the command line for TestStand.

I found a solution that works for me (running Parallels 9).  Here are the video settings that 'fixed' the problem (I'm not sure exactly which setting but I think it was disabling 3d acceleration that did it ...):

 

 

I hope this helps someone out there.

I have one more data point to report ...

 

Running from the same Mac OSX 10.9 and Parallels 9, I have two Win 7 x64 VMs.  One of them I built recently and another I built a long time ago.  The older VM allows the CTRL+SHIFT shortcuts (tested with CTRL+SHIFT+E) but the new one does not.  The older VM is running LV 2011 and I did not update parallels tools.  The old VM was running Parallels Tools 7.0.15004 when it was working.  I took a snapshot and then upgraded parallels tools to latest version.  After upgrading to latest Parallels Tools CTRL+SHIFT+E still works.

 

Note that Justin mentioned that in LV2011 on his VM CTRL+SHIFT+E did not work - so there must be some VM or Windows setting that is affecting LabVIEW but its really not obvious to me what the difference is between my two VMs.

For some reason, I get really small tools glyphs on a new VM I just created running on Parallels 9 with Win 7 Pro on a Mac with Retina display.  Never seen this issue before and am wondering if anyone else has seen it and/or knows of a display setting that will fix it

 

FWIW - I just created a new Parallels VM and am running LV 2013 (32-bit) on a Win7 x64 machine and I have the exact same problem.  Its a real pain and the only workaround is manually remapping shortcuts which really sucks - I remapped CTRL+SHIFT+E and CTRL+SHIFT+W immediately - the other three key combos aren't so critical to me ...

Congratulations and good luck with your new role! You've made really great contributions to both LabVIEW and the LabVIEW Community that will have a long lasting impact.

I really got to get out more, what else am I missing???

Maybe you should check out my presentation slides (both of theses were in the presentation):

http://blog.jki.net/events/niweek-2011-five-clever-debugging-techniques-slides-and-code-now-available/

Option 3 (not shown) - Create a DVR reference and place that inside the lvclass private data. This means that you can't access the private data of the class without dereferencing the DVR. It also means that the public API never exposes the DVR.

I use this option frequently and it seems to scale well in that I still have dynamic dispatching but my data is byRef due to the DVR.

(Note - from cross post on ni.com but since these issues keep coming up I re-posted here)

Just to point out a couple of OpenG feature that are highly overlooked:

• The source code is available, so it is possible to test OpenG libraries during the LabVIEW beta periods and prevent bugs from LabVIEW upgrades from getting their way into the OpenG libraries.
  
• OpenG library functions are all unit tested and the unit tests are also open source, so it is possible for anyone to both test and improve the quality of OpenG libraries by running/creating unit tests. The unit tests for OpenG have been one of the primary mechanisms for ensuring that the quality of OpenG code is really high. For example, the unit tests for the OpenG array library can be found here:http://opengtoolkit.svn.sourceforge.net/viewvc/opengtoolkit/trunk/array/tests/?s ortby=date
  

Note that the unit tests predate both JKI VI Tester and the NI Unit Test Framework, so the tests themselves are just VIs that have a pass/fail status (update: but there are plans to update them to utilize an existing unit test framework). Hopefully this helps anyone who cares about the quality of OpenG code (both developers including OpenG in their source and developers receiving code that depends on OpenG).

Also, the example code included a VI Package Configuration file (used by VIPM) that is used to download and install the specific OpenG libraries that the example depends on from the LabVIEW Tools Network, and instructions on how to apply the VI Package Configuration file. I personally don't see what additional transparency needs to exist in terms of notifying people what the example code depends on.

It would be worth asking whether the CLA graders would accept a VI that says, "Download standard toolkit XYZ from location MNO and instantiate the following template, then put that subVI here." ... and similar comments. Any of the tools like LapDog, or AMC, or ReX, or the Actor Framework, or the GOOP Toolkit might be usable then. After all, that's exactly the instructions I would give to a developer in some of these cases.

I would be happy with the following change - any free for commercial use code (i.e. free, not just trial mode) software that can be downloaded from the LabVIEW Tools Network should be allowed in the CLA exam. It is really frustrating to experienced developers when they can't use their standard tool-set (and one that is ultimately managed by NI) on the CLA exam. It definitely takes critical time away from creating an architecture when you are compelled to recreate architecture components (or even their interfaces) from scratch, especially when you already use them every day.

Embeds are an interesting idea, but I haven't convinced myself they're a *good* idea.

I agree. I saw this product called Flowstone recently (don't take this as any kind of endorsement) ... and it looks like they 'embed' sub-nodes (they don't have VIs of course ). At around the 6:40 mark of this

, it shows the sub-node embedded in the main app node. Its pretty interesting in that you can 'reuse' a subcomponents UI but at the same time customize it - similar to subpanelling a VI in LabVIEW only you can edit the position of subpanelled controls and indicators at edit time. Anyways, it looks interesting conceptually.

Great job Jon! I think its really an awesome achievement and will help lower the barrier for other LV Community members contributing to OpenG! Thanks for all your hard work on this endeavor!

One minor wish--I use the project dependencies folder a lot. Is it possible to wrap all those dependencies in a library?

Wow, I didn't know that you could use the dependencies folder for something useful. I use it only as a sort of garbage collector of things that I don't care about that happen to be in my project (I thought that was all it could do). How do you use the dependencies folder?

(Also - yes I can look into wrapping all dependencies in a library).

Understanding the benefits of unit testing is one thing--experiencing the benefits of unit testing is a whole 'nother feeling.

Even internally at JKI, every few months someone says "wow, unit testing really saved me on xyz". I'm glad that you're getting some value out of your time investment!

Thank you JKI!

Thank you too! Keep on feeding us suggestions on how to improve VI Tester as well, we're definitely listening

Your API is great, I just tried using it out and was impressed!

I have some feature requests that I think would make it even better (and these requests depend on the .NET API)"

1. If the clicked events could specify whether there was a right-mouse vs left-mouse click on a given menu/tray/balloon tip
2. If the balloon tip clicked event returned the balloon tip text

Thanks for your contribution to the community!