DanW

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?

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.

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?

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.

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?

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

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.

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. 

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.   

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.

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.

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/    

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.    

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.

Sure you wired it right? Is it a loop powered transmitter?  Have you wired a DC power supply into the loop? 

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. 

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?

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.        

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. 

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.  

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

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/

It is not just a marketing term, there is a true functional difference between a dedicated function analog input card (4-20mA only) and a universal input card. An analog input card that takes a direct RTD or thermocouple input in addition to 0-10Vdc and 4-20mA has a lot of functionality that an analog input card that a 4-20mA-only card does not have.

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?

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?