DanW

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.

input byte 0 = 0000 input byte 1 = 000F The actual Modbus message uses zero-based addressing for Modbus registers, which in this case would be address 00 for input byte 0, address 01 for input byte 1. The development software for the HMI might use one-based addressing, where for Input registers, (3)0001 = address 00 (3)0002 = address 01 It is not clear whether these are Input Register (read with Function Code 04, cannot write to an Input Register), except for the statement, "16 unsigned unteger values are expected as input data." Holding registers are read with Function Code 03 and can be written to using Function Code 16 (decimal, 0x10).   But you'll have to discover whether the listed registers are Input or Holding registers by discovering which function code reads the data and whether you can read write to any particular register with FC 16 (decimal)  

The United Electric Excela line has a digital read-out pressure switch (easy to change setpoint) with a couple wall-mount flanges.  Would that help?  Note that the output is to connect to a PLC discrete input; it is not a traditional pressure switch microswitch with dry contacts. https://www.ueonline.com/products/general-purpose/excela/

Looks like no PCS7 users on this forum.  Have you tried the Siemens user forum at the link below (requires registration)? https://support.industry.siemens.com/tf/us/en/threads/135/?page=0&pageSize=10

Testing with a manually controlled signal generator is not a good test for PID because your signal generator is not responding like the process would respond to the PID output changes. If the output is wired to the I/Ps and the I/P's are connected to the damper and valve, then a signal generator can prove the control direction is correct with rise or fall of the input. It would not surprise me if "PID has locked up" means that the output is stuck at either 100% output or 0% output when the input does not reflect the output change.

Here's what the manual says about HART current ratio (page 62) https://www.quicktimeonline.com/assets/images/pdf/Allen%20Bradley/1794-IF8IH%20User%20Manual%20FLEX%20IO%20Isolated%20Input%20Output%20HART%20Analog%20Modules.pdf There is a current fault/fail-safe limit on most field devices that drives the analog signal upscale beyond the overrange 20.5mA level (like 21.4mA0 or downscale below the 3.7mA underrange level (like 3.3mA).   But the fail-safe limit happens when the transmitter determines that its internal functioning can not report a valid process variable.  It's telling the controller, "my process variable is not trustworthy".   Which brings up the point, what does the HART variable do when the transmitter is in fail-safe fault condition?  If the HART variable goes off-scale, too, of then there's no deviation between the fail-safe analog value and fail-safe HART value. It might be for dealing with a situation where the 4-20mA analog output is a subset of the full range of the transmitter.   For instance, pressure transmitters can be capable of measuring 0-1 bar but can be ranged 0-0.25 bar.  I've never checked for this but it could be that the instrument senses and can report a 0.40 bar signal that would saturate the 4-20mA signal at 20.5mA or thereabouts while the HART signal could conceivably report a reliable 0.40 bar value.  The current ratio tells you that the HART signal is valid but the analog is not ? ? ?   

I've been mulling your question for a couple weeks now because I'd never heard of current ratio in relation to HART. If I interpret your conclusion correctly, the HART digital variable is compared to the analog value and if the analog value wanders or drifts beyond the percentage limit, then current ratio alarm is triggered. The analysis function would have to be smart enough to know what the 4-20mA signal represents, in eng. units, in order to make a valid evaluation and the card is probably smart enough to know that.   But what if the HART variable is the secondary or tertiary variable, not the primary variable?  Then there's no direct correlation between the analog value and the HART value. And, what's the purpose?   Detecting drift between the digital and analog variable?    When I started this field in the late 1970's, the analog (non-smart, zero and span pot) pressure transmitters would drift several percent in 6 months, necessitating periodic re-calibration.  But the electronics have improved so much over 40 years that today's' 4-20mA's don't drift much, if at all;  they're remarkably stable, and they don't typically drift to the over 5% range.   There is a possibility of ground loops occurring and although that's usually detected during installation, events like the moisture intrusion into junction boxes over time can create a ground loop or increase the magnitude of a ground loop.  So analysis could detect a ground loop affected current signal that doesn't match the HART variable.  So an analysis might catch a ground loop error. But I suspect that the current ratio refers to signal strength, noise or signal to noise ratio of the HART signal. A web tutorial/primer on dB (deciBel) states: Typically the deciBel, dB is used for defining amplifier gains, component losses (e.g. attenuators, feeders, mixers, etc), as well as a host of other measurements such as noise figure, signal to noise ratio, and many others. https://www.electronics-notes.com/articles/basic_concepts/decibel/basics-tutorial-formula-equation.php and the primer continues on to mention current ratios. So I suspect that the current ratio is a means of determining the signal strength of the HART signal, an FSK voltage superimposed on the mA current signal. But how that works out to percent and what the practical real world implication is, is beyond me.

The panel under consideration has a compressed air supply of 120 PSIG which runs through some Parker N 1/2" OD nylon tubing rated to 250 PSIG.  Parker Prestolok Push-to-connect tube fittings are used throughout.     Should one of the tubes fail or the seal on a push-to-connect fitting fails, the supply air would leak out and fill the panel.  I assume that that door gasket would leak at some point, probably leaking at the same rate as the 'fault' or the door gasket would tear, opening a gap that exhausts/vents the pressurized air from the enclosure.  But this is speculative on my part. Is it a standard practice to install a relief valve to open and vent compressed air in the event of a air component failure inside the panel?

There are stand-alone single circuit calendar timers that operate on sunset/sunrise that are intended for lighting purposes.  The one I saw fit in electrical wall box.  I saw the electrician messing with the configuration.  It came in a retail box with printing on it.  Sorry, I didn't catch a name, brand or model and since I didn't buy it, I don't its cost.  But maybe the cost of loal timer control would be offset by the extensive wiring needed to do central control. 

short answer, from a Honeywell authorized distributor. For years, the HC-900 development software was called Hybrid Control Designer (HCD) but is now called ControlEdge HC900 Designer (not to be confused with ControlEdge PLC Designer, an altogether different platform).  The current Version 7 is backwards compatible through all previous versions,  Be aware that there is a 'utilities' version that only allows setpoint programming batch edits; other logic can not be edited.   There is separate software for Honeywell CS900/CR900 branded HMI panels called Station Designer. Both are licensed products, available only through Honeywell authorized distributors. Also be aware that an HC-900 CPU has optional password security that if enabled, must be dealt with. Updates within a version are still free downloads from the Honeywell public web site, but will not install unless a licensed version is detected.   (software tab at this link). https://www.honeywellprocess.com/en-US/explore/products/control-monitoring-and-safety-systems/Scalable Control Solutions/ControlEdge HC900 Process and Safety System/Pages/ControlEdge-HC900.aspx All the manuals are downloadable from the documentation tab at the link above. Delivery of licensed software is either an electronic download or a DVD.  The DVD costs more. Honeywell contact information for the Americas, who can presumably put you in touch with a distributor: Honeywell Process Solutions (Sales) 1-800-343-0228   Email: (Sales)    FP-Sales-Apps@Honeywell.com