DanW

MrPLC Member
  • Content count

    272
  • Joined

  • Last visited

Community Reputation

9 Neutral

1 Follower

About DanW

  • Rank
    instrument guy

Contact Methods

  • Website URL http://
  • ICQ 0

Profile Information

  • Gender Male
  • Location Midwest, USA
  • Country United States

Recent Profile Visitors

4026 profile views
  1. PT100 on Arduino Mega Industrial Shields PLC

    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.
  2. OPC & PLC Integration

    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?  
  3. Temperatre Sensing

    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. 
  4. 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.
  5. >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
  6. HMI and Weighing Indicator

    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?
  7. 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
  8. Control Valve

    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.
  9. ModbusComm

    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.  
  10. Honeywell DCS with Schneider Citect

    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/    
  11. 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.    
  12. floating and Nonfloating I/O modules

    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.
  13. DP Flow Measurement

    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.        
  14. Temperature Transmitter Configurations

    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.  
  15. Temperature Transmitter Configurations

    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).