Lars915

In my business, we deal with a lot of regulations including military, aviation, and safety critical systems. I don't believe there is any single source to tell you how to deal with "regulated industries", there's just too much variation. As stated above, determine what regulations apply to you, then start digging into the specifics of those regulations. One of the first questions to ask is whether or not your product is even regulated. Medical will have many layers of criticality. User interfaces are treated much differently than software that actually controls a blood conditioning machine for instance. Every industry has experts that will help you through the maze for a price.

A couple more observations to throw out. I also found that TestStand does not honor the LabVIEW project paradigm either. This could have some effect on handling classes. As for passing variants, I do that a lot. The only requirement I've found so far, at least for single values, is that variables must be cast as STR or VAL inside TestStand before TestStand can use them. I pass all my LV variants to TS containers.

Guess it helps if you make doubly sure the card is closed in one protocol before you start the next it works a lot better. :headbang:

I have many applications that must run various flavors of CAN, most notably CANOpen and DeviceNet. I am using a PXI-8464 dual CAN card. The problem I'm having is that during development, hiccups occur which crash the program before all of the CAN handles can be released. The only way I've found to clear them is to shutdown all of my NI software and restart which is a royal pain. I've also found that the NI DNET drivers do the same thing, leave handles unclosed, so I cannot run a standard CAN application after running DNET. Anyone know how to get these handles to release without restarting LabVIEW???

Instead of worrying about writing to Excel, perhaps you could just figure out how to make a CSV file and import it into Excel later. CSV's are easy: send out your data separated by commas, and add a linefeed at the end of each line of data. Super simple and Excel is totally happy with it.

I've learned over the years to explicitly close every reference I create. Since I generally am interacting with MS Office applications, this means all of them including the application references from the front panel. When I'm working with VI rerferences or front panel object references, I always close them unless I get a fault and completely understand why I'm getting the fault. This may be overkill, but I don't get memory overflow crashes on my tests that run for months on end any more.

QUOTE(JDave @ Mar 8 2008, 09:03 PM) That's kinda what I figured. The list under My Computer isn't too promising. Thanks for the replies!

We have just started changing over to MS Office 2007 and have found some problems using current VI's with the new Excel 2007 API. Specifically, some parameter lists have changed which breaks my VI's. My problem is that not all LV developers are changing Office versions at the same time. Conditional disable structures look like a good way to deal with this as I can call the Excel API version I need based on conditional symbols. My question is, can I add symbols to the Conditional Disable Symbols list for My Computer? It currently shows CPU and OS symbols, it would be nice if I could add Office or Excel version to the list.

We don't use DSC, but we use various combinations of LabVIEW as a front end to control TestStand while it's calling LabVIEW in a driver layer, both in production and in new product development. The latest version of TestStand is far superior to versions 1 and 2, and is quite a step up from 3.X. You may want to take another look at TS4.x. They've done a lot of work on appearance, and the user interface layer (used by LabVIEW) is vastly different than all other releases.

My testing passes a lot of info between LV background processes and TestStand (Implementing custom communications protocols.) Using a communications manager works great, especially when the background processes run on remote machines.

QUOTE(bmoyer @ Nov 19 2007, 01:17 PM) I've got the Watlow VI's, but they all deal with command numbers and values (Modubus commands). I like to deal with english commands so I'll have to wrap them in a higher level layer. No big deal once I get the time to understand the order of operations and all the options.

QUOTE(mross @ Nov 19 2007, 09:39 AM) It lookes like that pattern is the one I'm looking for.Unfortunately, the temp controller is a Modbus based controller with very generic Serial to Modbus converter VI's. I'll end up creating a lot of the stuff I need for it (gotta learn it, we have a few of them.) Anybody have a Watlow F4 library? QUOTE(Eugen Graf @ Nov 19 2007, 10:17 AM) Hello, would you try it out:I think it is exactly what you need. You can manage complex applications dynamically. This design pattern supports 4 communication types incl. User Events and Notifiers, but the best one you can debug it remotely over TCP/IP.Eugen That's a great example. It'll help get over some of the initial hurdles of understanding how to implement the pattern. Thanks!!

First off - I'm a long time LabVIEW programmer, but mainly with instrument drivers and small apps. Sorry if these issues have been covered before, but I'm under quite a time crunch and need a little guidance while I keep researching. I am putting together an application that controls a temperature chamber for long term testing (30 to 60 days per test.) The application performs logging and UUT status checking at regular intervals and provides a configurable user interface. During the main application loop, the program must read and write several flags, run the timers that control the flags, interact with the user interface, interact with the UUT's, and provide closed loop control for the temperature chamber. It looks to me like I'll be running several parallel loops, an event structure driven state machine, and several user events. What I'm looking for here is a suggestion on the high level application architecture. I need to monitor three or four flags, set three or four flags, write some data to file, send data to a user interface (similar to the structure described in "A Software Engineering Approach to LabVIEW." Is a central event structure capable of handling something like this while using parallel timer loops to effectively generate interrupts? How stable is event handling overall? Again, sorry if this is old stuff, I have to come up to speed in a hurry. (Oh, this is a slow application with no real time requirements. If I get 15 second response times I'm good.) I'm familiar with several state machine algorithms and am coming up to speed on user events and the event structure. Hope this isn't too vague. I'm not looking for solutions to the worlds problems, just a general idea as to what architecture can handle a potentially high interprocess communication load so I don't get too far down the wrong road.

Uwe, Thanks for the reply!! After some brainstorming among my developers, we came up with pretty much the same idea. It will be a bit cumbersome to maintain parallel development paths during the brief time my group is using different versions of LabVIEW, but we try to keep that time to a minimum so it shouldn't be too bad.

My company has a large number of software testers in several departments. We all use Subversion for version control, but we don't all use the same version of LabVIEW. Almost all testing we do uses TestStand for test flow control and we use several libraries of LabVIEW drivers to interface with the test hardware. My problem is figuring out how to organize subversion to accomodate using several versions of LabVIEW libraries. We don't necessarily try to keep all libraries up to date. As new products come into our department, we try to take advantage of new technology, and of course new drivers may be needed as required functionality grows. So, I understand trunks and tags. I suspect the answer is to use branches, but I'd like to hear some experienced opinions before I dive in to fix this and end up redoing it a dozen times. The current layout we use is to use a trunk to hold all the libraries in the user.lib and instr.lib directories. We use tags to capture snapshots specific to individual projects so we can rebuild a test setup. The next thing I need to figure out is how to continue development in LV8.5 without overwriting our 8.2 and code.