I'm new to using LabVIEW, and I'd like help finding examples, or some guidance, if someone has the time.
I'm using an industrial device with a RS232 output. I've viewed the basic and advanced examples for serial communication, but I have further questions and haven't even started attempting to program in LabVIEW.
The initial idea is to have the RS232 output connected to the computer, then WinWedge (like HyperTerminal), and have that signal be both plotted in real time AND recorded in an Excel like datasheet.
Do I have to use WinWedge in between, or can LabVIEW just read incoming serial data? Also, are there programs out there that have such a function done that I can edit (with proper credit given)?
Thanks for the help.
LabVIEW can do all of the communication and saving of data.
There are thousands and thousands of existing instrument drivers. You have not mentioned the vendor or model number of the device so the search for similar drivers or one that match your instrument will have to be up to you. On that page you will also find information on how to use an instrument driver or how to create your own.
Thanks for the response.
Alright, so I can cut out the WinWedge part, and go from the device to LabVIEW. Good to know.
I searched for drives, but no luck. I'm using a Thornton 770MAX, which monitors several things. Would I still be able to interface with this? What would be the steps that I need to take, to properly get this functioning?
You can use LabVIEW to interface to any serial instrument. Look at the drivers for other Mettler-Toledo instruments and study your manual. There are a couple of basic serial examples that come with LabVIEW. Debug communication in MAX or with another terminal emulation program so that you learn the correct com parameters (i.e. baud rate, parity, etc), the correct type of cable, and the command and responses. Then you can start writing some LabVIEW.
Alright, I'll look up the information that you provided. Thank you.
As far as the device goes; we have been using WinWedge which easily allows us to communicate with the device without any drivers. We then used an Excel macro to record the data at a specific time unit. Would this be a better solution? To send the WinWedge data to LabVIEW, so there would be no need to develop drivers for LabVIEW (assuming that I can't do it).
No, I would implement it all in LabVIEW. It is actually quite easy to do what you are asking in LabVIEW. If you start introducing additional applications and data formats everything becomes more difficult to maintain.
Sorry, but I have no experience with winwedge. You would need some sort of api to call it from inside LabVIEW. Check with the vendor to see what sort of options for interfacing to other programs are. If this winwedge is already acquiring and saving the data, what would be the point of using any LabVIEW program?
Alright, I'll give it a shot and update whenever I can, with success or failures. I guess this is a bit different (to me) from typical programming. I know interfacing with devices without proper drivers can be a headache at times too, which I am attempting to avoid.
WinWedge is like HyperTerminal pretty much. It's a nice piece of software.
LabVIEW is nice because it looks nicer and the possibility of real time is very appealing, as a developer and researcher.
What exactly does WinWedge fail to do for you today? LabVIEW is a complete programming language and environment. The possibilities of what you can do in LabVIEW are infinite. WinWedge appears to be an application that captures data from serial devices and pushes it into other application like Excel or into a database. If that is all you need to do than stick with WinWedge. If you need to do other things such as automating the process than you are probably better off doing it in LabVIEW. Most serial protocols are pretty easy to implement. If you are talking to fairly common devices chances are a LabVIEW driver already exists or there is one that is very similar. If you do go the LabVIEW route I am not sure how easy it would be to integrate it with WinWedge. In addition, your application will be dependent on a third party tool.