MODBUS RTU PROBLEM

[helix360]

Hi,

I'm using a BX-DM1E-10ED23-D as master for an Oriental Motor stepper drive (RKS). Once I write the data to the single register of the slave, I'm getting a PLC warning ST143 "device drive error" and it's only the error bit will turn on in the MWX command. The RS485 port D+ and D- leds of the PLC are blinking (seems normal communication) and the slave has no error but the data that I'm sending is not received by the slave. I programmed the PLC that once the write is successful,  a "success bit" is set and will break the write command rung. The "success bit" can only be reset on the first scan and the by the reset button. Maybe you can guide me through in solving this problem.

Thank you very much.

[ATU]

This is a handy tool to have.  https://www.modbustools.com/

You can send it to RS232/USB or an old laptop with a serial port (I still have one for that purpose) running that program and see what is coming over. A serial port sniffer is also good to use if you can get one.  Common issues are register offset, port settings. Doesn't make sense getting a driver error if the MWX instruction is successful.

[franji1]

What code block is your MWX instruction in?

Is it in a Stage?

Is the Stage and/or code-block active until the MWX is finished, i.e. the PLC is scanning the instruction until the OnSuccess or OnError event has occurred?

MWX is a fully-asynchronous multi-scan instruction.  Even if it's "edge triggered", the instruction itself needs to be "scanned" by the PLC firmware control engine until it completes.  No premature JMPs.  No MWX in edge-triggered Tasks.  No EXITed programs.  MWX must finish before you can JMP/terminate/EXIT.

There may be some Program Check warnings/messages that may help point you to the issue.

[helix360]

It's programmed on normal ladder. The first rung is to reset the "On success bit" and "Write successful bit" on first scan and when a reset button is turned ON. The second rung contains a normally open contact as switch for writing data and it is and with a normally closed "Write successful" bit to make sure that the Modbus Write instruction is deactivated once the writing is successful. The third rung has normally open contact "On success bit" that will set the "Write successful" bit. I don't use the stage programming because it is only one writing one register for changing the position data of the stepper drive.

[franji1]

Is the MWX input leg edge triggered or normal power flow, i.e. does it have a "clock" triangle on the box's input leg?

[Controls Guy]

Try reversing polarity.  If the line is backwards and the PLC is the master, it will talk all day long, but the slave won't hear anything, therefore will not respond, therefore the PLC will generate an error on the transaction, never having received the proper ack from the slave.

[helix360]

I was able to eliminate the warning ST143. I tried to experiment by writing small data numbers on four non-consecutive holding registers. For position data, I put-1, speed - 2, acceleration - 3 and deceleration - 4. All data was written successfully - no error. The problem is that on the driver side, the data does not match with the data from PLC, i.e., 1 from PLC corresponds to 65,535 on the drive, 2 is 131,072, 3 is 196,609 and 4 is 262.145 - it's weird!

[Controls Guy]

It wants 32-bit data, and it's reading what you write in the MSW.   Try changing your address by 1 word one way or the other (depending on endianness).    Then you'd probably see correct values, but since I'm pretty sure it wants 32-bit data, you couldn't get close to full range setpoints.  However, it would be a comms troubleshooting test.  If I'm right, you're going to need to end up sending 32-bit values.

[Controls Guy]

Try dividing the values it thinks it sees by what you're sending for each register.

[ATU]

Instead of writing the data, set the values manually in the drive if you can and then read them out in  Vmemory  and then examine the values. It should give you an idea of what its looking for.

[helix360]

No error in reading but the data is not coming in to the master (BRX).

[ATU]

Read a block of registers, perhaps your addressing is off