C++ code for Modbus used with AZ series

[tobias]

Hello everyone,

we've recently purchased three AZ stages from OM and will build a setup where they act as a combined XYZ stage.
We would like to integrate the communication with the stages into our C++ script of the overall process in which we are using them.
Since we don't have any experience with Modbus in C++ I was wondering if anyone has already written some code that he or she would be willing to share with us or can point us to a resource or tutorial that can help us in developing this communication interface for our system. The code will be running on a linux machine that is connected to the stages via a USB <-> RS485 adapter.
Thank you very much for your help!

Best,
Tobias

[om_tech_support_JT]

Hi tobias,

Unfortunately, OM does not offer a C++ to Modbus code library. Your C++ code does need to be converted to Modbus RTU code format. Our AZ series drivers only supports setting data with our own MEXE02 GUI software (free download), or with a Modbus RTU master. We offer network converters (to Modbus RTU) for other industrial communication protocols such as CC-Link, Mechatrolink I/II, and Ethercat. We can recommend a 3rd party network converter for Ethernet IP.

I'd advise setting as much data with our MEXE02 software to minimize the burden on the C++ to Modbus RTU code conversion.

Modbus RTU code/message structure start on PAGE 233: http://www.orientalmotor.com/products/p ... 60262E.pdf
-PAGE 337 describes I/O commands which is necessary to execute the motion data written in the driver.

[tobias]

Hi,

thank you for your reply. Meanwhile I have been able to get the open source libmodbus library to work so i can now send hex commands from my computer through the Digitus DA-70157 USB to RS485 converter to the stage driver.
Unfortunately I don't get a response from the driver, not even when I send the command in hex through a serial terminal.

My configuration:
Odroid <-> USB/RS485 converter + termination resistor <-> DSUB9 to RJ45 adapter <-> 0.5m Ethernet cable <-> AZ stage driver

settings in the serial console:
slave ID: 1
baud: 19200
data bits: 8
stop bit: 1
parity: even

settings in the stage driver:
baud switch: 1
ID switch: 1
SW1: 1 off, 2-4 on

When I power the driver with 24V the C-DAT LED is off and the POWER LED is illuminated in green.

Let's now say I send this command (I found it as an example in the AZ function edition):
master -> driver
01 03 18 40 00 06 c2 bc
As a response in the serial console I then see:
00 00 00 00 00 00 00 00
and the C-DAT LED switches to red while the POWER LED starts its 7-times-red-blinking circle.

What am I doing wrong?
Do I need to make any settings before talking to the device like I try? Do I HAVE to connect it to the MEXE02 at some point? I don't get it. I also tried setting the home position before sending the above mentioned command but it makes no difference to the result.

[tobias]

I just connected the drive to MEXE02 and found the alarm record. Before I reset it it was filled with errors of the one in the screen shot I attached. Maybe that helps you in diagnosing my problem. Thank you.

Mexe Alarm record

AZ_MEXE_Alarm.PNG (99.62 KiB) Viewed 5090 times

[tobias]

Further infos from MEXE:
In the communication monitor it says "framing error" after I tried to send a command from the master to the slave.

[tobias]

According to the AZ function edition this means: Stop bit 0 was detected.
The funny thing is: I connected another RS485 to USB converter to the second ethernet port of the driver and connected that converter back to the controller PC. When I open a serial terminal on the new COM port and monitor what comes in it shows me the exact command that I sent out through the first port. That means, the PC recognizes its own message but the drive has some kind of problem with a falsely detected stop bit. What communication settings could I check?

[tobias]

When I connect a slave simulator on my laptop as a second slave to the network it also recognizes the message without a problem.
Sorry for the posts but I couldn't figure out how to edit them.

[tobias]

Ok, I think i solved it. The problem for this very error was: the char delay in the serial console was set to 4ms. Apparently that was too long for the drive and it timed out in between the frames...After changing it to 1ms I got a valid response and the LED stayed green.