DanW

Maybe, it's a big world out there, but I doubt it. Typical serial I/O modules use either a defined proprietary protocol or use Modbus. The Advantech Adam 4050 has 8 DO's but only part of the message written is the bit pattern for which bit is on or off.  The protocol uses ASCII characrters, with this syntacx (for that specific module) [delimiter character][address][command][data][checksum] [carriage return]. That series of I/O modules does not have RS-232, they use RS-485, so you'd have to use an RS-232/485 converter, or use the Red Lion RS-485 port.  

One key word under product description is 'single ended'.  That means the (-) side of all the signals are connected all together at one point. The terminal labeled RTN on the Field Wiring Terminals table means return, or the common, (-) side of the input(s). The wiring diagram shows the field device on the left with its positive output connecteed to In, (-) connected to RTN. The In (I2, I4) number represents the current source field device (I is current in Ohms Law). What is not spelled out is what happens when the field device is a loop power transmitter and needs a loop power supply. So the (+) side of the current signal goes to the An terminal,  which is either - the negative terminal on a loop powered transmitter (because the positive terminal of the transmitter is connected to the Power supply (+), or - the positive output from a 3 wire or 4 wire field device. and then either - the negative (return) of the loop power supply output connects to the RTN terminal - the negative outputs from either 3-wire or 4-wire field devices are run to terminal blocks, jumpered together and then connected to RTN. The wiring diagram essentially shows the same thing - Test it with a single field device. I haven't a clue what all the Bn connectors do.  Shame they can't be used as RTN or (-) connections.        

see this link https://support.industry.siemens.com/cs/document/106656707/the-tia-portal-tutorial-center-(videos)?dti=0&lc=en-US

The flow meter is clearly a lab unit  - it's construction, power source, line fittings, accompanying software and lack of industrial signal interface all peg it as a lab unit.   Writing a conversion protcol driver for the device to get data into a PLC could take hundreds of hours, far more if you're inexperienced. The flow meter is a thermal dispersion inferred mass flowmeter, similar in size flowmeters from vendors like Brooks, Aalborg, TSI Alnor, MKS.  It does have a 2KHz sampling rate, which you might need, but I doubt it.  You might consider buying a flowmeter that can interface to the process AND to the data collection or control needed. @aawilliams  Welcome to the forum.  Your reply is cogent, readable and a very instructive reply for a first time (?) poster. Nice job. You must be a sojourner from some other controls forum to compose that high level a reply.

As the software splash screen shows you, it's a BauMuller (u umlaut with correct spelling) product (Omaga makes nothing, private labels everything). web searches turn up parts described as Baumuller-Omega:   Baumuller is still around.  Have one of your buddies who's fluent in German give them a call, maybe an old guy still has an English manual for the old stuff https://www.baumueller.com/en/products/automation/control-platforms  

A photo might help identify what you have.   Are you sure 'Omega' is the PLC or could Omega be just the HMI display? 

There does not seem to be a manual on the Siemens site.    What kind of manual came with it?   Have the Germans given up on documentation?  

The field instrument is supposed to be a 2 wire, loop powered, passive transmitter, powered by an external power supply source. That supply power source in the input module is connected to the Uvn terminal.  (Uv = voltage supply, n = the input channel number) DC power, by convention, connects to the transmitter's (+) terminal. The transmitter's (-) terminal connects to the analog input (+), which for this module is (In) (current = I, n = the input channel number) Most field instruments are 'floating' and their outputs are not grounded, so there is not likely to be excessive common mode voltage in the loop which would require an isolator.  So, no isolator.

The typical story one hears when the problem is excessive common mode sounds something like this, "I had x number of analog inputs connected and they were all fine.  Then I added one more and all of them went crazy.   What happened?" An AI card can work within its common mode limitations but adding just one AI can drive the common mode past its limits. If you can establish that X number of AI's worked OK for some period of time and then when an additional AI was added this overrange situation started, then the last one added is the one to that needs the isolator.  An isolator will decouple the common mode and allow the other inputs to function OK.   

  The symptoms are excessive common mode.   Some source of common  mode exceeding the ±10V limitation is forcing the input above the rail voltage saturating the input, just as Panic Mode describes.  The A-B manual says: Chances are the AO's on the flowmeters are active outputs and you can't connect the commons of the power supplies because you don't have access to them. I'd put a 4-20mA isolator/repeater on the one that seems to fail first and hopefully that'll solve it without isolating the other inputs.  

It does not appear to be a fault in the AI because you can measure the 20mA+ (28mA is some cases), so the AI is jsut reflecting the loop current it 'sees'. The flow meter's AO should regulate the current in the loop.  That's what 4-20mA outputs do.  But the flow meter can not prevent currents from ground loops adding to or subtracting from the loop current.   It would be unusual if ground loops developed over time.  Which makes me wonder, how many of the 16 flow meters exhibit this over-current phenomenon? Is it the same flow meter's output going high or does this occur over different flow meters? Are the loops 2 wire loop powered (external power supplied) or active, powered by the flowmeter?

Modbus master/clients all have a time-out setting that in the absence of a reply from a slave will skip over it (instead of waiting forever for the reply) and go onto the next task/action.   Assuming that the time-out can be flagged, It would take some programming to recognize some number of reply-failures and then drop the missing slave from the line-up.  Yes, slave loss slows down 'throughput' because the master waits the entire time-out interval before moving onto the next action.  The 'next' action might be a re-try or it might be 'ignore and proceed'. Slaves can be wired on an RS-485 multidrop network without affecting the network if the slave is not enabled.   But disabling the slave's comm will not speed up the Master's actions.  The bad slave has to be taken out of the Master's 'line-up' to avoid the time the master waits for a reply that might not be forthcoming.

Thanks for the update.

Is it the best way?  I don't know.   Does it matter how fast the conversion is? I do know that there four different word/byte (IEE754) formats for 32 bit floating point values, two of which are commonly used in Modbus. Many Modbus master/clients provide the ability to pick one of the two to use to interpret the raw data. If your master/client has a choice for floating point formats, you could try the alternative one and see if it does the conversion properly with the raw data, before moving the data.

If it sorts inversely, then move the data words to change their order of the 16 bit data words and convert to float D0: BE62   move to D2 D1: 31D7   stays in D1 D1: 31D7 D2: BE62 new inverse of the sequential data D1 D2 is BE6231D7; convert D1 D2 to the correct float