DanW

MrPLC Member
  • Content count

    307
  • Joined

  • Last visited

Community Reputation

20 Excellent

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

4739 profile views
  1. 50+ Thermistors on PLC

    Presumably you want temperature units. There are not a lot of resistance-to-4-20ma transmitters that linearize to a thermistor curve.  The one I know of is Acromag's TT230, a single channel thermistor transmitter that has "Customizable thermistor linearization table with preset curves for popular resistances".   A PAC I use has an 8 channel RTD input card that has several straight resistance input ranges, 0-200, 0-500, 0-1000, 0-2000, and 0-4000 ohms with programmable look-up table functionality for conversion to temperature units. I suspect that most RTD input cards have some configurable resistance input option, but you'd have to investigate. Considerations when using a multiplexor Synchronizing an external multiplexor to the input scan of a PLC could be a challenge if the Mux is not driven by an external pulse.   A mux's solid state switch (as opposed to dry contact switching) might not be designed for switching resistance and affect the measurement.
  2. OMRON CJ2M-AD08V1 - AD data fluctuation

    That will certainly work but now you have to activate 2 switches. 13/14 is SPST.  If it were SPDT with another terminal for the open position (as shown), say 13/14/15 then with only one activation you could ground the input through the unpowered 10K pot which is effectively a grounded input which should give you zero volts (I'd try it just to make sure that is doesn't draw a bias current somewhere and give you an offset).  
  3. OMRON CJ2M-AD08V1 - AD data fluctuation

    Apparently a high value during the open circuit state is not acceptable?  What is acceptable, zero volts? Your AI will show 0 volts when shorted. What about using a SPDT switch where the terminal shown as the open switch state connects to the AI (+) input, so that when the switch is open the AI (+) is shorted to V (-), but when switch toggles the AI reads the pot voltage drop as shown?
  4. There is a category of software for dealing with process data from controllers known as HMI software.    HMI software is designed to talk to controllers through Modbus or OPC, get data from a controller/box via Modbus or OPC, put data into a database, trend the data as Y-t charts, and since it's usually a Windows app/service, it has the power to do custom programmed analysis. Every PLC vendor has their own branded HMI softare, then there are 3rd party HMI software vendors like Wonderware, Advanced HMI, Ignition, or Indusoft that are OPC clients out-of-the box, so they talk to OPC servers.    The OPC client will most likely have Modbus driver in its OPC client.  If not, one buys the Modbus license for it. The software package is a toolbox of development software, a blank slate that needs to be programmed.   One buys a run-time license for the developed program.   But none of the generic HMI software packages come with pre-programmed, high level software analysis of process (vibration, in this case), that's the job of the integrator/programmer.
  5. OMRON CJ2M-AD08V1 - AD data fluctuation

    1. Why are there switches (rectangle with a lever arm is a switch?) in an analog input circuit ? 2.  Are these 8 signals current signals or voltage signals? 3.  What are the field signal generators?   pure current through a variable resistance?   output of a transmitter?   4.  What is an A/L screen?  If it's the cable shield, then connect it to chassis ground, not to the AI (-) 5.  The video appears to show some high count value toggling with the value 0.  Is that a correct interpretation? Is that happening with the switches in the open state? If the switches close, what happens?
  6. OK, now I have a better understanding your thread title, "How to make a PLC Device accept data exported from Application Software." Vibration is one of those vertical knowledge categories that is so 'expert' related and sophisticated that I consider a category for which Artificial Intelligence might bring some value.   Ordinary people do not have the experience to interpret changes-over-time of frequency domain FFT charts (nor do most have the desire).   After sitting through a Bently Nevada presentation some years ago, it impressed me that the analysis of vibration and its related data is something for dedicated, expert, specialized software that relies on expert knowledge and years of experience in the field. As I mentioned before, a PLC is real-time industral controller, it is NOT designed as an analysis platform.   This forum or another like once had a thread asking about trying to do FFT's (Fast Fourier Transforms, time domain to frequency domain conversion, a key element in vibration analysis) and the response was, no! a PLC is the wrong platform for running FFTs. If the application software is sophisticated enough to determine that a motor should be shut down, then writing a value to a PLC programmed to recognize that value and interpret the value as "shut down motor #x", then a PLC brings some value to the party. But if the application software already generates a report that tells you "conditions at motor #x reflect the need for shutdown and maintenance, maybe even to the level of "maintenance on bearings 13B and 14A", then it takes human beings to implement the sequence of tasks needed to do that, sequential steps like - scheduling  (when can the motor and what it is driving be shut down) - checking inventory for the needed parts (bearing, gaskets, whatever) and ordering if need be (and how does that affect scheduling?) - issuance of a work order and who does the work (contractor, staff?) - motor shutdown - LOTO - actual work - barriers, wrenches, pullers and the guys who do that all of those steps involve humans doing things that PLC's don't do.  The PLC might only be involved in the shutdown part; PLC's do not issue work orders or check inventory. So, what kind of data is the app software exporting? A.  Data that needs further analysis (probably a task for more sophisticated software, not a human, unless you've got vibration experts on staff)? If you need data exported for further analysis, then you need to find such expert software that includes an OPC client that can talk to the OPC server in the dedicated box.    B.  Alarm data that needs to be annunciated (something a PLC would do as an intermediary to the actual annunciator (light, horn, bell) If the dedicated box does analysis that can issue an alarm that means a failure is imminent and an alarm needs to be annunciated, then either Modbus or OPC could conceivably write a value to a PLC that the PLC (when so programmed) would interpret as an alarm for which it turns on an output connected to a horn/light/siren or even sends an email. C  something else? You select a server for server tasks and not a work station.  This is a similar situation - what is the data and what task has to be done with the data?  Previously I said, "the people who sell the high value data analysis software (your dedicated box) make it quite clear about what is needed as input for the software and what it needs to run with.   Now I have to ask a modified version, "the people who sell the high value data analysis software (your dedicated box) (should) make it quite clear about what data is available for export and what is available to export the data. At a minimum, you need to figure out what kind of data is coming out of the dedicated box and what needs to be done with that data - does it need a PLC or some other software?  To some extent you know there is OPC and Modbus, but you need more particulars: Does the dedicated box have - OPC DA server (older, more common version? - OPC UA server (more recent version)? - Modbus connectivity through Ethernet (Modbus/TCP)? - Modbus connectivity through RS-232 or RS-485 (Modbus RTU)? Is the device a Modbus client/master? or is the device a Modbus Server/slave? A server/slave (almost) always has a table or map of numbered registers that are used to call the data in that register.  Some very sophisticated server/slaves have a custom programmable table/map that the programmer populates with the needed data. Modbus is useful only for nearly realtime data points.  Although the Modbus specifications include some commands for block data transfer, almost no commercial devices implement those commands.   Those commands might be used by a proprietary software, but then you, the user, don't even need to know its Modbus, it's just the protocol used by the software. OPC has had some means of moving blocks of data, histories, but I have no direct experience in implementation of such, so I don't know how well it works or how wide spread those functions are.
  7. Analog sensors connect to the conversion device directly.  The conversion must have I/O capable of handling the analog signals. If the field sensors are not analog but use an industrial protocol (Modbus, Ethernet/IP, Profibus), then an OPC server could probably talk directly to the field device, but it is more common to get data into a PLC using the industrial protocol and then talk to the PLC through OPC. OPC or Modbus could be used between the conversion device and PC application software, assuming the application software has a access to an OPC client that can get data from an OPC server or a Modbus master/client.   Or an OPC server might be used to get data from the conversion device directly to a database, which the application software uses. OPC and Modbus are both bi-directional, so results of analysis can be sent back to a PLC for control/alarm action. 1.  There is no step-by-step procedure for a project of this complexity.   2.  With enough time and money, anything is possible.   The industrial world has done tasks like this (sensor data > PLC > analysis app) for decades now. 3.  This a question for the PLC/SCADA device vendor. A given PLC/SCADA device determines which communications protocols it handles (many times an option), which is brand/model specific.   If a PLC/SCADA handles a given comm protocol then its development software would have the means to deal with the comm setup and handling the comm data.   The interaction between application software and a PLC is almost certainly a custom programming job, which is what 'systems integrators' do for a living. 4.  Freeware I think most OPC servers will run for 2 hours in demo mode before they need to be reset, which is the development/test mode for the OPC server.  A run-time license would need to be purchased for the OPC server to run unattended.  But be aware, the purpose of an OPC server is to communicate the data to an OPC client, which needs to be associated with the application software.   One generally assumes any OPC server communicates to any OPC client, but there are freeware OPC test clients, also. There are freeware Modbus client/master and server/slave programs of limited functionality.  They are useful for testing but I'm not sure how valuable a Modbus test program is in the scope of this project. Direction PLCs make real time decisions on input data and change their outputs for control purposes - turn on a motor, generate an alarm, that kind of stuff.   What data analysis is needed beyond what a PLC does? Generally, the people who sell the high value data analyis software make it quite clear about what is needed as input for the software and what it needs to run with.   Isn't this clear for your analysis software?
  8. RS485 to Scale

    Congratulations.   Serial 485 is a pain, isn't it?   Delighted you got it running . . . 
  9. RS485 to Scale

    Another thing, that might apply or not because it applies to recent vintage USB/RS-485 converters and you're wiring to an RS-485 port. For 20 years, I wired USB/RS-485 converters that were capable of 4 wire full duplex operation (4 terminals: Tx+, Tx-, Rx+, Rx-) but were to be used for 2 wire half duplex operation by jumpering the (+) to (+), (-) to (-). But the last converter I bought recently failed to operate right out of the box when I jumpered it for 2 wire operation.  I'd seen someone mention on a forum that they'd had a converter work without jumpering, so I removed the jumpers, connected it as a 2 wire device without the jumpers and it worked just fine.  It had an FTDI chipset, which is what I've used for 15 years now. A regular "Gotcha" when working with RS-485 is that some vendors label the 485 terminals the opposite way of others.   RS-485 is supposed to wire (+) to (+), (-) to (-), but when you've connected, configured and you KNOW it should work and it doesn't, swap the 485 leads on one end and when it works you will have discovered another situation where one of the devices using backwards labeling.   Hooking RS-485 up backwards will not damage the 485 drivers, but it will never operate properly or at all.
  10. RS485 to Scale

    1.  The scale is a slave, it responds only to Modbus Function Code 03, Read Holding Registers (see 3.11 Modbus Protocol) You are incorrectly using Function Code 04 (read input registers) (as shown in Packet Setting element 2). When you switch to Function Code 03, element 4 might change name but it will probably be the starting register. With Modbus, always start by reading one value only, get that working, then move onto whatever else you need. If you want Gross Weight, then you need registers (4)0008 and (4)0009, which are one based decimal register addresses.  I do not know how your master interprets one based decimal register addresses Might be starting address 40008 and element 3 is qty 4 (bytes, 2 registers) Might be starting address 0007 (zero-based), element 3 is qty 4 bytes (2 registers) Might be starting address 0008 (one-based), element 3 is qty 4 bytes. Someone who knows will have to advise you or you'll have to experiment to see what syntax is needed for stating the starting address. 2.  Serial settings MUST be identical on both ends.  It appears the PLC is 8 data bits, 1 stop bit, Odd parity.  Is the scale also have those exact settings?  (odd parity is unusual as a default setting, most Modbus RTU devices are either no parity or even parity, not that it makes any difference, but both ends MUST be identical. 3.  if it were me, I would disconnect the signal ground from chassis ground and see if it works.  If chassis grounds are more than 5Vdc difference in common mode, RS-485 will saturate and fail.   It's one of things that if you have problems connecting, it's something to try and see if floating the signal ground makes a difference.   It's another one of those issues with RS-485 that Ethernet doesn't have because Ethernet is isolated by design. 
  11. CIF11 Modbus Slave

    1)  For your information, Modbus is inherently half duplex because the Master has to wait for the slave to process its request and then reply.  Therefore masters are (almost) never programmed to take advantage of full duplex operation for Modbus because it's too complex and statistically not worthy of the effort. 4 wire RS-485 is for full duplex operation. 2 wire RS-485 is for half duplex operation. If you can configure it, use half duplex for Modbus. 2)  Connections to convert 4 wire (full duplex) to 2 wire (half duplex) historically jumpered  the (-) together:  Rx- jumpered to Tx- and the (+) drivers were jumpered:  Rx+ jumpered to Tx+ However, on a recently purchased USB/RS-485 converter (FTDI chipset), I found it would not communicate when I jumpered it like I've done for years.  When I removed the jumpers and used only 2 terminals, it operated OK.   So some experimentation might be needed for half duplex operation from a device capable of 4 wire full duplex operation. 3)  I have no familiarity with either ABB or Omron, so I'm confused about choosing RS-232 for port 2.   The SDA+, SDA-, RDA+, RDA- designations are 4 wire RS-485 designations, not RS-232.   If you are using port 2 for RS-485 communiations, then you can't configure the port for RS-232.  RS-232 is not compatible with RS-485 without a hardware converter.   
  12. I think you are a Modbus expert.

    I  need advice for communication modbus Tcp Fx5U to Fx5U

    Thank you.

  13. Janitza UMG96RM RS485 Bus

    What you've got Page 9 in the manual shows that the RS-485 port uses the Modbus RTU protocol.   RS-485 defines the electrical characteristics of the bus, but Modbus defines the rules of communications: who talks, who listens, timing, what the format of the messages is, error checks and what the error handling is. Nothing happens Nothing should happen when you connect your Janitza to your PC via RS-485. Modbus is a master/slave protocol.  In Modbus, slave/servers never speak unless they are asked for information or acknowledge a message sending them data.  The Janitza box is a Modbus RTU slave.   It is sitting there waiting for a command from a Master/client.   You haven't sent it a command.   So it is silent.  You need to obtain a Modbus Master application program for your PLC and then program the master application to ask the Janitza slave for the data you need.   Modbus is a project.   There is nothing plug-and-play about Modbus. Power The power used by the RS-485 communications port is derived from the power to the Janitza itself. Signal Ground The implementation of RS-485 is all over the map.   RS-485 should have a signal ground wire - Profibus DP is RS-485 and since it was an engineered implementation of RS-485 it has not only the 3rd wire but bias (driver lines connected to Vcc and gnd) at the master and selectable termination.  But the companies that implement RS-485 for Modbus sometimes do a pretty poor job of implementing either RS-485 or Modbus.   In the absence of a signal ground the 485 circuit 'finds' a ground somewhere to reference.  When things are good, that ground potential is close to the true signal ground. When things are bad, the ground potential between the master and various slaves exceeds the common mode voltage limitations of RS-485 and the bus communications ceases.  The typical work-around is to use RS-485 repeater-isolator modules to break the ground loop created by excessive common mode. Grounding the shield on the comm cable Good idea to use quality communications grade cable with twisted pair(s) and to ground the shield at one end. RS-485 connections Driver line A is supposed to connect to A, B to B, (+) to (+), (-) to (-), depending on how the driver lines are labeled.  But some vendors label the lines the opposite of others (some divisions in large companies that never talk to each other label the 485 driver lines the opposite of the other's).   So when you've got your Modbus RTU master programmed and it can't get 485 to communicate to the slave, one of the first things to try is to swap the driver lines on one end to see if that's the issue.  On the bench at baud rates below 28K baud, terminating resistors generally aren't needed.  I install them in the field, but termination becomes more critical at higher baud rates. serial settings RS-485 is a serial bus.  The serial settings for both devices MUST be identical - baud rate, 1 start bit, 8 data bits, and parity.  Check and recheck serial settings.  Most devices do not recognize serial setting changes until you cycle the power to the device, so cycle the power and the check again.
  14. I'd guess that the DC power supply probably failed taking out the meter's electronics.    In general, Coriolis meters are AC powered.   An internal DC power supply provides power for running the components.   DC power supplies have finite life spans.   When capacitors fail, they fail.   If it were a case of electrical surges or brown-outs causing the failure, then either a ferro-resonant transformer (Sola) or a battery powered UPS could condition the AC to the meter. From the 1980's forward, the era of field repairable instrumentation disappeared with the adoption of microelectronics.  Vendors stopped providing schematics, parts lists, or service manuals.   Many users don't have anyone that can troubleshoot and do component level repair either. I/O boards, comm modules and digital displays might sometimes be available as replacement assemblies for the converter/transmitter electronics end of the flow meter, depending on the manufacturer.  10 years I remember being surprised to find a company that would re-wire the coils in the larger magmeter tubes, but I suspect coriolis tubes are unrepairable.
  15. I'm not a Mitsubishi guy, I'm a Modbus guy, so my comments are from the Modbus world. Several observations. RTU and ASCII are totally different protocols Modbus ASCII and Modbus RTU are totally different protocols in terms of byte size, message formatting, timing, and error checking. If you don't believe me, here's a vendor telling you the same story https://www.icpdas-usa.com/documents/modbus-RTU-to-modbus-ascii-conversion.pdf cases in point: Byte size ASCII is 7 bit, not 8 bit. That confuses the UARTs that handle the serial data. You need a UART that can handle 7 bit ASCII data. Yours does not appear to want to do so (8 bit only) Message formatting Modbus RTU uses a timing delay and a start bit know what to start a message Modbus ASCII uses the colon character. A device handling RTU has no means of generating a colon at the beginning of message or recognizing a colon character in a reply message. error checking Each message uses error checking ASCII uses LRC RTU uses CRC These two error checks are totally incompatible with one another.  A bad error check results in an exception message and the message is discarded. Incompatability The differences between Modbus ASCII and RTU message formats make them incompatible protocols - neither can deal wth the other. Commercial gateway/converters solutions Either you can do your own coding using whatever tools Mitsu offers for that PLC or you can buy a commercial converter/gateway solution. Modbus ASCII is relatively rare nowadays (it was designed for telephone modem communications), so the only dedicated Modbus RTU-ASCII gateways that also combines a serial conversion, 485-232, that I know about are Cel Mar (Polish) https://cel-mar.pl/en/rs232_rs485rs422_asci_rtu_1040pc1.htm?idk=5#poz Equustek DL-4000 MMX (Canadian) https://www.equustek.com/dl-4000-mmx-modbus-rtu-modbus-ascii/ This is not an endorsement, I've never used either and I'd want to confirm that the software for the DL-4000 MMX would run on Windows 10. There are several Modbus RTU-ASCII gateways that are RS-485 on both sides, which would require a 485/232 converter on the ASCII side, as well. There might be other gateway/converters out there, but be aware when searching that there are Modbus RTU-to-(generic)-serial ACSII converters that are not programmed specifically for Modbus ASCII that offer no real advantage over roll-your-own coding, (they're for non-Modbus ASCII serial, like propritary datalogger serial protocols). The market is now primarily Ethernet-serial protocol gateways (RTU timing requires the use of Modbus-specific gateways, not generic Ethernet-serial gateways).   In fact, one such vendor suggests doing Modbus RTU - ASCII conversion using Ethernet: https://ipc2u.com/support-service/faq/protocol-gateways/modbus-rtu-to-modbus-ascii/