EkremVK

IQ-F FX5U Predefined Protocol Support Function to Implement Modbus ASCII

3 posts in this topic

Posted (edited)

Hi all!

I'm trying to read data from a magnetic sensor of Roboteq's called MGSW1600. The sensor allows Modbus ASCII communication with RS232 interface. I'm already using a RS232-RS485 converter but that's not enough to communicate. In attachments, you can find the related settings of the sensor for communication and packet structure for sending and receiving data.

I've tried using non-procedural communication and did all the settings but I guess sumcheck here is CRC, not LRC as denoted in the sensor's datasheet, moreover, I couldn't figure out how to sent all the necessary information to the sensor (node address, function code, register address to read from, number of registers to read) using RS2 function block. So, I'm thinking of using Predefined Protocol Support Function as soon as I obtain the necessary devices I ordered online. I also added Predefined Protocol Support Function settings in the attachments.

I need help with the ladder program and confirmation of settings or any other idea about how I can establish communication between FX5U's built-in Modbus RTU RS485 port and Modbus  ASCII RS232 sensor.

Packet Structure for Sending and Receiving Data.png

Serial Communication Settings of the Sensor.png

Predefined Protocol Function Settings 1.png

Predefined Protocol Function Settings - Send Packet.png

Predefined Protocol Function Settings - Receive Packet.png

Edited by EkremVK

Share this post


Link to post
Share on other sites

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/

 

 

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now