Wednesday, May 09, 2012
#
Time for another LabVIEW user group at RoviSys in Aurora, OH! Along with the usual food and beer, we'll have a new presentation that I'm particularly interested in: LabVIEW OOP.
Here's the official blurb:
Introduction to LabVIEW Object-Oriented Programming
Learn the basics of object-oriented programming (OOP), when and why you should use it, and how to use OOP in NI LabVIEW software. Attend this session if you are a LabVIEW developer who is new to OOP or a developer familiar with OOP principles in other languages and want to learn how to apply that knowledge to LabVIEW code.
----
For a good overview of what OOP is and what it brings to LabVIEW, check out the LabVIEW OOP FAQ. There's another great article that goes in-depth on the methodology and design choices made by the LabVIEW team for their implementation here: The Decisions Behind the Design.
Object oriented programming has existed in LabVIEW for a long time; before NI's official implementation, there were 3rd-party toolkits that added various flavors of functionality. The National Instruments team has been shipping OOP examples with LabVIEW since version 8.2.
The Advanced Architectures in LabVIEW training course touches on some of the OOP principals in LabVIEW, but there's a complete course dedicated to OOP: Object oriented design and programming in LabVIEW.
Register for the event!
Thursday, January 26, 2012
#
A year of User Group Meetings have been planned at RoviSys, and the next one is only two weeks away. Come chat with fellow professionals and enthusiasts over a beer, and stay for dinner while two industry professionals present on different topics.
Hillary Emer, our local NE Ohio field sales engineer, is giving a presentation on Building Advanced UIs in LabVIEW. I saw what might be a subset of this talk at an NI week 2011 Alliance Day presentation and was impressed by the flexibility and customization present in LabVIEW's controls without needing to delve too deeply into any esoteric nooks of the software. Hopefully I'm not spoiling any surprises, but check out the NI UI interest group at https://decibel.ni.com/content/groups/ui to get some ideas or download some control schemes for your own apps.
AJ Piscitelli, from Fenetech, is presenting on X Controls. Whenever you need custom UI elements that behave with functionality not available in the standard controls suite in LabVIEW, X controls can save your day. The common shipping example for LabVIEW is a thermometer temperature control that can convert from F to C or vice-versa internally and has a different appearance depending on if it's placed as a control or indicator. I've also seen an interesting text indicator that works like a "scrolling LED sign"; it's datatype is "string", but it looks like a 10x50 grid of boolean LED indicators and automatically scrolls its text from left-to-right. Once you've made it, it's easily reusable and can simple be dropped onto your UI like any indicator.
Be sure to ask AJ to see his Star Trek LCARS graphical UI he designed in LabVIEW!
February 9, 2012 at 5:30 pm
RoviSys, 1455 Danner Drive, Aurora, OH 44241, Multipurpose Room (just come in the front door!)
Register here: http://sine.ni.com/nievents/app/offering/p/offeringId/965845/site/nic/country/us/lang/en
Tuesday, December 27, 2011
#
RoviSys hosted another Northeast Ohio LabVIEW user group meeting a few weeks ago, put together by Hillary Emer from National Instruments. We catered barbecue for dinner and filled the cooler with beer for another round of presentations and discussions.
Mike Owens, a Services Specialist from National Instruments, presented Managing Obsolescence of COTS Components. He demonstrated a few lifecycle management plans from actual NI customers and gave a lot of useful advice about the benefits of planning upfront for equipment retirement. He also explained how NI handles product and service lifecycle internally, and how a customer can determine where a given piece of NI hardware falls into the lifecycle/support matrix (hint: call Mike Owens!).
Check out the NI Product Lifecycle page for some general information.
Next, John Hubiak from Eaton presented Real World Application of LabVIEW Real-Time Programming. John shared his code from a large real-time fuel pump test stand he maintains. The project has a real-time control and data collection backend with a network-connected interface frontend for interacting with the stand.
I asked John later what he wished he'd known before he'd ever embarked on the project and he reiterated a point from his presentation, which is that large numbers of network shared variables are far too slow for passing data between the frontend and backend. Instead, John implemented a custom TCP-IP talker/listener pair and used functional globals to store the data on the frontend which gave him the throughput he needed to handle his large number of datapoints at high rates.
Sharing your personal code with a group is a nerve-wracking undertaking - it's as soul-baring as presenting any work of art to an audience for the first time - and I'm really glad that John chose to share all his work with us. LabVIEW has a strong user community and a lot of those users are self-taught to some degree. These opportunities to share and view other ideas are one way that good practices are learned and spread, and I look forward to seeing more applications in the future.
RoviSys will be hosting more user group meetings in 2012, and we'd love to see you attend!
Wednesday, September 21, 2011
#
The LabVIEW User Group Meeting happened last night at RoviSys. We enjoyed a good turnout and a great dinner from Old Carolina Barbecue!
Hillary from NI kicked off the meeting with a round of introductions, followed by my Desktop Missiles presentation (described in the previous blog post. Hillary wrapped up with a "What's New in LabVIEW 2011" presentation, and RoviSys director Dick Ciammaichella led a tour of our facility.
Click Here to view the Desktop Missiles presentation (Prezi.com)
Source Code for LabVIEW 2011
The Missile Launcher I used is becoming hard to find for purchase because the company that makes it (Dream Cheeky) is constantly coming out with newer versions that incorporate more missiles, webcams, and even bluetooth control. These models may or may not use a similar control scheme, but I'm excited to get my hands on one to find out!
I had a great time after the meeting enjoying a beer and talking to everyone about the interesting and diverse things people are doing with LabVIEW. Several people at the meetup said they didn't use LabVIEW, but they came anyway because they're enthusiastic about programming and technology. I think it's a good reminder that LabVIEW is only one tool out of many but that anyone who's interested in programming on any platform can learn a lot by meeting and talking with fellow enthusiasts.
I look forward to the next User Group!
Friday, September 02, 2011
#
National Instruments and RoviSys are teaming up to host the September 2011 NEOhio LabVIEW user group meeting at RoviSys in Aurora, OH.
Hit this link to sign up at NI.com.
We're putting on a technical presentation and serving Damon's ribs and chicken for dinner. The user group meetings are a great time to meet some of the local people using LabVIEW and share ideas over a few beers.
Here's the official abstract:
Serial ports are disappearing. We miss them because they made integration to outside devices easy; just open a port and send some data! USB devices have never been quite as approachable and usually require the a programming API to be made available by the manufacturer. With NI’s VISA customer driver development wizard, we can easily create custom USB device drivers that let us open a pipe to USB devices and send commands using some familiar VISA functions.
During this presentation, we’ll start from the beginning with a popular USB Desktop Missile Launcher toy and show you how to create a custom driver, access it from LabVIEW, and even how to use some USB packet sniffing tools to derive the necessary control commands by “listening” to the host application talk to the device. The end result is a set of custom functions that let you add missile launching to any of your applications and gives you another tool in your arsenal of interfacing to unusual devices.
Wednesday, December 01, 2010
#
It happens all the time - we have 20 signals to collect, but the card only has 16 inputs. Usually the solution is simply to buy another card and identify the excess as spares.
But what happens when having a high count of inputs is prohibitive, either from cost or practicality? Take an example where a test stand might have 48 test positions, each of which needs to connect to a single USB device. Having 48 of these USB devices might be very expensive (consider the case of an oscilloscope that costs thousands of dollars.) Moreover, how do you connect that many devices to your test stand PC and ensure they're all powered sufficiently? Finally, how are you going to manage that many devices in your application and ensure that you're talking to the right one each time?
There are several good answers to these questions; even the scenario above of having 48 USB devices would certainly work if you can afford it and manage it carefully.
There's another solution, though - use an NI switch module (multiplexer or matrix) to allow you to connect many devices under test to a single (or two, for parallel throughput) input device.
We recently designed a system that would use an NI Multiplexer to let us connect 24 test samples to a single USB device one at a time. If we had only a single signal wire to connect, this would be called a 1x24 mutliplexer or "mux". However, we actually had two signal wires per device that needed switched simultaneously - in this case a TX and an RX line for communication. That meant we needed a 2x24 mux - 2 wires by 24 positions.
After further consideration, we realized in our case there was a big benefit to be had from adding a second USB device so that two of the test samples could be connected to the PC at once. National Instruments directed us to the use of a "dual 2x12" topology offered by the switch we had already selected. This would give us two separate banks of 2x12 switches that can be switched independently, allowing us to scan two positions simultaneously in our code.
There's a very strong ease-of-use factor with these switches as well. It could be confusing to attempt to manage 24 of our enumerated USB devices through LabVIEW, especially tracking as devices are added or removed, but managing the 24 possible switch connections is easy. We simply explicitly command the switch to connect, say, channel 5 to common 0. We can even query the driver to see what connections have already been made.
The questions you have to answer before considering a switch module are:
- How many test positions do I need to connect to?
- How many common devices do those positions need to interface to?
- How fast do I need to access each position?
- Is this more cost effective or easy to use versus simply having an end device for each test position?
Sunday, November 07, 2010
#
We frequently interface to parallel port label printers with LabVIEW. These make it easy to use VISA calls to write a stream of ASCII data directly to the printer. As our focus moves to USB printers, there’s a more complicated setup process involved that ultimately gets you to the same place – being able to use the VISA VIs to stream data directly to the printer without going through the windows print function.
When you plug in a USB printer, Windows wants you to install drivers and you cannot access the device until you do. If you install either the Datamax printer driver or the generic USB print host driver supplied with Windows, LabVIEW won’t be able to access it directly. It could only print out to it like a normal printer, and you’d wind up with a label with the raw ASCII label code printed directly on in instead of a parsed label like you were expecting.
The solution is to install a custom-made driver that tells National Instruments VISA to take control of the printer, allowing you to open it like a normal VISA port. The National Instruments website has a procedure - but check the notes below before following it for printers!
I ran into a few issues following the procedure. First, you must know the USB Vendor ID and Product ID for your printer. The article has a tip for finding it, but it didn't work for this particular printer. Instead, I used the free program USB Snoopy to look at my USB devices attached to the computer to find the Vendor ID and Product ID. For my model of Datamax printer, it was VID_0B0B & PID_106E.
The next issue was that, after installing the device, I'd still get a "Device cannot be started" error at the end of the driver installation. It turns out that with USB printers, Windows will associate it with "USB Printing Support" in the system device manager even if you choose not to install a driver! This interferes with NI-VISA's ability to take control of the printer. The correct method for doing this procedure with a USB printer is to connect the printer to your computer, then cancel the driver installation wizard. You must find the USB Printing Support entry in the device manager and update the driver for it. Follow the National Instruments procedure linked above after you choose to update the driver.
Once everything is complete, you'll have a brand new USB entry in Measurement and Automation Explorer (MAX) that you can give a custom alias. In LabVIEW you can now use the VISA open, close, and write VIs to communicate directly with the printer. If you drop a VISA Resource Name Constant on the block diagram, you can select the alias you’ve configured. Note that these aliases are persistent, even if you don’t have the device attached.
With Datamax printers, you can test your connection by sending command <STX> T to print a quality test label. This looks like “\02T” in slash code mode.
This procedure will let you talk to many other USB devices, not just printers. Other types of devices will not appear as "USB printing support" so that advice may be skipped - although we now know to check to see if they automatically appear as something else when first plugged in. Using the advanced functionality of USB Snoopy, you could even sniff out the commands sent back and forth to other USB devices from their native drivers to decode how to control them from your own applications. Want a USB Rocket Launcher integrated with your teststand?
Wednesday, October 27, 2010
#
Every manufacturer spends significant time verifying that their product performs to the design specifications before leaving the factory. With all of the quality inspections in place companies still have to allocate entirely too much of their time and expense to deal with faulty products that have left the manufacturing facility.
The true cost of faulty products being shipped is hard to measure. You can track the amount of time we have employees handling phone calls and returned products; the amount of time spent reworking products; and service techs time in the field. It is much more difficult to measure cost due to business interruption and more importantly, lost sales and lost goodwill!
Product testing is getting more complex with more products that contain some type of microcontroller. The greater the complexity of a product, the more things that could go wr.
How do we solve the problem of bad product leaving the facility? The first step is to automate testing. Automated testing brings several advantages including:
- Eliminate human error
- Perform comprehensive testing including hardware and firmware
- Simulate failure conditions to ensure proper operation
- Automatically store data for real time trending and alarming of patterns before they become failures
Automated testing allows us to perform tests that cannot be accomplished manually i.e. monitoring several values during an entire test and failing the test if one parameter momentarily falls outside the test limits. Automated systems excel at repetitive tasks, reducing human error.
Automated test systems sound like a great idea but it can be difficult to figure out how an automated system will work within your existing manufacturing environment. There are companies that specialize in automated testing and they can show you how to successfully deploy an automated test system that is designed for your product and methodologies. All we need is the knowledge of how you currently manufacture your product.
Thursday, November 18, 2010
#
HART is a popular communication protocol for field instrumentation that can allow remote reading and configuration for installed devices. There are many software packages available that allow PCs to talk to HART capable devices using HART modems. RS-232 HART modems are still farily common, although they are being superceded by USB versions.
It's possible to use LabVIEW VISA functions to talk HART through RS-232 modems. Although the details of how to talk HART are proprietary and must be purchased from the HART foundation, getting LabVIEW to communicate can be difficult even once you know how to form a proper data message.
To begin, use a VISA CONFIGURE SERIAL PORT block to open a local COM port at 1200 bits per second, 8 data bits, ODD parity, NO flow control, and 1 stop bit. Disable the termination character.
We've disabled flow control, but most RS-232 HART modems rely on the RTS line to tell them when to take control of the line by generating the carrier frequency. You can drop a VISA property node and write directly to the RTS line status. We want the RTS line to be "unasserted" after configuring our serial port to make sure we're not unnecessarily generating the frequency on the line. Some modems need the DTS line to be high all the time to provide power to the modem. It can be asserted in the same fashion.
Before we can send a message over HART, we must again use the VISA property node to assert the RTS line. The message can be sent immediately.
Most computers have a buffer associated with their serial port. When you perform a VISA write to the serial port, the data you wish to transmit is put in the output buffer and the computer takes care of clocking it out at the appropriate rate. The HART modem itself may add some additional lag before the message appears on the data lines. Therefore, it is important that we allow the RTS line to stay asserted long enough for the message to make it out of the buffer. 1200 baud is very slow by modern standards. I found that by immediately unasserting the RTS line after a VISA write I was only able to get a few bytes of my message actually onto the data line before the carrier frequency shut off. For short messages, a delay of 100 mS between the VISA Write and the RTS unassert gave enough time for the message to get out on the bus but not so much time that the device's response was overwhelmed.
It's easy to see that for longer messages this timing might not work. A better solution is to monitor your computer's output buffer to make sure it's clear before unasserting the RTS line, but it does not appear this is possible through LabVIEW. Instead, it might be a good idea to use the length of the message to calculate an appropriate delay time.
Tuesday, September 28, 2010
#
R.W. Beckett is a respected manufacturer of oil and gas burners in northern Ohio. Quality Magazine has a whitepaper in their May issue about R.W. Beckett's gains in testing reliability and throughput when they moved to automated testing of their oil burners and controls using teststands designed and built by RoviSys.