ak_nz

Yes, this is an interesting design problem that inevitably ends with a different answer for each developer - what percentage deviation from LSP are you comfortable with? It is a slippery slope - so be careful. And document the limitations so that the next developer to follow you understands the trade-offs you made - they might follow your example in a way you didn't expect. As the quote goes: “Code as if the next guy to maintain your code is a homicidal maniac who knows where you live.†I do this for hierarchies where a child class doesn't support a particular function - the default parent behavior is to generate an "Unsupported Operation" error. Still I personally only do this if I think the number of operations or number of classes in the hierarchy won't really increase (ie. percentage deviation from LSP is small). If I find that I have multiple levels of undo in multiple operations in a hierarchy I wonder how maintainable this codebase will be by the worst critic - another independent developer.

You can have an abstract class that implements some concrete logic. Since it is functionally irrelevant from a compiler perspective the important thing is to communicate the intent of the class to other developers. One technique I use in this scenario is to alter the class icon to a wire-frame cube (rather than a full cube) using GDS which indicates that the class is not intended to be instantiated but exists only to specify a common interface for concrete children and implement some common behavior.

You aren't really "breaking" any good-practice rules in OOP design. There is nothing inherently wrong with have common functionality in an abstract parent - as long as you are comfortable that this will always reasonably be the case for all child implementations. If you come up against scenarios where children are over-riding methods just to inhibit parent behavior then you are definitely seeing a code smell - your hierarchy is making assumptions about behavior that are not true for all children. One of the most important guidelines for OOP design is to favor composition over inheritance for exactly this reason - inheritance enforces behavior that isn't always appropriate. The guideline encourages small, focused hierarchies of classes and then using composition where needed to add functionality without impacting the hierarchy. Unfortunately OOP development in LabVIEW is cumbersome compared to other languages, so we can all be forgiven for taking a short-cut where it is simply more expedient. EDIT: If you are new to OOP development, I encourage you to read through these if you haven't already: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://javarevisited.blogspot.co.nz/2012/03/10-object-oriented-design-principles.html

All I can add to this is that QueueYueue's suggestion is exactly how I resolve similar issues in my frameworks without resorting to other class creation frameworks such as GOOP or G#. Let dynamic dispatch work it's magic on object terminals and let the root class be by-reference. The ESF has the same issue you are experiencing but it has that nifty class creation utility to hide the busy work.

We pretty much use the VI from that thread. I've attached our copy (LV2012 onwards). I can't say much about Bamboo, but when we use TeamCity it is looking for tokens in the stream that indicate specific messages. That's how we transmit status messages (progress) as well as unit test results etc. I do recall having issues executing a batch file and then receiving messages though - currently we execute scripts manually in TeamCity (ie. it opens a command window and then feeds each line as StdIn). Perhaps this is related to your issue? Write to Console Standard Out.vi

If you don't have the option of extracting information form the output stream with your Bamboo thingy-a-bob then this would be your best option.

We do the same thing - since the command output stream is already hooked back to TeamCity we don't need any content in the result log file - it's presence (or not) indicates whether the LabVIEW process finished successfully or not.

Before we had a dedicated build agent PC (well virtual machine, but you get the gist) I actually used my development machine as a build server and scheduled the hours the the agent was available for (typically break times, outside work hours, times I knew it didn't need LabVIEW etc.). Not quite as useful as a dedicated machine but it was able to take advantage of the same license. I could enable or disable the agent when I needed control of LabVIEW back to get some actual work done, and then relinquish it back to the build agent when I was done. Build agents are independent of the build server with TeamCity so if my development machine was unavailable the build server would try and locate another available agent. The biggest issue we faced was the automation of the LabVIEW IDE. We went through several hoops to make sure that we could shut-down the IDE normally when a "build" was finished. If only LabVIEW, ironically, had a command-line version

We built a basic utility we inventively called "GBuild" that is run via command-line when starting LabVIEW. GBuild parses LabVIEW command line arguments (ignoring itself) to determine what project to open, whether to mass compile or clear the compiled object cache, what number to version a build (e.g.with reference to source control version), what unit tests to run (by unit test framework provider, we occasionally use more than one), what VI Analyzer configuration file to use (if required) and then what build specification to execute. We use the command output stream to feed information back to the CI runner (progress, unit test results etc.), which in our case happens to be TeamCity. The actual TeamCity build agent in our case is a virtual machine with the development environment elsewhere on the network. As part of the pre-build process TeamCity automatically checks the source out of source control prior to starting GBuild. This works quite well, even in some scenarios where we "chain" builds (one build is dependent on the previous). The only issue we have had is where we use .NET assemblies as part of a project that is being built - if the .NET assembly version has changed then we have had to add a programmatic "Save All" to avoid LabVIEW hanging at exit with a prompt to save changes (since there is no actual user).

That's very useful to know, thanks!

Personally I have no problem with the term subVI. In our business we understand that the term refers to a caller-callee relationship - often we say "PleaseDoThis.vi calls DoThis.vi as a subVI" to indicate that more clearly.

I typically have a post-build action that can update the ini file with the appropriate keys. Having written an application with over 20 asynchronous processes running long-time .NET calls it comes in handy. On occasion I have had to create a "wrapper" VI that launches the common SubVI(s) in a specific execution system so that I can share the load appropriately. The SubVI(s) are obviously configured same as caller.

You could certainly use the basic incrementing number solution. Often I need to serialize my objects to disk and back so I tend to go straight to the less KISS approach so that each object really is unique.

By-value objects are just data so there is no unique identifier for them that already exists - you will have to create one yourself. You could create a GUID as an object property. They are unique "enough" that they are used through-out the Windows infrastructure. The .NET static method Guid.NewGuid() will provide this for you as a string in a single call.

As long as they are different working copies there should be no conflicts at all. I personally have both those, Perforce (legacy systems) and Git source control providers installed.

Or the newly re-branded Goop Development Suite

For SVN - using the TSVN Toolkit (from Viewpoint USA - see VIPM) helps alleviate this issue (as well as file renames). It makes the changes both in Project Explorer and SVN using the "Rename" command. THis basically performs the SVN rename (even if you just moved the file) and performs all the caller linking as well, just like normal rename / move on disk functions. The main downside is that you have to perform it one file at a time rather than bulk as you can with move on disk. We moved to SVN (away from both TFS and Perforce) because of this toolkit - and this is one of the key reasons. There is no such convenience for Perforce or TFS. Without the TSVN Toolkit this would be the same similar issue with SVN as well. As far as source control goes - I still think that storing relative paths in all project and library-type xml files is the best best (where projects are still absolute paths). At least then a convention of "folder -> project file -> sub folders with all the project content" would make re-linking easier if you wanting to move things around outside of LabVIEW.

Hi there, It's a loaded question to be sure. But we have had to consider similar things in the past before as well. Here would be my feedback: We use Intouch for production equipment HMIs. This is mainly due to the ease of rapid prototyping and the enhanced graphical capabilities that are needed. We find that LabVIEW is sorely lacking in this department - our HMIs are intended to be operated with minimal training and be accessible to the "swipe" generation. For test equipment with specialist hardware we often have a TestStand or LabVIEW back-end that does a lot of the hardware interfacing. For other automation equipment we often revert back to cheap but effective PLCs. The ability to do complex animation effects, window management and scripting is typically built-in and intuitive in most SCADA systems. It's what they are there for after all. Most SCADA HMIs (Intouch included) support ModbusTCP. This is a very common communication protocol and is often "built-in".. We have implemented much more complex systems than this in Intouch previously. SCADA systems typically require purchasing a development license and then a run-time license on each machine running the deployed HMI. You should factor this cost into your solution chart when making the decision. You can always contact a local representative in your country to determine the expected costs. Do not forget the cost of engineering time. This is difficult to gauge in your case but the fact that you are already familiar with LabVIEW is a strong tick in that column. SCADA systems are not as typically good at performing test sequencing (their primary function is data collection, display and logging hence the name). In your case the infrastructure needed is not great so it is quite possible to implement what you are proposing in such a system and we have done so many times before. However I suspect that familiarity will be the biggest deciding factor for you. I would encourage you to explore the SCADA option if only for future endeavors where your requirements are different. Hope that helps.

I have posted a reply to your question over on the dark side: http://forums.ni.com/t5/LabVIEW/Tree-Data-Structure-with-DVR-Arrays/td-p/2836214

The configuration is contained in the *.ini file for the built application along with other properties such as vi server configuration. Here's an example of the content that updates the Other1 and Other2 execution systems maximum thread count for each priority. You can generate this programmatically as part of the application build spec with a Post-Built Action : ESys.other1.Normal = 20 ESys.other1.High = 20 ESys.other1.VHigh = 20 ESys.other1.TCritical = 20 ESys.other2.Normal = 20 ESys.other2.High = 20 ESys.other2.VHigh = 20 ESys.other2.TCritical = 20 Note that you could also just use the same property settings in your LabVIEW.ini file for the same effect in the development environment. I believe this is all threadconfig.vi actually does however it doesn't touch any application build specs (not that sophisticated I'm afraid). Here is a quick post build vi I cobbled together to generate the entries on every application build:

Thanks Omar. Further investigation seems to indicate that pulling network licenses is what is causing the issue. Oh well, running the agent as an application will work for now. I see a fix there for template instantiation, nice! I'll check it out. I confess I had actually lost a little faith and ended up building my own unit test framework with some similarities to VI Tester (ie based on xUnit) solely so that we could run on 2012+ and get the benefits of a leaner framework for CI rather than NI's UTF. But I would always rather use a tried and tested tool. Just an FYI this is the sort of tool we would happily pay money for!

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 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!

Hello all, I am trying to integrate our LabVIEW build workflow into our CI Server. Currently we have several builds in LabVIEW projects that we can programmatically call in order to perform the build, conduct unit testing etc. using the IDE. I'm looking to integrate this into our build server using TeamCity. Every time we check in changes to one of the projects a build is triggered. Since building requires the IDE running, I am attempting to use the Command-line Runner in TeamCity to execute a batch file that launches the IDE with the builder VI as an argument. The build VI performs the builds, testing and then shuts-down LabVIEW. Running the batch file manually (as me) works a treat - LabVIEW starts up, the builds occur, unit test results are captured and then the IDE shuts-down. However I have run into a problem getting the batch file automatically called by TeamCity. The build agent runs as a windows service and it appears as if windows services do not have permissions ordinarily to start up GUI applications. I have tried several options such as configuring the log-on account for the service to run etc. Every time the build occurs, the log shows that the batch file has been run but LabVIEW does not start up. Unfortunately there is no command-line version of LabVIEW (pity) so it appears as if there is no obvious way to get this to work. Has any-one attempted this before? I know guys at JKI pull this off (using a different CI server) and I'm wondering whether this issue is familiar to anyone. Thanks for any and all help.

hoovahh is correct - I would like to ensure that I run a VI in the correct application context (in my case it will always be the singular My Computer) of the active project regardless of whether the menu was opened from Project Explorer or a VI opened from Project Explorer. I had hoped that MenuLaunchApp would provide this but Aristos' explanation proves otherwise. This seems like the best idea. Since I want to the same behaviour regardless of whether the menu is called from project explorer or a VI in that project, this would appear to be the only way to ensure that. I am building a simple custom unit test framework so all my tests will be executed in the IDE in the My Computer app instance; I can hard-code the search for that. Thanks for your help guys.

Thanks for checking it out (although I might still be a little crazy generally speaking!). I'm on 2012 SP1 as well. I did a little test using a basic VI that grabs the current context and the MenuLaunch context names under a number of conditions: Getting Started Window - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Editor, MenuLaunchVI=GSW.lvlibp:GettingStartedWindow.vi Project Explorer - ThisContext=NI.LV.Dialog, MenuLaunchContext=NI.LV.Dialog, MenuLaunchVI=_ProjectWindow2 New VI in the Project - ThisContext=NI.LV.Dialog, MenuLaunchContext=My Computer, MenuLaunchVI=Untitled 1 Surprisingly there is an actual Launch VI for running from the tools menu in Project Explorer, although I don't know whether the naming is anything specific or could just be random. In any event this doesn't get me the project application context that I was after unfortunately.