Not sure if this is even possible but I have an micro 1400 that I would like to connect to HMI. I am using rs232 from PLC to (RS232/ttl converter) to ttl HMI. HMI uses c+ programming. Am I chasing my tail?
It is possible - but not quick or easy if you are doing it from scratch.
Any Allen-Bradley register-oriented (and not tag-oriented) PLCs use at least one protocol based upon 'DF1' These go back to PLC-5 and before. The messages had different 'FNC' codes for different products but the packet structure was similar. Newer PLC implementations of the protocol seem to be divided into two categories - those that come from the PLC-5 family and those that come from the SLC-500 family. Why that distinction exists is a puzzle to me.
Protocols built upon this include Data Highway, PLC-5 port 2222 Ethernet, and others including the PCCC that can work with today's CompactLogix. Type encodings have been added for data types that were not considered years ago like 32-bit integers and character strings.
My introduction to DF1 came from Publication 1770-6.5.16 dated November 1991. It's a well-written well-used printed book that is much easier to work with than the online documents which have more links between fragments than usable information. It does not include putting the DF1 packets into any sort of Ethernet packet. Some of that information was not freely available from Allen Bradley. PCCC is available.
The book I have probably has enough information that you could use it to hit your micro 1400 if you download a modern version of it. I suspect it would use the SLC-500 family of function codes. Any Ethernet documents would be a separate download.
I'm sure there are C-code communication libraries for serial DF1 out there somewhere. I've never used one. Stubborn pride has me chewing my own gum and making my own mistakes through 30+ years.
PM me if you're interested in discussing Raspberry PI possibilities
Modbus is another possibility; the HMI will have to poll, and performance may be an issue, but there are plenty of Modbus libraries available in many languages.
Your PM mentioned multiple devices. When using multiple devices on serial you need to switch to RS-422 or RS-485. Typically '2-wire' 485 using an ISOLATED converter. I know it's called 2-wire but don't forget the third.
With serial multiple devices comms requests are sent out one at a time from the computer. It then must wait for that request to complete - either with a reply from the PLC or from a timeout - before going onto the next request. It cannot talk to more than one PLC at a time and it cannot 'pipeline'
multiple requests to the same PLC. People think serial is slow because of baud rate but that is only part of the reason. There are other considerations - half versus full duplex, packet size, etc.
Legitimate PLC protocols continue the Modbus tradition of a one-byte identifier in the packet that determines which PLC is to reply to the request. Each PLC on the multidrop connection must have a different value for this identifier. The DF1 protocol has it.
When serial protocols like Modbus or DF1 are incorporated into Ethernet the one-byte identifier is still there. In some cases it is ignored since Ethernet routing is done through IP addresses. In other cases it is used for protocol gateways.
NET.ABLINK Visual Studio .NET PLC drivers for Allen-Bradley MicroLogix, SLC and PLC controllers make it easy to write HMI .NET applications for the .NET framework, ASP .NET web service and Windows CE Compact Framework.
Your PM mentioned multiple devices. When using multiple devices on serial you need to switch to RS-422 or RS-485. Typically '2-wire' 485 using an ISOLATED converter. I know it's called 2-wire but don't forget the third.
The 'normal' serial protocol with AB Legacy controllers is called DF1 full-duplex. This protocol only works for a single connections between 2 partners.
For serial between one 'master' and multiple 'slaves' the protocol is called Df1 half-duplex. Is that what you are after ? If so I am not sure if the above-mentioned software products supports that mode.