01-05-2010 09:42 AM
Hello all,
I have a pyrometer from micro-epsilon company with the brand thermoMETER CT infrared sensor. It is connected to computer via serial connection. The problem is when I send the command to read the temperature value, I get 4 empty square characters as response. These pyrometers are newer. We also have old version pyrometer and I tried to connect them and everything is working just fine. I tried to search on the net but couldn't find a solution. Anyone had a similar experience or have a solution for this? I appreciate any help or suggestion.
Thanks,
Emre
01-05-2010 09:45 AM
01-05-2010 09:47 AM
Hi,
when usin serial comuniations i normall try to et the device working using hyper terminal first. If you a test VI it might help us see if there is an obvious problem.
01-06-2010 06:21 PM
Hello Eunsal,
Please also make sure that you are displaying the returned value as Hex display. It sounds like your sensor is returning values, but does not have an ASCII representation of what is being returned. Just right-click your string display and select Hex Display to start getting data that you can read and interpret.
01-07-2010 11:00 AM
Thanks for the quick replies and suggestions.
Here is my current weird progress. We have 5 of these units and I could connect only 1 of them through Labview and Hyper Terminal and I can read temperature values with no problem. For the other 4 unit I can connect through the software that the company provided and can read temperature values. However I can not connect those 4 through Hyper Terminal or Labview. When I use Labview (I use Labviews Basic Read and Write.vi example) I get those 4 empty square characters and if I select "Hex Display" as ColeTrain suggested "0708 0514" is showing.
All the units are running in factory default settings, I ddin't change anythig. The point that I couldn't understand is how can I connect the 4 unit through their program and can not reach through Hyper Terminal or Labview. Or the other way, the 1 unit that I can see in Labview or Hyper Terminal I cannot reach through their program. I thought that the program they provided somehow reserves those ports, so I even uninstalled the program but still the result is same. I also contacted with them but all I got is set baud rate to 9.6k and they should work.
I changed cables, computers, ports but couldn't figure out whats going on.
01-07-2010 11:49 AM
Well, seeing that the old unit works and 4 newer ones do not suggest something is different with the newer pyrometers. Are you sure the newer ones have RS-232 serial and not RS-485 communications? If in doubt, open up the units and check the communications board that is installed. Also make sure it is connected to the header and the wiring is correct as outlined in the manual.
Does not seem like a LabVIEW related issue based on your Hyperterminal and stand-alone application from micro-epsilon. You may want to press the issue further with micro-epsilon.
-AK2DM
01-08-2010 02:37 PM - edited 01-08-2010 02:39 PM
Eunsal,
That Hex number is 1887438100 in decimal notation. As it's 4 hex digits, this is a 32 bit number. If your device is returning temperature based on an I32 scale then this number scales to 0.878 while the U32 version scales to 0.439. Just something else that you could discuss with the device manufacturers. Also, if they are returning a floating point single precision scaled as a 32 bit number (explained here), then they are returning a value of approximately 0. Hope this helps!
01-08-2010 03:25 PM
03-13-2018 04:08 AM
A bit late (8 years) I know but hopefully this will help someone.
The reason for the different output for the newer models versus the old ones could be the serial output protocol used. CT/CTM pyrometers (and probably the rest of the line) are by default set up to communicate in binary, however if desired they can be set to ASCII. Given the difference in expected output I'm assuming your original model was set to ASCII.
As someone else mentioned the 4 bytes returned do indeed contain the temperature, for binary sending a 0x01 ("READ Object") request yields 4 bytes: b0 & b1 contain the temperature (T = {b0*256 + b1 - 1000} / 10) and from what I can tell b2 and b3 are some kind of termination (the exact value seems to differ from model to model).
If you want to set the devices to ASCII communication you can send the HEX code 0x83 ("ASCII protocol"), it's unclear in the manual whether you need to specify a value (0 for binary, 1 for ASCII) or if it toggles. Additionally if you are writing a value you may also need to send the checksum (arithmatic XOR of all bytes except the address byte if used) which is enabled by default.
Tl;Dr - You may be having issues because you expect it to be in ASCII mode. You can fix this by sending either "83 01 [82]" or "83" (NB: set display style of string constant to hex before writing).
03-14-2018 11:09 AM
Update:
If you want to set the mode to ASCII you do need to send the checksum. Not all models support this however, if you find this locks you out of the device perform a manual reset (off and on then hold "down key" followed by "mode key" until RESET is displayed, this will put you back in binary mode.
I also found out what those extra two bytes were when reading temperature (or any other write/read command). It turns out that the binary protocol used doesn't use any termination methods on commands. Funnily enough the default termchar used by labview (line feed constant) happens to be the same as the "READ AL1 Value" or lower temperature alarm value command (0x0A). Just set ASLR End In and ASLR End Out to None on serial setup and you'll be fine.