DanW

If the "RTD" in the part number of that input module means that that particular AI card is for direct connection of RTD's then the answer is most likely, "No, you cannot wire Infrared sensors directly to that card".  Nor are you able to take signal from the temperature controller because there is no known commercial temperature controller than outputs a resistance vs temperature signal.  The re-transmitting output of temperature controller is normally 4-20mA, sometimes a high level voltage, like 0-5V.  4-20mA and 0-5V is incompatible with a RTD input. The infrared sensor market has models that output 4-20mA over a specified temperature range and then there are models that output a non-linear thermocouple mV output over a temperature range.   The thermocouple output is designed to be compatible with thermocouple inputs but it is not compatible with an RTD input card. You need a different analog input card to handle an infrared sensor signal.

You might try control.com and Plcs.net forums with this problem.

Nice write up, thanks.    Changes over time . . . .

Can’t comment on a value without knowing its units. Is P proportional band or gain? is I engineering units minutes or repeats per minute?

Have you investigated whether this qualifies as a 'medical device' that falls under the purview of the FDA?  I've seen far less ambitious projects at pharmas that were subject to testing, and FDA review and approval.   

I did an HC-900 project back in 2010 or thereabouts.  That project used the standard fixed Modbus map, not the user-defined custom Modbus map. I do recall that Honeywell sold a large project in Europe at which point they discovered that Modbus did not work very well and produced several CPU firmware updates with Modbus revisions, 2010 or earlier.  So one question is, how old is this HC-900?  Could it be from the early period when there were Modbus bugs? Do you know if the Modbus register ever reported current values instead of stale, out-of-date values or is this the first time anyone's discovered it? If you can see the variable changing monitor mode in Control Designer, then I suspect that it is a mapping problem.  Somewhere in the presentation it describes how to print or export the Modbus map so you can check which tags are at which Modbus address. I attempted to upload a 1.5Mb pdf version of Honeywell power point on Modbus training for the HC-900 but the forum doesn't like it and I doubt there's a reasonable solution. The details in my memory are long gone on specifics of navigating HCD software, so I can't really help you, but if you post a throw-away email address that can handle an attachment, I'll email the training pdf to you.

The vendor reached out and said the displays arent calibrated only the output signal is Just a rant.  I've run into this on other instrumentation and it amazes me that a digital value for the measured process variable is available internally, so why isn't the digital display displaying the digital value and not converting an analog value?  You'd think that you could trust the local display as having the highest integrity as the representation of what's being measured, but no, the analog output is calibrated, not the display.  

I've  never used a 1746-NT8, but my reading of the 1746-NT8 manual says that it should theoretically cover the range -454°F through 2498°F. The blinking green channel LED indicates an over range input at the mV generated by whatever you're using to simulate 2498°F.  The fact that when you back the simulator off to 2488°F indicates to me a calibration issue: whatever the simulator is putting out the module interprets as the top of the A/D range: 32,757 counts at what thinks is should be 2488°F.   The top of the A/D range, 32,757 counts should be interpreted as 2498°F, not 2488°F.   I think you need to calibrate the input so that the module indicates 2498°F when the simulator provides the mV at 32,757 counts. As to the practicality of using Type K's above 2300°F (or below -30°C), or other upper levels, there's lots of bar stool opinions by long term users.   The 2498°F top value for Type K comes from the NIST tables (1370°C).   Many, many vendors have a lower limit on their Type K's based on reality experiences.   Honeywell's HC-900 thermal PAC ranges a Type K only up to 2192°F (1200°C).   Type K's can exhibit a fairly short 'valid' life at the high end of NIST table.   The problem is that the thermocouple can drift, which happens much more rapidly at high temperatures, and if the element does not break open, the T/C card still 'sees' a mV signal, but since the thermocouple has drifted the temperature calculated for the mV signal is false.  There is no way to compensate for drift.   You don't know how much or in what direction the drift is, because the T/C still appears valid because it's not an open circuit (it's not a thermocouple break condition).  

Commercial RTD’s are inherently isolated to prevent ground loop voltage/current (caused by a connection to ground anywhere in the lead wire or sensor) from affecting the constant current source generated by analog input.  A ground connection of the sensor element can cause symtoms like you describe.  Check for continuty between any lead wire and the element sheath (disconnect from the analog input while testing): it should be an open circuit, an extremely high resistance.  Make the same continuity check between each lead wire and the shield ground: again it should be an dxtremely high resistance. if you get a low resistance reading, replace the RTD assembly, unless you can find an obvious insulation problem or short in the lead wires. The lead wires should not run in AC power conduit or parallel AC power wiring in cable trays.   The nature of a ground loop is such that a ground fault connection in any of the connected RTD’s can produce a problem with the other connected signals, so if more than one RTD is check the others as well. If there are junction boxes in the field wiring, check for dirt, spider webs, insect nests, and especially moisture or water, any or all of which can provide a path between a signal and ground.   Intermittent spikes fully upscale or downscale is typically indicative of an intermittent loose connection.   

See posts #5, #6 and #7 at this link.  Note that post #7 is a correction to the formula given in post #5. https://www.refrigeration-engineer.com/forums/showthread.php?46561-R717-Pressure-Temperature-Conversion

Good catch Pturmel.   I can't proof read my own writing.   Yes, Modbus RTU uses an 8 bit data word.   I meant to write "Modbus ASCII" is a 7 bit data word.  

Serial settings for Modbus RTU, by the standard, is 7 data bits, not 8 data bits.    Apparently the ASCII protocol uses 7 data bits, too.   When you get a comm card, give 7 data bits a try, instead of 8.

If this is fire detection, a real fire detection system would use flame detection, fairly sophisticated multiband flame sensors with a corresponding price, and fault tolerancy logic. For your described requirements. - for temperature use an RTD or thermocouple sensor, either of which need a special, corresponding analog input, or a 'transmitter' that converts the raw sensor signal to a proportional 4-20mA output (4-20mA input is common PLCs).   Be aware that either senses only the temperature at the tip of the sensor, neither is an area sensor. For smoke detection, there are commercial smoke detectors that have a relay output that you tie into a PLC digital input.  Find one with a search engine. 

Have you ever pressed to see whether this network ever actually worked to any degree?  The mix of Honeywell products and their protocols makes me think that someone might have attempted and then abandoned the project, given the mix of protocols.  The absence of the program in the Basic module might disclose how the project actually got before being abandoned. There are 8 Honeywell devices I located in the field and they come in pairs. Node1: UDC3000 VERSAP PRO and UDC2000 MINI PRO Node2: UDC3300 and UDC2000 Node18: DCP1021111110 and UDC500 CONTROLLER Node19: DCP1021111111000 and UDC2000 MINI PRO 1. Pairing - High Limits I suspect that one of the UDC's for each pair of controllers is a high limit controller for a temperature control loop.  The fact that the comm cable only runs to the first controller in the pair confirms that. a. UDC 500 The UDC 500 is way past its expected life span.  It was obsolete when I started selling Honeywell in 1988.  I only one I ever saw was one that was replaced in about 2004.   If it still trips as a high limit, why not use it until it dies, but it could be lights out any day.   b.  UDC 2000 The blue bezels were obsoleted in about 1993. Blue bezel 2000's had no communications option The gray bezel DC200x models were obsoleted in 2000.  Gray bezel DC200x models had no comm option.       A DC200H is a high limit model Replacement models were gray bezel UDC 2300 (DC230x) and the current model UDC 2500  (DC250x) 2.  Single loop Controllers a. UDC 2300B DC230H is a high limit version.  DC230x-xx-1x had an "RS-485 ASCII/Modbus option".  The ASCII is a proprietary ASCII protocol, not Modbus ASCII (106 page manual).  The Modbus option was Modbus RTU.   Very few sold with the comm option, even fewer implemented.  No one ever implemented the ASCII version to my knowledge. I know that a UDC 2500 UL-approved High Limit controller (Modbus slave) will not accept a Modbus "write" Function Code (FC 06) for the operating setpoint variable.   One of the main operational uses in heat treat is to use a setpoint appropriate for the load for the high limit controller, but UL does not allow remote (comm) change of the operating setpoint.   I never tested to see whether a reset function (to reset the latched output) could be implemented via Modbus (I see that there's an output override value at (4)0035 that might reset the output) b. UDC 3000 The UDC3000 VersaPro (first generation) had one of two comm options, a proprietary DMCS protocol or communications RS-422/485, for another proprietary protocol with a 135 page manual.  As a Honeywell distributor we were aware of a couple OEMs who used DCMS; but I never encountered anyone who actually implemented the none-DCMS proprietary protocol.  That early, first generation model did NOT run the Modbus protocol. c.  CSP mode For Modbus comm, the UDC used a "CSP" mode to accept remote setpoint writes to the UDC to save the EEPROM.  The CSP mode held the remotely written setpoints in RAM and those updated setpoints were not written to EEPROM, because the EEPROM has a life-time limitation of the number of writes it could accept before bits failed.   Anyone communicating setpoint ramp values should have used the CSP mode because the constantly changing setpoints could crash the EEPROM (which is the units firmware) in a matter of weeks. d.  UDC's could have had a Setpoint programmer/profile option for a single SP program profile.  Could the comm have been tasked to just RUN, ABORT or STOP the profile? 3. DCP setpoint programmers The DCP102 is either a Yamatake "setpoint programmer" (runs 1 of x internal preconfigured ramp/soak setpoint profiles and can run the associated PID control) sold by Honeywell as a private label or a Honeywell France import.  I can't remember, but I suspect the latter because the configuration uses letters and truncated words, as opposed to Yamatake's love of numerical codes ("function 17" instead of "Inp 1 Type") A DCP 100 spec sheet dated 1996 says, "RS485 ASCII serial communications", (which is table 4, code #1 in the model number).  It is not likely to be Modbus ASCII.  The user manual does not cover communications and I never had manual for the ASCII communications.   A numeral 1 in the model number says that these DCP102 had the 485 ASCII comm card. A different, undated, but later DCP100 model selection guides shows that Modbus (RTU/485) was available only on the DCP10T model, not the DCP102 model. The Yamatake DCP's never ran Modbus RTU or Modbus ASCII protocol.   4.  Summary This is really, really old, obsolete stuff.  If it fails, Ebay is the only source of a replacement. What tasks are communications supposed to support/implement?  Select and program and RUN?  Generate ramp/soaks?    How much time can you put into writing drivers for proprietary ASCII protocols (plural)?  Do you even have the manuals?  

The tags are usually based on ISA standards.  You can see the tables for ISA codes here: https://instrumentationtools.com/isa-codes-symbols-for-process-instrumentation/ UV transmittance is not widespread enough to warrant its own category like temperature (T) or pressure (P).  It might be considered an Analysis (A). There is provision for using a key table for defining exceptions. Why not UVTT or UVTA for UV Transmittance, Transmitter or Analyzer? If I read UV anything, I'd immediately associate it with Ultraviolet something.