Reading Pyrometer Temperature Data into LabVIEW

[johndoe5280]

Note: Please let me know if this would belong better in another community and I will repost it there. 

I work in a research lab that requires a pyrometer to do non-contact temperature measurement of silicon chips that are heated by halogen lamps. Presently, we use thermocouples to read the temperature and then do closed-loop feedback to either turn the lamps on/off based on the heating trends that we desire. The issue with using the pyrometer (Model here: http://www.optris.com/optris-cslaser-lt and the manuals are in the "Datasheets and manuals" tab) is that the software provided by the manufacturer just records the data into a text file after the test is run and doesn't allow for real-time integration with LabVIEW. There is a connector that plugs into the back of the pyrometer and has wires with the following designation:

Then there is a further USB adapter that we bought in order to communicate with the pyrometer on the computer. This is the connection diagram:

I'm new to LabVIEW - is there a way to get the temperature data (which I assume is coming from TXD, the yellow wire) into LabVIEW? Could I use a Compact DAQ on the digital side and plug the TXD wire into one of the channels to receive data? Or is there a way to still use the USB? Thank you so much for any help. 

[WenR]

Hi

Thanks for providing such good detail of your setup! Usually, when it comes to using non NI hardware with LabVIEW, the options (from the easiest to the not so easy one are):

From Software (without breaking any cables):

1. If you are lucky, use the driver someone else already built for the device. ni.com/idnet has a lot of drivers for third-party, unfortunately, I did not find one for this pyrometer there. Sometimes the vendor of the hardware has a driver available, so searching in Optris' website would be worth trying.
2. If there is not a driver for LV, you can use a driver built for another environment (usually delivered by the vendor as a DLL) and use the Call Library Function Node in LabVIEW as a wrapper to call those functions. This will allow you to send commands to the device and read data back on a high level. This is usually the approach that most people take to integrate hardware into their programs.
3. If the vendor does not have a driver available, you can use the details in the manual to build one yourself. This requires you to have the details on the commands that are sent through the USB port which is something the vendor could provide you with. The guy from this post seems to have gone with this option. Some vendors do not release this information, in which case you would need to put a lot of effort and some reverse engineering to figure out the commands. This would likely require a lot of time and I would not recommend you to go down this path unless you really need this to be done.
4. Another option would be to continue running the third party software and use a USB sniffer to get the data from the SUB adapter (what you proposed). There is no native USB sniffer in LV, so this would require some additional software or building the sniffer yourself. here is a discussion on the topic, there are some free USB sniffers on the web, but I would not feel comfortable recommending a particular one in this case. https://forums.ni.com/t5/LabVIEW/how-to-sniff-port-usb-using-labview/td-p/1894895

From Hardware (breaking the cable):

1. Using a cDAQ on the TXD wire seems like an easy way to get the digital packages into LV, however, you will need to invest a bit of time on building code to recognize the digital patterns you capture and translating those into the data you need. If the vendor provides you with information about the commands that the device sends and receives, this seems like something you could try. It would likely have the added complexity of keeping the connection noise free, since breaking the cable could affect not only your readings but also the device's capacity to sustain stable communication with the computer.

There might be some additional options I did not think of, but I hope this helps!

WenR