DanW

  1.  Did the HMI ever communicate successfully with the CPU, or is this a commissioning/start-up problem? 2.  What HMI instruction faults the HC900 CPU? 3.  Which version firmware is the HC900 CPU running? 4.  Which hardware comm is for CPU/HMI comm?  Ethernet or RS-485? 5.  Is the HMI the Modbus Master, HC the Modbus slave? 6.  Are the CPU’s genuine Honeywell, or the fake, knock-off made in India models?

If the pump doesn't pump water or the heater doesn't turn on and heat, then you need to determine whether the pump or heater is faulty or whether the control circuit that tells the pump to run or the heater to turn on can be the reason those things do not turn on and do what they're supposed to.  

> only when filling the water chamber. Is the radar positioned so it shoots through partially through the fill stream? Does the fill splash onto the antenna? Does the fill create turbulence like waves or agitation ?  Is the algorithm one designed for turbulence (which does not reflect the beam energy straight back up) ?

Water has a high dielectric so it should be a no-brainer application for radar, but non-contact radar is complex so the fault could be any of a dozens of reasons.    Diagnosis, remediation and root cause analysis require data.   Data for top mount, non-contact radar level includes stuff like - as complete a description of the fault/failure that can be compiled - accurate dimensional sketch or drawing or annotated photos of the installation with respect to geometry (slopes and angles) of the tank ceiling, nozzle, walls, interior structures and its fill/empty ports, radar mounting (angular aimers, flange/screw thread), antenna purge - written narrative on the process: temperature, pressure, atmosphere, mixing/agitation, -when, where and how it fills and empties, condition of the interior of the tank (steam?  dust?  rats?) - written record of the device model number, technology, beam angle, blanking zone distance for that device, range and accuracy - device's spec sheet and operating manual - written record of the existing setup (parameters, as found) - written report of device diagnostic log - screen shots of the echo profile at various levels - maintenance history - written notes on periodic inspections of the process side of the instrument - condition of the antenna for water, dust or material deposits - recorded trend charts of the level at a fairly high sample rate so that you can analyze the frequency, duration and time of the faults, to analyze whether the faults are event-related. A skilled (factory) technician with field experience for that manufacturer might be able to identify some probably causes and provide some remediation.  

see this thread covering the aspects of serial printing, then one adds the wireless on top.  It's a project. http://forums.mrplc.com/index.php?/topic/18102-slc-503-to-print-tickets/

I've never used BacNet but if you're familiar with it, why not?  The alternative is probably Modbus, but why switch mid-stream if you'd had success with Bacnet in the past? I have seen several comments on Linkedin from those in the HVAC world who are migrating, when possible, to Modbus from Bacnet because of issues with inter-operability of Bacnet produc', but having to experience, I can't comment. If you consider Modbus, RTU over RS-485 has an inherent issue with grounding and might require an RS-485 repeater Isolator to eliminate ground loops between points at long distances, where the earth grounds are at different potentials.   Ethernet is inherently isolated by design, although the spec for distance is 100m, although the signal doesn't die at 100m, you're on your own as to whether it works and how well beyond that point, so people put in a switch as a repeater at 100m intervals.

From experience 15 years ago with a SCADA version (Plantscape) of the DCS software, I feel fairly confident asserting that without a valid license code, Experion DCS software has no trial period at all therefore zero functionality; meaning that limitations are total.  I’m fairly confident that the software will not even install without a valid license code. 

1.  The 4-20mA signal is converted to a voltage for the analog input on the Arduino to read it properly. Ohms Law says that 4.0mA current through a 250 ohm resistor drops 1.00 volts (E=I*R) 20.0mA current through a 250 ohm resistor drops 5.00 volts (0.20A * 250ohms = 5.0V) When 4.0mA current passes through 237 ohms, then the voltage drop is:   0.004A * 237 ohms =  0.948V. Not having exactly 250 ohms makes your reading low. 2.  You need to know what the scaling or range is for the temperature transmitter.    4.00mA = x Deg F or y Deg C 20.00mA = x Deg F or y Deg C 3.  Your calculations for what resistance is make no sense whatsoever.   > I got the values from an online pt100 table for resistance and tabulated them from 0-110C in 10 deg increments and for the corresponding resistance using:  nADC = 1023 * ( 237Ω/(237Ω+Rpt100)) The Arduino 'sees' only the mA current signal from the temperature transmitter and the voltage drop it creates across the analog input.   That signal could be relative humidiy, velocity, flow rate, pressure, temperature or about 100 other process variables. Your calculation has to interpret the voltage drop seen at the input and scale that voltage drop for temperature. You can only do that when you know for certain what the range of the temperature transmitter is (see item 2, above). 4.0mA = x deg F or C 20.0mA = x deg F or C. If you don't know, then you can estimate the range with freezing water and boiling water. Make up an icebath of crushed ice and a little water and put the RTD in the ice bath.  That's close to 0 deg C or 32 Deg F.   Measure the current output with a milliampmeter and record it. Boil water with the RTD in the pot.  Try to keep transmitter out of the heat.  Measure the current output when the water boils. Post the resulting current values here and I'll help you calculate what the transmitter is ranged for.

I will freely make the statement that OPC UA will NEVER work with an unknown PLC with unknown data registers and unknown data properties. You can't even get OPC DA to work with an unknown PLC with unknown data registers and unknown data properties.  Hardware connection details do not qualify as data properties.   There is zero basis for accomplishing digital communications. The basis for data communication is to know and understand the properties of the field data and then create/use/buy a digital communications protocol and associated bus hardware to accomplish data transfer and whatever software/firmware is needed for data interpretation at the other end. The lack of understanding and knowledge about the data and its propertied precludes/exludes/eliminates the reasonablness of  attempting any type of digital communications. As to unreasonable expectations, I like the signature line of a water processing expert - "Any water can be made potable if you filter it through enough money".    The same applies to any task, but is it worthwhile compared to the alternative - outright replacement?  

Every yard sale I've ever been to has a box of junk including an old mechanical residential wall thermostat; probably working, just replaced with a programmed setback type. As long as the temperature range is adequate, then use a residential thermostat.  If the temperature range is outside that of a residential T-stat, there are dozens of cheap single loop temperature controllers with a relay output that will run on-off like a thermostat.   You'll need a foot of J, K, or T thermocouple wire, too.  All are powered devices, but so is your PLC.  Ebay is your friend. Many are sold by people who have no idea what they are, so it's up to you to know what you're buying.  You need to know how to decode the model number to make sure it has an electromechanical relay that you can use with your PLC DI. 

A 32 bit floating point consists of four 8 bit bytes, each represented by two hexadecimal characters. The actual total value, 147082 (decimal) is 0x480fa2c0 in 32 bit floating point. the 1st byte is 0x48 the 2nd byte is 0x0F the 3rd byte is 0xA2 the 4th byte is 0xC0 The first byte value 0x48 makes a low 6 six digit value in the 100,000's in 32 bit floating point   substituting a value 0x47 for the first byte reduces the total to well below 100,000, down to 37811. Although there are four accepted formats for floating point word and byte order and most common issue in getting the correct value is getting the words and bytes in the correct order, the problem here is that the value you provided from the ladder logic has no byte value close to 0x48 to get a 32 bit floating point total into the range of 100,000. Your ladder logic value is 15598 17316  decimal 15598 converted to hex = 0x3CEE 17316 converted to hex = 0x43A4 None of those bytes is close enough to 0x48 to get you a total over 100,000.  In standard format, 0x3CEE43A4  = 0.029084988 Swapping word order gets the closest value: 0x43A43CEE = 328.476 Swapping bytes gets bizzare: 0x3CEE43A4  = 0.029084988 0xA443EE3C = -4.2485677E-17 Without a ladder logic value closer to what your actual total is, it's sheer speculation whether the issue is word/byte order.

>However, it doesn't list what bits I need to send to the device in order for it to send the PLC the data. I've tried contacting Siemen's (who makes the BGA) and they were useless. RP500 comm manual page 2-7:  Patient Sample Assay Transaction - The analyzer notifies the host (LIS) that a patient sample analysis has begun or been cancelled. - Host acknowledges - analyzer notifies host that new patient data is available - host acknowledges the msg - host request the data and identifies the sequence number of the requested data - analyzer sends data - host acknowledges

I have no experience with Omron, but from general Modbus experience I have these observations: 1) Master or slave? a) Modbus functionality is sometimes 'native', included in the operating system, but is frequently an option, meaning not every device has Modbus, only those with an option.  Do each device have the Modbus functionality?    Does each device really talk Modbus (not some other protocol over RS-485)? b) A Modbus master can talk to one or more Modbus slaves, a Modbus master can not talk to a Modbus master.     c)  An RS-485 network can support one and only one Master d)  Field devices that are Modbus slaves will always have a 'map' or table' of assigned register addresses where the data resides.  Modbus masters do not have a map or table. e)  Some PLC's can operate as either a Modbus master or a Modbus slave, depending on programming and port assignment.   All that said, a Modbus master does not have a Modbus slave node ID number (1-247), also called station number.   A Modbus slave node ID number (station number) indicates slave functionality, not Master functionality. In the link you provided (for NB7W), the PLCs are functioning as Modbus slaves, as evidenced by two PLCs on one Comm port and each has a 'station number'.  Only a Modbus slave would have a station number.  Modbus Masters do not have station numbers.   Presumably the NB7W is a Modbus master, which is typical for HMI devices when used with PLCs. That means your weighing indicator must be a Modbus slave to communicate to HMI (a Modbus master) as shown in the setup in the NB7W link provided.  However, generic digital indicators typically have a Modbus slave 'option', although Precision Digital makes a "Modbus indicator" that can be a Modbus master.   I do not know the typical functionality of a 'weighing indicator'. If you want to connect the HMI, a Modbus master, to your weighing device then your weighing device must be a Modbus slave. Is your weighing indicator a Modbus slave? 2)  RS-485 issues a)  The drive lines for RS-485 differ in labeling from manufacturer to manufacturer.  While, electrically, (+) wires to (+) and (-) wires to (-), sometimes one manufacturer's (+) is the other manufacturer's (-).   Connecting the drivers backwards will not damage the lines, but RS-485 (and Modbus) will not function.   Try swapping the lines to see if the lines are labeled differently. b)  RS-485 should have a 3rd wire, a signal ground.   But many manufacturers do not supply a signal ground connection. c)  Termination resistors (typically 120 ohms) are installed at the devices on the two ends of the network, usually the master and then the last slave.  Short cable lengths at low baud rates (9600, 19.2K) will almost always work without resistors. d)  Just the presence of an RS-485 port does NOT mean that the device talks Modbus.  Modbus is a protocol, RS-485 is a communication link.  If a device talks modbus, its documentation will specifically state Modbus functionality.  3)  The Modbus master has to be configured/programmed to poll for the data from the slave Have you configured the HMI to poll the weigh indicator for the data?

Walt Boyes reports that Dick Morley, the father of the PLC died on October 17th. http://www.spitzerandboyes.com/a-legend-passes-dick-morley-died-today/ Wikipedia has been updated and summarizes Dick's contribution to the automation world: "Richard (Dick) Morley (died October 17, 2017) was considered the "father" of the programmable logic controller (PLC) since he was involved with the production of the first PLC for General Motors, the Modicon, at Bedford and Associates in 1968. The Modicon brand of PLC is now owned by Schneider Electric. The PLC has been recognized as a significant advancement in the practice of automation, and has an important influence on manufacturing industry." https://en.wikipedia.org/wiki/Dick_Morley An article gives some history of the process Dick went through in the early days https://www.automationmag.com/features/the-father-of-invention-dick-morley-looks-back-on-the-40th-anniversary-of-the-plc.html

The valve is the chunk of metal or plastic in the line that regulates the flow. The actuator is what drives the valve open or closed. An actuator driven by two 24Vdc discrete outputs is likely an electric actuator. Here's an example of an actuator driven by two AC discrete outputs. https://postimg.org/image/vg2qoudr7/  (the forum's "insert other media" doesn't work for some reason) The actuator functions like Bryll describes: powering one output "increases" the valve position (opens); powering the other output "decreases" the valve position (closes). When neither output is ON, the valve position is stationary, it remains at its last position. The diagram shows a slidewire feedback so that the control system knows what current valve position is.  The absence of valve position information is 'open loop control'. The control logic has to be written so that there is no circumstance where both outputs can be ON at the same time. One has to consider what happens on Start-up when the valve position is unknown.

In Modscan32 you need to use the address 14193, because Modscan 32 address is decimal, not hexadecimal 0x3770 = 14192 decimal Since hexadecimal addressing is usually zero based, and decimal addressing is usually one based, the 3770 (hex) register is probably at 14192 +1 = 14193 (decimal) Note that the format for displaying values in Modscan can be changed from binary to hex to integer or floating point, but the address is always a decimal number.  

I spent about 10 minutes looking for documentation for this system.   There is no documentation on the US Honeywell web site (see statement at the bottom of the screen shot of the search engine): https://s23.postimg.org/g3h5pdvqj/no_documentation_on_US_site.jpg I found several data sheets but no manual. I found one reference to it being a German product. I found lots of references to it being BACnet enabled, but only short cursory references to its Modbus capability. The question in my mind is whether it is a real product of vaporware product or a short-lived now obsolete product.  Any commercial device that returns no Google search hits for "manual" doesn't seem to have much of a market presence. If Modbus is real for this product (which is real?) then there has to be some documentation, but 10 minutes didn't bring up any. In general, you need documentation to figure out Modbus.   PLC slaves frequently need to map specific tags or points to Modbus registers. Honeywell's industrial HC-900 Process Automation Controller has a fixed Modbus slave map where each function block is assigned slave address registers, or one can custom map each and every point.  It's an either/or situation, one does fixed or custom, but not both at the same time. Wireless systems frequently allow custom mapping of tags to registers.  But you have to know that and how to do it. Sorry I can't help. but Honeywell hasn't begun to make it easy to use this particular beast. I'm putting this one in my folder called, "Just because it's Modbus doesn't mean it communicates". http://forums.mrplc.com/index.php?/topic/32683-honeywell-dcs-with-schneider-citect/    

See my lengthy introduction to Modbus in this thread (4th post down): How do you know the PLC Modbus slave register is 450001?  Where did that register number come from? The PLC has to be configured as a Modbus slave with a slave node ID number (maybe it defaults 1, sometimes 247, who knows?  You need to look it up and determine what the slave ID number is. You need to research how to set up your HMI as a Modbus master.  It's somewhere in the HMI documentation, it has to be because an HMI has no I/O, it has to read its data digitally from some device. You need to setup the serial settings on both devices to be the same (baud rate, 8 bit word, parity). You need to dig out the wiring connections for the RS-485 connections.  A to A, B to B or + to +, - to -, unless one of them does it backwards, which happens more than it should.    If it's 4 wire RS-485, the jumper + to +, - to -.   You should connect signal ground with a 3rd wire. If you can test  on the bench it's a lot easier than running back and forth. I'd use a generic Modbus master to read the PLC's value first to confirm that you can actually read data from 450001 and interpret it (integer, floating point, long integer, whatever format). Then start working through how the HMI reads a Modbus value.    

Non-floating I/O modules are the ones that have problems with ground loops due to the difference in ground potential between where the field source device is powered and where the PLC is powered.   One connects a signal with too much common mode voltage and there's an offset or the signal is driven offscale in either direction (depending on the polarity of the ground differential).    That's why Siemens says everything must be equipotential - no ground potential differences.   Easy to print in a manual, ink is cheap and maybe there's a plant somewhere that is equipotential (the old NORAD radar sites were probably equipotential given the effort to install and maintain ground planes) but I'm not sure I've been in one.

This is now a four year old thread, but given how threads come up in searches I'll give an answer: >"Which would be preferreable - compact logix, square root, two press trans, or a differential pressure transmitter? Is there a difference in accuracy?" 1) Two or one transmitters Whether measuring pressure drop across a flow element or a filter, one always, ALWAYS, uses a differential pressure transmitter, one with two ports, and high side and a low side. Using two separate pressure transmitters is folly.  The combined error can put you in the 10's of percent error.  In fact, at low flow, the errors could combine arithmetically to indicate reverse flow, because the basic calculation is high side minus low side.  The nature of percent full scale accuracy means that the error increases as the signal approaches the low end of the scale and is greatest at the low end.  If the low side transmitter errs on the high side and high side transmitter errs on the low side, the subtraction of the two could drive the result negative, for low DPs. 2)  where to extract the square root Differential pressure transmitters accuracy is spec'd on the DP, not on the line/static pressure, which is what would be used with two separate Gauge pressure.transmitters. The instrumentation world is divided as to whether the square root should be extracted in the transmitter or the receiver (PLC).  I favor square root extraction in the transmitter because a) it's the most accurate, it's internal to the transmitter, b) the output signal is linear over the range of determined by the sizing of the primary flow element (the orifice plate). But there are lots of others who extract in the receiver.  An all too common problem (for people who should know better) is erroneous double extraction, in both the transmitter and the receiver. 3)  flow across a control valve If getting accurate flow rate measurement across a valve was feasible and reasonably easy, lots of people would do it.  Not only could one avoid the cost of a primary flow element and its installation, measuring flow across a valve would avoid another process pipe intrusion.   It would be a popular measurement technique.   But it isn't easy and I can't even recall where I've ever seen that done and I'm an instrument guy, that's what I do.   A major problem with measuring across a valve is flow profile.   Established DP Primary Flow elements, orifice plate, venturi, averaging pitot tube, or nozzle all require fairly extensive straight pipe upstream/downstream in order to develop a flow profile at the DP element.   Valve manufacturers design valves to create pressure drop which takes energy out of the system, valves are in now designed to create a clean flow profile suitable for measurement.  All sorts of phenomena will affect the flow profile (if there is one) and the subsequent DP across a valve, like Mr. Lloyd mentions. Primary flow elements used for flow measurement are over 100 years old with lots of supporting data for the relative accuracy claims.  Probably the least expensive primary flow element including installation is the Averaging pitot tube.   Any of these beat the task/effort to characterize flow across a valve and its questionable reported flow rate.        

There's nothing inherently wrong with bimet thermometers - they need no power and process grade models are good to plus/minus 1% full scale.  The problem is relying on the value it shows without knowing how good that value is.   Even if it was another instrument with a sensor like an RTD or thermocouple my question would still be, how do you know the reading is accurate (enough for your purposes)? Industries where accuracy is important (pharmaceuticals, for instance) have spares of sensors/instruments like RTD's or bimets that are periodically checked for calibration to see how much error is indicated.  Those that 'pass' are exchanged for ones in service, so that there's a degree of confidence that the reading is good.  

1.  RTD types     2 wire RTD's have a constant offset error due to lead wire resistance.     3 wire RTD's are probably 97% of the industrial marketplace with sufficient accuracy for industrial use.     4 wire RTD's are for critical accuracy applications like BTU calcs when accurate measurement for invoicing/billing is involved or for laboratory use.  Most transmitters all 2.  Temperature transmitter I cannot find a Baumer model 2201 in a quick web search.  The 2202 is a 2 wire loop powered, blind (non-indicating) RTD temperature transmitter (sometimes called a hockey puck in North America). It appears to be a modern competitive unit that is highly likely to work out-of-thebox when wired and configured properly.  My experience says that the probability of a fault or error is very low.   But, there are several things that can make you think the transmitter is in error. If you wired the 3 wires as shown and you get a 4-20mA signal, then the transmitter probably working OK. The 4-20mA output represents a specific temperature range.  The default 2202 output range is 0-120 Deg C (32 - 248 Deg F). The receiver (PLC/controller/indicator analog input) that takes the 2202 4-20mA output must be ranged to the same range (and units) as the 4-20mA represents. Is your transmitter also ranged 0-120 DegC (factory default) or some other range?   What is transmitter's 4-20mA connected to?   Did you configure that for 0-120 Deg C? Mismatch between the temperature represented by the transmitter output by the receiver is the most likely source of error. 3.  Error of 10 Deg C Dial indicator shows 25C, Flextop shows 35C, an error of 10 Deg C a)  The dial temperature is probably a bi-metallic thermometer?   How do you know it is giving an accurate value?  You're using it as a reference.  Why can you trust it?   Many bimets have an offset (screw) adjustment on the back that could have been bumped.  If the probe has been bent, a bimet will indicate a false temperature due to the distortion of the mechanical linkage from the spring to the dial.   In other words, just because the dial shows some temperature, how to do you know it's valid? b)  Is the dial measuring the same physical point as the RTD?   Temperature is not the same everywhere in a process.   Even in an office room, there are temperature gradients in elevation (floor is cooler than the ceiling; door gaps allow outside air at different temperature).  How close are the probes to one another and what exactly does each 'see'? c)   What influences the heat transfer at that point? Both devices have some thermal lag.  But lags are on the order of fractions of a minute. On a bi-met thermometer, heat transfer has to penetrate the probe sheath, saturate the entire length of the bimet 'spring' to drive the dial.    On an RTD, the heat transfer has to penetrate the probe sheath and the MI insulation powder used to electrically isolate the RTD element from the sheath.   But the surrounding area that heats or cools the probe can have a dramatic effect on response.  Insertion into 100Kg of steel that has its own slow thermal response is different than insertion into a tank with agitated liquid (about the fastest response). 4.  slow to react. The 2202 transmitter has adjustable damping, meaning the values are filtered or averaged over time to reduce a fluctuations that produce a jumpy/noisy output. The damping time base is 0 (no filter) to 30 seconds (heavy, heavy filtering).   The spec sheet does not say what the default value is.   A highly damped signal will take some time for input (RTD temperature) changes to be seen at the output (4-20mA).

1) Modbus is a Project Modbus is NOT plug-n-play; it is always a project.  It is not feasible to provide details about specific connections between this brand/model to that brand/model because of the number of possible combinations of the 100,000 Modbus-enabled devices out there.    2) What is Modbus? Modbus is a protocol, the set of rules for who talks when (who is silent), rules for packing the data, how to tell when transmission starts, when it ends, what constitutes an error.   Modbus does not define what kind of data is transmitted nor does it define the format of the data (the product vendor defines the data format).   Modbus has a specification for serial communications, which in some cases is ignored despite explicit requirements. 3)  ASCII vs RTU vs TCP Modbus ASCII was widely used when telephone modems were used for the serial network link and it has very loose timing requirements, which fit the realities of modem communication.   It is NOT human readable ASCII, it uses binary values of the ASCII characters representing the hexadecimal characters that represent the 16 bits of a Modbus register.  The following ASCII string shows a Master query request to slave 17 for the analog output values in 3 holding registers starting at (4)0108 to prove this "non human readable" point:        : 1 1 0 3 0 0 6 B 0 0 0 3 7 E CR LF Modbus ASCII takes almost double the number of bits to communicate the same amount of data.   In my opinion, the use for Modbus ASCII is in wireless which has many of the same timing delays that telephone communication had 25 years ago. Modbus RTU is the dominant protocol used nowadays for serial communication over RS-232 point-to-point up to 15m or RS-485 for multidrop up to 1200m.  It has much stricter timing requirements that usually don't offer a stumbling block.   Modbus over Ethernet is referred to as Modbus/TCP. Ethernet, by design, has isolation, so it has a huge advantage over RS-485 which does not. Ethernet, by design, is limited by spec to 100m of cable.  That can be exceeded in non-critical applications but it needs to be taken into account.  Extension by switches is feasible Ethernet, by design, has standardized connectors with standardized wire connection.   Plug in the commercial cable and it works. Ethernet, by design, supports infrastructure above and beyond the 485 multidrop limits. If I have a choice, I'll use Modbus/TCP over Ethernet because it is usually easy to setup and get connected. 5) RS-485 RS-485's problems are - 2 wire 485 is a misnomer.  A signal ground is needed.  So 2 wire 485 is really 3 wire 485.  But many products do not have a signal ground terminal. - lack of a signal ground terminal so grounding devolves to case ground connections which has the issue of creating a common mode ground loop.  Ground loop problems are solved by adding an isolator module. - RS-485 lacks isolation from ground   - where does the bias come from or what is the access to the supply voltage or ground if a bias resistor is needed?  Mostly a mystery unless the system is designed from the ground up, like Profibus DP, which takes biasing and termination into account. - no industry standard on data/drive line labeling (A/B, (+)/(-)).  Backwards connection does not damage the lines, but will not work.  Annoying, but easy to fix by swapping the lines. - field implementation with cable that is not specifically communications cable. - field implementation with spurs or a star topology which 485 can't handle - Most Modbus masters cannot handle duplex (4 wire) communication so simplex (2 wire) works for the master/slave sequence in Modbus. implementations of slave node ID address and serial comm settings (word size, baud rate, parity, stop bits) is all over the map.  Some mechanical (DIP or rotary switches or jumpers); some firmware setup. 6)  Who is Master?  Who is Slave? A drive is always a Modbus slave.  So the PLC has to be the Modbus master. Which network will you use?  RS-485?  Ethernet? You need to check into what firmware/hardware/licensing is needed to get a Modbus Master for the hardware network you need to use.  It varies from vendor to vendor. It pays to check the Modbus documentation.  Is it 1/2 a page or 20 pages with examples?  It's what you'll have to work with.   7)  Slave A slave is always silent until it is spoken to and then it interprets the master's command and either accepts data to be written internally or replies with the data requested. The slave documentation needs to - specify which Modbus commands (Function codes) it works with - spell out what data is available - at which register address the data resides - the data format - limitations, like a maximum number of values acceptable in one write transaction Slaves frequently do not recognize serial setting changes until the power is cycled All slaves need a unique network node ID address number 8)  Master Master Tasks - The master has to issue the instructions (Function Codes) and accept the replies.    - It has interpret the binary bits, sometimes converting from one format to another. - It has to do something with the data the Master receives, typically moving the data to working registers. 9)  Modbus in general A) Register/addressing - the one offset issue. Some devices start register/addressing at zero. Others start at one. So the holding register at (4)0109, might actually be at 0108. The leading numeral in register references, the (4) in (4)0109, is not part of the Modbus message.  It is a convention used so that humans (and some software) can distinguish between memory areas served by different function codes.  For instance, Function code 03 reads holding registers in the (4)xxxxx memory area.  Function code 04 reads input registers in the (3)xxxxx memory area.     I put the leading numeral in parentheses to indicate that it is not part of the message (the register address is part of the message) Some master/client use the leading numeral to designate which Function Code to use. Others require defining which Function code and then (typically) only want the indexed value (minus the leading numeral). B)  Floating point/real values If your slave uses floating point, it is undoubtedly IEEE 754 formatted.  There are 4 different byte orders, but I've only ever seen two of those in popular use.  Somewhere in the master's software there's a setting for whether a floating point value is interpreted straight or swapped byte/word order. If the wrong choice is used the data value will be wildly wrong, like the value 156.32 will be a ridiculous value like 1.26842274 E11. C)  Integer with decimal point Integers (whole numbers) are frequently assigned a multiplier (by the slave's vendor).   For instance 156.32 will transmit as 15632 with an assigned multiplier of 0.01.   The assigned multiplier is not part of the Modbus message, it is defined in the slave documentation D)  Generic master/client I really recommend using a PC based generic Modbus master, something like Modscan 32, Modpoll or Simply Modbus to 'prove' a connection between the master and slave, because of the number of settings that can hinder a working connection. There are few settings in the generic masters. There are other freebie generics out there. Start by reading a known value (non-zero) from a register. Make sure that the value is what you expect, to confirm that you're not reading one register off. Unused registers are frequently zeroed out, which makes zero a bad value to expect. Most PLC vendors seem to have a documented example of setup as a master or slave somewhere on the web. Dan  

Solution on the Siemens forum: https://support.industry.siemens.com/tf/ww/en/posts/intellisys-modbus-com-port-to-db9-cm-1241/162711/?page=0&pageSize=10

I was thinking about this.  I haven't known of a CJ compensator going bad - it's a passive device, a resistor. What is more likely is - the CJ was removed and re-connected improperly (heard that any number of times) - the voltage regulator that creates a constant current source that drives the CJ circuit is bad; a fairly high probability - the sense circuit that reads the the voltage drop that represents the temperature has failed; possible. Any of those options has a higher probability than a bad passive resistor.  I mention this because you could go through all the effort of getting a replacement CJ, only to find out that the error is still there, and CJ is still dysfunctional. I'd be inclined to substitute a resistor across wherever the CJ thermistor is supposed to go and see if the error disappears. With no idea of what the thermistor is, I'd probably start with a 1K, then 2.2K, then a 3.3K resistor and see if any makes the error disappear.  If the error disappears and the indicated temperature increases when the resistor is connected (assuming the T/C is hot) then it says that the CJ device is bad and that substituting some resistance makes the circuit happy, even if it's the wrong resistance.