Fab

Make sure you check the warnings list if any when opening your VIs for the first time in 2010. They will indicate if any subVIs have been deprecated or any other changes LabVIEW does automatically to your code.

Here is my entry. I will try to find time to improve it and add color, but I thought I would put it out there in case someone wants to use it as inspiration and improve it. Fab PS: I can't wait for NI Week

It worked but now it turns that either we have access to the Block Diagram or access to the custom run-time menus, but not both. This also got me thinking that the block diagram should open automatically, I posted an idea for that: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Automatically-open-block-diagram-when-debugging-an-application/idi-p/1574278 with a video of how it works now. At least I can do some debugging now. Fab

I didn't think this would do it, but after reading this post: http://lavag.org/top...ared-libraries/ I tried building an installer instead of copying the executable and now I can connect without Windows complaining

Thanks SuperS, Normally I have more luck here than at NI's forums I did try with a simple executable that only adds two numbers and I was able to connect to it and I was able to debug the block diagram and run highlighted execution. I wanted to see if anyone else had tried debugging a remote application and had the same problem. Maybe they could give me ideas on what could be preventing me from connecting to this particular application. Unfortunately, I did not write the code and I am not very familiar with the application. But it someone went like "I remember this happening to me when I was trying to X", maybe I could look for X on this app. Thanks for your time, Fab

I tried setting the top level VI to not RUN when opened. But if I do that I can not see the application listed, even after clicking on the run arrow. Has anybody else had problems debugging remote applications?

I built a stand alone application using LabVIEW 2010. I enabled debugging. This application is running in a Windows XP computer that only has the LabVIEW Run Time Engine. In a separate computer that does have LabVIEW 2010, I click on the menu Operate>>Debug Application or Shared Library. I entered the IP address of the computer where the exe is running and I am able to click connect. In the status window I start to see how all the VIs get downloaded. As soon as the front panel shows up in this computer, the computer running the executable displays one of those "lovely" Windows indicating that my application "has encountered a problem and needs to close. We are sorry for the inconvenience." And then proceed to ask me to send the error report to Microsoft. I can consistently reproduce this behavior. Every time I want to connect to the executable, I get the error window on the computer running the executable as soon as the remote computer loads the front panel. Any ideas? It would be nice if I didn't have to find bugs on the tools I am using to debug an application that has its own bugs... oh well... Thanks, Fab

Try this one: http://zone.ni.com/wv/app/doc/p/id/wv-2695 This was the virtual users group meeting presented on May, 11, 2011

Daklu, I am sorry you didn't pass, but I agree that you should call NI, if not to challenge the results, at least to provide feedback on the test. You are one of the most experienced LV people and NI is missing a lot by not having you as a CLA. It is very discouraging when someone with your background does not pass the test and it explains why for some customers my certification is not enough. They want to see my code. I guess they have been burned many times by hiring people who have the certification but do not have the knowledge/experience to back it up.

NI rewrote their LVOOP course. It is no longer the one written by Mike. I haven't had the chance to teach the new material yet. They focus more now on native classes, I heard good things about the course from the students perspective. Cat, You'll be fine, no worries. It would be a lot easier in LabVIEW, but you have conquered bigger beasts than this one Fab

Can you post the code you are using? The suggestions we can give you will depend on the approach you are currently taking. I am going to guess that you are using the "Write To Spreadsheet File.vi" in the File I/O palette. I strongly suggest you don't use that inside a while loop. If you open the multiple VIs inside this VI you will see that you are opening and closing the file every time. You can go to the lowest level subVI (Write Spreadsheet String.vi), copy that and use that as a starting point, leaving the opening and closing outside your while loop. You will see that there is a "Set File Position" function that it is set to go to the end of the file when the append to file is set to true. You could do some calculations based on your file size and the size of your last line to set the file position to always be the last line so it gets overwritten every time. Good luck, Fab

I agree with Justin, this whole issue is just a reflection that the event structure is more of a "black box" than we thought. A very dark black box . If there was a way to "probe" for an event structure we could "see" when an event that has been registered for and it is not being handle "fires" and resets the timer. Which seems to be one of the ideas tossed around inside NI: I don't think we necessarily need to break future VIs, because as it has been discussed before, there might be someone out there than in these 9.5 years might be taking advantage of this "feature". So, I vote for "updating the documentation", "doing something special during Execution Highlighting to show that the event fired but nothing happened" and the one that I just mentioned about having a way to probe the event queue. I agree with jgcode that we need to vote the good ideas regarding this up. I did a quick search in the Idea Exchange and I couldn't find an idea regarding being able to configure timers for an event structure. jgcode, have you added that idea? if so where, I would like to vote for it. Well those were my 2 pesos I hope I see you all at next year's CLA Summit. Fab

In case anyone else things this should be possible, please vote, there is an idea for that: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Obtain-the-IP-address-from-the-Application-Reference/idi-p/1491780 Fab

Tomi, I am trying to do something similar. Did you ever find out if there was a way to get the IP Address from the "application reference"? Thanks, Fab

Check the "Graphics & Sounds" palette.

Tushar, I thought more about this and if you want the same as when "we drag a png file from explorer and drop it to empty area on front panel." Then a picture control would do the trick, you would only need to adjust the picture size to the image size. (I am not attaching a snippet this time, because it removes the direct reference to the picture control, but you can download the attached VI) I hope this helps. The tool your are building sounds really cool, please let us know when is ready set-backgroundORpicture.vi

I use the VIs in the "Graphics & Sounds>>Graphic Formats" palette, there are VIs to read png, jpeg and bmp. That combined with what crelf posted earlier results in the following snippet for LV2010 (snippets remove the direct link to the pane for the property node) Fab

In case someone else needs to customize the needles on their LabVIEW Gauges, Dials, Knobs, etc... and the above solution is not enough, then "There is an IDEA for that": http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Custom-Meter-Gauge-Needles/idi-p/1006643

Christina, Do you think I should post it in the Idea forum? I don't think we are going to get too much support, because this is one of those properties that are not widely known... but one never knows Thanks for your post. I hope everything is going well with you Fab

I found this post from Christina: http://www.eyesonvis.com/blog/2007/03/labview-ui-trick-panel-wallpaper.html and I added an image as a background on my VI. The problem is that now when I use the property method for the VI "Print.Panel To Printer" I get a gray square instead of the image I had set as my background. Is there a way to make the background print? Thanks, Fab My workaround is to have the image as background and then add the same image to the front panel. Then programmatically I make it visible only for printing and then invisible again so it does not get in the way when I am editing my front panel. But it would be nice not to have all that extra code. Thanks, Fab

Now that several months have gone by, how do you feel about Mercurial? I use Fogbugz too and I just went to their Fogbugz and Kiln world tour and the link between Fogbugz, Kiln and Mercurial seemed very promising. But since LabVIEW handles binary files I don't know how useful it is going to be. I have been using TortoiseSVN and I gave up long time ago on branches and merges. It was a nightmare, the Fogcreek guys made it sound like in Mercurial this was not an issue and they use TortoiseHg, which would make the transition easy. I will just need to remember that there is an extra layer involved and push/pull needs to be done besides the commit/update. They also mentioned a tool that converts a SVN repository into a Hg repository. Anyway, before going on this "adventure", I wanted to make sure I asked you guys how it has been working for you. Should I stay on SVN? or jump on Mercurial? Thanks, Fab

cross posted from: http://forums.ni.com...uireLogin=False Hi, I figured there would be more people using Execution Trace Toolkit in this group than in the general LabVIEW community forum in the dark side . I have been using Desktop Execution Trace Toolkit 2009 to debug an application. We have been able to locate most of the reference leaks and fixed them. However, there is a reference leak that when I double click on the Execution Trace Toolkit line points to an Unbundle by name The other times I got a reference leak, it would point to a place where a reference would actually get created such as Obtain Queue, Obtain Semaphore, etc. Any idea why it is pointing to an Unbundle by name function?, also the event details are "VI: 0xD8300076", but I can not find that reference anywhere else in the trace report. Thanks, Fab

Yair, Thanks, that makes sense. Now I need to see why when called inside the big application the FGV goes out of memory. Fab

This sounded exactly like the problem I am having, unfortunately the solution mentioned above does not help me, the semaphore is being initialized While running "Desktop Execution Trace Toolkit" in the code I am debugging, I realized that the semaphores used inside a FGV were returning error 1 after trying to acquire a semaphore and error 1111 after trying to release it. I simplified the code to the bare bones to see if I could reproduce this problem. Here is the odd behavior: If I run the FGV with the single enum enabled and I run first "init" and then "acquire-release", I get "Error 1 occurred at Dequeue Element in Acquire Semaphore.vi" If I enable the other case in the disable structure (an array of init, acquire-release, destroy) and single step through the code with highlighted execution there are no errors. This might be basic knowledge regarding semaphores, but I don't understand why if the semaphore refnum is saved in the shift register, it is no longer valid the next time the VI is ran. Please help me understand if this is valid behavior. Thanks, Fab

Congratulations! Well deserved, I have learned so much from your posts Fab