MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

18 Good

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

4592 profile views
  1. 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.
  2. 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.
  3. 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/    
  4. I'm not a mitsubishi guy, I'm a Modbus guy, so I can't comment on your ladder. Several observations. CRC error 99% of Modbus is half-duplex "2 wire RS-485" which means that handshaking is not used.  That's why the "handshake control" feature should not be checked (first graphic, upper right), because 2 wire RS-485 has no provision for the RTS signal (a separate pin on RS-232). Checking "reverse CRC" is probably why your 3rd graphic shows an invalid checksum.   If the checksum bytes are reversed, the the checksum is wrong.  Uncheck the "reverse CRC" feature.   Not a valid Modbus reply In the first graphic, the single byte response, A7, makes no sense whatsoever.   A valid Modbus reply message, even an error-exception code reply is a formatted message with at least 8 bytes.     "Read Holding Registers" or "Read Input Registers"? In the first graphic, the "Read Holding Registers" is selected, with a Function 4.   In Step 3, the 2nd byte in the message [04h] "Data Out" message confirms that the Modbus message is requesting a read of the "Input Registers", which is what Function Code 04 does. Input Registers are a different set of registers than Holding Registers in a slave.  Some few slave devices map the same information in the Input Registers to the Holding Registers, but many do not.  A source of confusion is that Input Registers are identified by the leading numeral (3)xxxxx, whereas Holding Registers are identified by the leading numeral (4)xxxxx. So Function Code 03 (read Input Registers) reads the (4)xxxxx memory area, but Function Code 04 (read Holding Registers) reads the (3)xxxxx memory area. The graphic shows what I consider a misrepresentation because it allows Function 04 to be incorrectly associated or identified with Holding Registers.    The bottom line is that the query is polling the slave's Input Registers, (3)xxxxx, with Function Code 04, and if that's what you want, fine; or maybe you need to poll with Function Code 03 instead if you need to poll Holding registers   Unreadable graphics I'm sure there's critical information in the graphics of manual pages that you posted, but it's your problem and if you can't take the time to format the graphics so they're readable, you can't expect readers to jump through hoops to do so. Who's Master, Who's Slave? By definition, Modbus RTU Masters can not communicate with another Modbus RTU master. The text about connecting to weinview hmi - most HMI's operate as Modbus master so that actions like pressing a soft switch on the HMI immediately sends the status change to the PLC without waiting for a PLC master to poll the HMI for changed states.    I had assumed that the first set of 3 graphics were Modbus Master setup pages for the Fx2n PLC.   If the Fx2n is a Modbus Master, can the Weintek HMI be a Modbus slave?   Parity The rule for serial RS-485 communications (which is one of the hardware comm links used by Modbus RTU, the other is RS-232) is that the parity settings for all devices on the link MUST be the same.   The Modbus Spec says that devices MUST have Even Parity, but there are no Modbus Police to enforce the specification, so occasionally there are vendors who use only No Parity.   But most allow a choice of even, odd, or none Parity. But you have to match the parity settings for the Master and all slaves or you have garbage network that won't work.    
  5. How should I matching the impedance?

    There’s all those status bits, channel enable or input type selection that affect card operation.   With respect to impedance matching, if the device AO is a standard commercial 4-20mA output, then its output impedance is what it is and is presimably rated to be capable of driving 21mA of DC current through a reasonable load resistance, typically a minimum of at least 500 ohms, sometimes as much as 750-1,000 ohms for AC powered devices.   Unless the copper wiring is excessively long and small diameter (high resistance), any 4-20 mA loop driving a 250 ohm input resistance should  work OK.   There is no impedance to ’match’; the total loop resistance just has to be lower than the maximum load resistance the AO can drive (spec’d somewhere in the spec sheet). The installation guide shows the ”I in 0-” terminal jumpered to the ”ANLG Com” terminal for loop powered transmitters.   I’d probably try a temporary jumper to see if it makes any difference.   The warning about voltages on V/Iin+ and Iin+ having to be plus/minus 10Vdc is valid; that’s the common mode limitation for this module.   If the device ground is more than 10v from the AI card ground, the 4-20mA current signal disappears in resulting ground loop, which may be happening.   Ground loops between a single ended, non-isolated analog output and an AI are quite common.
  6. How should I matching the impedance?

    Sure you wired it right? Is it a loop powered transmitter?  Have you wired a DC power supply into the loop? 
  7. Ultrasonic Flow Meter noise

    Are the Flowmeters AC or DC powered? Some frequency outputs are passive that need loop power to operate. If a 24Vdc power supply is in the frequency loop, is the 24V common grounded or floating?   Can you ground the DC supply if floating, or float it if it is grounded in order check alternative performance? I have heard of some field instrument outputs picking up noise from switching DC power supplies, where the solution was to substitute a linear DC power supply.   Linear supplies are now uncommon, but it might be worth the effort to locate one for testing to see if it makes any difference. Presumably the Fluke is battery powered and floating.     Are the frequency test results done with the field wires disconnected from the input terminals of the AB input card, or with the field wires connected? I wonder what an AC powered, grounded chassis oscilloscope would show for an ”as connected” test (in parallel with the connected field wiring)? I’ve seen 4-20mA common mode issues disappear when the field wiring is disconnected and its signal checked with a floating battery powered meter where problem reasserts itself when the field wiring is re-connected, because common mode is ’common’ between two points - remove the commonality (wiring connected, not floating) and the common mode disappears. Try the same frequency test with the (-) low side meter probe grounded to see if you get the same results. 
  8. Help with PLC communication basics

    PLC’s basically run ’real-time’ and do not routinely store data unless specifically programmed to do so.   ’HMI software’ (several flavors listed in the post above this one) takes on the task of communicating with the PLC to get data from or to write data to the PLC. As someone noted, some PLC comm ports are for programming, others for data transfer; depends on app specifics.    It takes a ’driver’ to talk to a specific brand/model PLC.   OPC server (Windows software) are like a gateway; one side has a driver that talks to the  PLC, the other side exchanges the data from the PLC with an OPC client.   OPC clients are built into most HMI software packages nowadays.  The latest iteration of OPC, OPC UA, is friendly on the server-client side, listing PLC configured tags in the client, but the driver side still requires ’building a tag database’ for many devices.   I think the proposed task is incredibly ambitious.  I find the prospect of connecting to a variety of installed controllers daunting, to say the least.   It’s my opinion that the world of IIoT is largely an illusion with its implementations requiring significant programming effort. Best of luck in the endeavor.        
  9. Banner DXM 700 or other Model

    I have configured dozens of DX80 gateways over the years, mostly mapping AI’s to AO’s, DI’s to DO’s.  It was straight forward with the software. Then came the DXM100.   I bought one to try and after a day’s effort at trying to get the DXM onboard AO to ’follow’ the node radio AI, I gave up.   The factory, which used to have superb support, blew me off.  The DXM100 was supposed to offer cellular communications and my guess is that Banner packed a whole bunch of programming features into it that the DX80’s did not have, especially in light of their marketing push into the agriculture markets (irrigation, soil moisture).  In that move, they made a gateway that won’t handle a 4-20.   Good for them. I didn’t bother to compare the DXM100 vs the DXM700 and I couldn’t find an on-line comparison chart.   Out of curiosity, why does yourclient want a particular brand/model wireless gateway?
  10. FX5U Modbus communication

    Historically and generally, a spec for the maximum number of units on an RS-485 network is based on the RS-485 chip in the device, and the frequently followed by the disclaimer (as in embedded graphic in the first post above) like "the number of slaves varies depending on communication equipment type". There have been advances in the 3+ decades that RS=485 has been around, and there are 485 chips that can support 64 devices, but the entire network has to be those chips. The Modbus RTU protocol limit for addressable slaves is 247 slaves. 
  11. FX5U Modbus communication

    A couple comments about Modbus in general. 1.  Consider how often the master can communicate with each slave.  The query/reply time period for multiple slaves adds up.   If one slave is “down” then the master waits for that slave’s reply until the master “times out”.  Consider a relatively workable means of de-selecting slave(s) in the master’s polling list should a slave be out-of-service. 2.  Pushing the maximum number of nodes on a single network/bus frequently leads to communications issues where a simple work-around is to use an RS-485 isolator repeater half way down the bus so the 485 drivers do not have to drive all the loads, only half the total loads.  
  12. Rules for the Forum

    As a non-admin, but long time forum participant on multiple industrial controls fora, my observation is that attempts to produce better interaction by establishing ’rules’ is not going to go anywhere. The fact that many OP’s never return-post beyond their initial post is universal. The fact that most OP’s do not clearly articulate their problem and leave out critical information is universal. The fact that some people desperately ’want’ something that is not commercially available is universal.   The fact that there is continued belief in one-size-fits-all ’secret PID terms’ that somehow just are not published but will be revealed in a forum thread is and will be universal. The fact that about 70% of my replies come straight out of a publicly available (downloadable from the web) manual or spec sheet will not inhibit those who will not research their own topic themselves. Just like the saying, ”there are 10 kinds of people, those understand binary and those who don’t”, there are those who understand troubleshooting and those who don’t.   I fail to understand those who stay in a vocational field where the ability to troubleshoot is ubiquitous, but hey, it’s their problem. Make up all the rules you want to, but just like I don’t bother to read EULA’s, they won’t bother to read or pay attention to new rules. my 2 cents
  13. ProfiBus Noise

    Try this article by a SMAR engineer http://www.smar.com/en/technical-article/tips-for-trouble-shooting-on-the-profibus-dp Other technical articles not specific to Profibus on that site, too Or this one: https://procentec.com/about/news/2016/a-short-guide-to-addressing-emc-on-profibus/
  14. Analog Wiring NO NO

    OK.  I thought the distinction your were making was signal type (analog vs digital), not connector type (screw terminal vs terminal block).   Even so, given the number of times I've found the problem to be a whisker (that errant single strand) that makes it way out from under the screw terminal and touches where it shouldn't, I'd take a ferrule over bare stranded wire even if a fork is the correct and proper solution.   Have you encountered maintenance/performance-over-time issues with ferrules under screw terminals?n   Loosening?
  15. Analog Wiring NO NO

    I have the panel shop use twisted pair from the short run from field terminal blocks to the AI cards.  You can see the blk/clear pair below coming up from the top of the field terminal blocks. I haven't a clue why analog signals rate fork terminals and discretes rate ferrules.  What's the logic for that?