Jump to content

Lars915

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0

About Lars915

  • Rank
    Active
  1. 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
  2. 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.
  3. 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:
  4. 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 Lab
  5. 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.
  6. 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.
  7. 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!
  8. 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 Offic
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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, in
  14. 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.
  15. 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 m
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.