Omar Mussa

Hi Tomi, I'd be happy to write an article on using SCC and LVOOP for your blog, we can work that out offline. QUOTE(Tomi Maila @ Apr 24 2007, 09:55 AM) 1) Yes, you have to be careful when renaming a file and using SCC. I'm using SVN so I use SVN Rename (which basically drops the old file and adds the new file to the repository). I'm not using SCC integration with LabVIEW - I use SVN outside of LabVIEW via TortoiseSVN in Explorer. 2) LVOOP does recompile the whole project on occasion. I just check in everything at that point and add a comment to the commit so that I know what happened. Its better to commit often and be able to revert later than not commit and then get stuck! The only cost is disk space, which is cheap relative to time spent programming! Omar

I just finished the first phase of a project where I'm using 15 different LVOOP classes and I thought I'd share some of what I learned. I've been using LV 8.20 and NOT upgraded to LV 8.2.1 yet, so hopefully Tomi has helped AQ figure out most of the issues that have come up for me - in fact I don't intend to write about the bugs in LVOOP here at all. (I do plan on upgrading to 8.2.1 right away to see what happens now that I've reached my milestone.) Here are five things that you should consider when starting a LVOOP project (not necessarily in order of importance). 1) Source Code Control Don't even THINK about starting a LVOOP project without it. Unlike in LabVIEW where it is possible (albeit risky) to plug along and not think about SCC too much, it is ESSENTIAL for LVOOP because it is possible for classes to get corrupted and without SCC, you're screwed because you can't do anything to the class file directly. Hopefully 8.2.1 fixes many of the issues that cause corruptions, but at the core, I firmly stand by the statement that if you don't have an SCC process in place, don't use LVOOP. 2) Project Environment I'm not a huge fan of the LV Project environment but you need to get familiar with it if you start working with LVOOP. The biggest challenge right now with the project environment is that it becomes very difficult to organize and find VIs in the hierarchy window (there isn't any support for sorting VIs in the project by name, etc). To get around this, it is best to create a VI Tree for each LVOOP class so that you can easily organize the members in a way that makes sense to you. 3) Context sensitivity One thing to keep in mind, class VIs are loaded into memory differently depending on the context in which you load them. For example, if you start from just LV being open and launch a class member VI, the entire class will be loaded into memory. If you then open a .lvproj file containing the class, you will find the class is locked because it is open in 2 contexts. I recommend creating a VI Tree that contains all of your class VI Trees so that you can open everything in your project in one context outside of the .lvproj in case your .lvproj gets corrupted. 4) Don't use dynamic dispatching on every VI Dynamic dispatching is great, but at the price (for 8.20 at least) of not being able to find your VIs using the 'Find all instances'. So, instead of making every VI in your class dynamically dispatched, use it judiciously in places where you truly want to have over-ridable functions. Where you don't intend to over-ride the function, make the class connection 'Required'. You can always change the connection to 'Dynamic Dispatching' if you decide to over-ride the function later. 5) Be prepared to iterate The one thing I found I had to iterate on the most was abstracting class data from child classes and putting the code into the parent class. Sometimes, even with careful design, you'll find patterns emerging as you develop. If you keep in mind that one good goal is to minimize the amount of code you create, you'll find that you need to move 'generic' functions into parent classes. Remember that a child function that over-rides the parent can call the parent function - so utilize that behavior to reduce duplication of code and then extend that functionality in the child class - or, if a very special implementation is required, skip calling the parent method - whatever option keeps the code tighter and easier to understand. Finally Understand OOP concepts Don't dive in and assume you'll figure it out. Get some OOP books and check out the shipping examples and blogs like Tomi's Expressionflow. Try to create a scale model of your project before implementing details.

Plus, with exchange rates being what they are... its like you'll be doubling down! (1 GBP = $2!!!)

Search LabVIEW Help for Excel, there's a shipping example for this exact problem (Write Table to XL.vi).

Thanks Yen, that's just what I was looking for. :thumbup: For now, I'm going to probably do nothing except for report it to NI.

A customer of mine who is VERY thorough in their testing brought an issue to me that I haven't come across yet and I thought maybe someone else has seen this... If you build an application with a timestamp control that has the date browse visible button, and the user presses the button, they see the following screen. If they press 'Help' - because they really don't understand a calendar control (?) - then basically nothing happens. http://forums.lavag.org/index.php?act=attach&type=post&id=5427 Is there a way to get the LabVIEW Help to appear OR to somehow customize that dialog so that the help is invisible? I'm using LV 8.20 for this app.

There is a setting in LabVIEW that may be useful for you - I'm not positive but am fairly sure this will work for you. You'll also need to follow Ben's advice and keep a 'Default' case for each case structure VI that uses the enum otherwise the VI will break. In the LabVIEW options menu select 'Environment' (LV 8.2 - I think its in a similar place for earlier versions but may not be exactly the same place) Check 'Treat read-only VIs as locked' and then check 'Do not save automatic changes'. This can help reduce the number of *s you see a lot. Then, what you can do is use LV integrated source code control or just manually set all of your VIs to read only. At that point, whenever you change a VI, you will manually set that VI to 'read-write', save the change, then set the VI to 'read only' (if you are using LabVIEW's integrated scc, checking in/out a VI will change its read-write property automatically) . While its a small pain, all of the VIs you are not working with will not get a *.

Hi Jason, My use case for the Mixed Signal Graph was not the one NI (you) intended it to be. I wanted to have a nice, elegant looking way to display database historical data from a data logging system and wanted to have multiple graphs share a common X axis so that the user could easily scroll through time (x-axis) for several plots that were not time aligned. The MSG was a useful tool in this regard but it took a LOT longer than I expected to figure out the workarounds to the issues I ran into. QUOTE(JasonKing @ Mar 9 2007, 12:06 PM) Well - I'd agree except that figuring out the workarounds was about 2 days of work and that is not what I expected going in - I really was 90% done in a few hours but the last 10% was almost impossible and I definitely had to cut back some of the original 'features' due to these issues. In particular, it was really disconcerting to watch a plot disappear from the plot legend when I changed the active Y-Axis to a different plot. That made the whole drag/drop part that is nicely integrated into the tree useless to me. Also, I wanted the user to be able to see 1-3 plots depending on how the user wanted to look at their data - it took a long time to figure out an effective way to resize the plot areas because doing that would resize the plot bounds which distorted the graph and the entire scene. I also spent a long time getting the axes to remain visible/invisible based on what the user wanted to see. These were things that were cosmetic, but very important to my application. I think the two following statements reflect a wider sentiment between NI and the LabVIEW development community (especially professionals). QUOTE(JasonKing @ Mar 9 2007, 12:06 PM) I've often wondered why I didn't hear much about people using the MSG. Is it too buggy? J QUOTE(tcplomp @ Mar 9 2007, 03:19 PM) Somehow I don't get it, as a developer I need the properties and methods alike the developer experiences the control. And for the MSG this is just not provided. Developers who are building custom applications need access to properties/methods to make the controls integrate with their applications. While its great for demo purposes to be able to whip out a graph that shows mixed signal DAQ data in a few minutes without getting too customized, the best professional apps tend to do a LOT of UI work to make the application meet or EXCEED the user expectations - this translates into developers wanting properties/methods to enable us to do that. The MSG is an example of a graph whose best features have no API or at best an obscure one that is not well conveyed - so most users will go to great lengths to integrate a different graph (like the XY graph) with a richer API so that they can get the desired user experience. (In fact, the NI App Engineer I worked with was actually steering me away from the MSG because he thought it would be better for me to create 3 XY graph controls then to use 1 MSG with 3 plot areas...)

You should probably take a look at NI TestStand as it is a framework that can handle parallel testing and a lot of generic UUT framework (loading parameters, storing results, reporting, etc) - you could then write the 'Tests' in LabVIEW. You'll need to figure out how you can define 'Tests' that fit into TestStand's framework and meet you application requirements.

I'm trying to spawn an asynchronous process that uses my LVOOP object (I'm actually using a Reference object from Tomi's example). I have an object that is a control on the asynch process VI and when I try to set its control value (using control references), I always get error 91. I've tried it using VI.SetControlValue method using Variant and Flattened String modes. Is there another way to do this? Thanks in advance.

After experimenting a lot with the Mixed Signal Graph as part of my ill planned "challenge", I've found out why I hit so many issues. Here's a list of CARS generated as part of my excercise... CAR ID: 45UEA5X6 If you change a plot's scale programatically (using the ActiveYScale property) to a scale in a different plot area, the plot disappears from the plot legend CAR ID: 46M8DBX6 If you set the Plot Legend to invisible and then 'Add Plot Area', the plot legend is visible for the new plot area. CAR ID: 3L2FE3CM (may be tied to all LV objects, not sure, also this one already existed but is related to an issue I had) If set the MSG 'Fit To Pane' and set the graph to scale object with pane, when you resize the pane the plot areas do not stay visible proportional to the pane size. (It is especially bad scaling down to smaller sizes - if you do this and then scale it back up a few times you will see the graph look very bad quickly). Additionally, I requested two additional features (which means nothing in a lot of ways...) - 1) you should be able to Add and Remove Plot Areas via invoke nodes. 2) the plot bounds and plot area are overly coupled which means it becomes very difficult to resize the MSG without very poor results. Thanks to everyone who helped me plow through my first (and possibly last) use of the Mixed Signal Graph.

I'm trying to do this now (read a DWG or DXF File - ideally a DWG File) and have been unable to find any useful file readers for LabVIEW. The only thing I was able to find was Jack Hamilton's HGPL Parser in the Odds and Ends category. Has anybody done this before? Thanks in advance!

QUOTE(xtaldaz @ Mar 2 2007, 12:46 PM) It is really important to use good error handling techniques as well to trap exceptions. For example, if your connection is open for a long time without any activity, the database server will generally close the connection. So, if this app will run for a long time, you'll need to check that the connection is alive (and potentially repoen the connection) whenever you do a query.

Well, after much troubleshooting I've figured out that basically the reason I can't get this to work is because there are some LabVIEW bugs when scaling the Mixed Signal Graph that cause serious grief. I'm in the process of reporting the bugs to NI and have been working with an AE. When I get the CARS will post them here. I'll still promise a pitcher of beer to share at Gingerman with whoever wants to comisserate over the issues of scaling a panel in LabVIEW! The Mixed Signal Graph is so, so close to being useful for me.... In the end, I've basically avoided the problem I'm having by disabling the user ability to resize the window, which means they better like the size of the graphs, because that's what they'll be stuck with. Believe me, this post started as a desperate cry for help and is basically ending as a desperate cry for NI to make panel resizing easier! Will be posting a few 'feature requests' too through NIs forum...

There are third party tools you can buy off the shelf that make it fairly easy to implement time expirations and other feature locks. The easiest way to do this is to Google "software copy protection" and you'll find a lot of tools. I've used some software by Crypto - I've not been terribly impressed by it but it is the reason I know such software exists. Most likely, the tool will come in the form of a dll.

I could use some expert advice. I'm trying to use the Mixed Signal Graph so that I can have a versatile way of resizing multiple plots at once and having multiple plots on the same x scale. I'm running into trouble making this work so I thought I'd show off what I've got. One pitcher of beer at the Gingerman during NI Week to whoever finds the solution to this challenge first (I figure we might as well keep this trend going! :thumbup: ). Here's the challenge: Use a Mixed Signal Graph (MSG) with 3 Plot Areas. The MSG must be on its own pane. If the user selects to show a plot in Plot Area 3, show all 3 Plot Areas. If the user selects to show a plot in Plot Area 2 (and none in Plot Area 3) then show 2 plot areas. Else show 1 Plot Area. The Plot Areas must be scaled to fit the pane in an optimal way (ie, they must take up as much space as possible (1, 1/2 or 1/3 or the pane depending on the number of plots shown). As the user changes the window size (pane size), the plot areas must scale proportionally (ie, additional plots should NOT be seen and the plot should not shrink to a dot). The plot areas should not require a Y Scrollbar at any time. (X scrollbar is fine). I've attached a VI to use as a starting point (the VI is in 8.20 - the MSG was started in 8.0) - unzip to a folder and open 'Mixed Signal LAVA Challenge.vi'. Here's a screenshot of the VI so you can see what I mean: Download File:post-5746-1170919766.zip

If I try to move a plot programatically from one plot area to another by changing the plots Yscale, the plot disappears from the legend completely. There seems to be no way to bring the plot back onto the legend either ( - 'sometimes' it comes back if you switch the plots and toggle the axis visible status - ). CAR ID 45UEA5X6 Download File:post-5746-1170284256.vi

I am trying to use the mixed signal graph because it seems like a great fit for my application but I'm running into issues. I want to have several stacked plots that share a common X axis and it seems like a good way to handle this problem. Aside from not being able to rename the 'Group' (Mixed Signal Graph Legend - Programmatic Plot Goup Label) I'm also having issues with the plot legend. If I create more than one plot area and I programatically assign a plot to an area other than the first area (via the YScaleIndex), the plot disappears completely from the plot legend. :headbang: (I'm in the process of reporting this to NI as a bug, will post CAR when I have it). One workaround I can think of is to hide the legend and create my own. There are downsides to that namely: 1) User can't move the plot from one graph to another using drag and drop (I can live with this) 2) User can't change the plot color, point style, etc. easily (Or I have to do much more programming...). I'm thinking another workaround would be to create a regular XY Graph and move the graph off the screen keep the legend on the screen for the user to interact with - then to use its legend to write to the Mixed Signal Legend. Luckily there is a 'Plot Attribute Changed' event but this will still be tricky. Has anyone out there tried to use the Mixed Signal Graph? Maybe I'm missing something here. Suggestions of all kinds greatly appreciated.

Your best bet is to look at the 'Producer-Consumer' template or one of the other parallel loop templates that ships with LabVIEW. That will give you some ideas on how to stop the second loop. There are many ways with pluses and minuses but the templates are a good starting place.

If you're using an Event Structure, this becomes very simple. Create an event that is handled by Value change on both ring controls. Wire the NewValue terminal in the event structure to a local variable (or value property node) for both controls. This solution would rely on both rings always containing the same Strings, but that's it. If you have other events tied to the Ring Value Change events, you can write to the Value(Signaling) property node and they will execute as well.

I don't know if there's already cross posted this on LAVA, but I thought I'd mention a cool posting on NI Forums that shows how to control Google Earth from LabVIEW. I also added to the llb with a Load KML file that loads an XML file with data that Google Earth can translate into markers. http://forums.ni.com/ni/board/message?boar...mp=true#M222693

Are you sure the problem is with the subVI or is something else in your application hogging resources that the subVI uses (like hogging the cpu, etc)??

If you just have to re-initialize the controls to default, why not use the reinitialize to default method of the VI class.

While it may be better in the latest version of VISIO, as of VISIO 2000 it seemed to me like the UML aspect of VISIO was not well exposed through the ActiveX interface so it was difficult to reverse engineer (or even more ambitiously forward engineer) LabVIEW code.