RS-485 Modbus - suitable for CNC machining motion control? or just VFD control?

Hello all,

Is Modbus (RS-485) suitable for precise motion control as required for CNC machining motion control?

I have researched quite a lot but not found enough definitive info... it seams that it may be fine for general comms and running VFD etc, but not for precise axis servo control? (for example, for servo control of a 5-axis router, machining to 0.05mm).

I see that I can get Mesa 5i21 (12-channel-RS485 card), but is Modbus able to provide me the co-ordinated/realtime 5-axis motion control that I need?

Any info, or pointers to other reference information would be much appreciated.

<I am using Dorna 3kW 3000rpm servos/drives (4 pcs) with standard pulse/direction comms, and a RS485 Modbus port, 17 bit absolute encoders. Any recommendations on which mesa boards I should select would also be greatly appreciated (5i20 + ? + ?)>

Many thanks

Jono

Typically, Modbus is not suitable for precision coordinated motion because it is not a real time protocol
I does work well for things like controlling/monitoring spindles

Jono wrote: <I am using Dorna 3kW 3000rpm servos/drives (4 pcs) with standard pulse/direction comms, and a RS485 Modbus port, 17 bit absolute encoders. Any recommendations on which mesa boards I should select would also be greatly appreciated (5i20 + ? + ?)>

What is the encoder format? Do you need the encoders to communicate with LinuxCNC?

One thing that I will say is that I wouldn't be starting with a 5i20 any more, there are cheaper cards with the same number of pins, 5i24 for example.

Thanks for that. So, to summarise:

1) Modbus is not suitable for precision coordinated motion because it is not a real time protocol.
2) Mesa 5i20 card is now very old and there are better/cheaper/more-up-to-date cards available, for example 5i24, 5i25, 7i76E.

Regarding the encoder format - I have "17 Bit Serial (Absolute) encoders"

I do not know very much about this stuff at the moment, I just researched and determined I needed absolute encoders, and then I ordered the servos/drives/encoders as factory sets. I will be getting down to the brass tacks from here on in. I had planned to connect encoders to the drives initially, but had understood from my research that there was benefits to bringing the encoder signals back to linuxCNC (?) and was planning to determine and implement that down the track. I have attached the sections of the manual that may shed light on the encoder format.
[Note 1: initially I was planning an linuxCNC/EtherCAT application, but was concerned that this may have complexity that may cause me roadblocks, so then decided to proceed with step/dir servos/drives.]
[Note 2: I am a mechanical engineer, I am familiar with ubuntu to a moderate level.]

Question: Is there benefit to bringing the encoder signals back to linuxCNC ?

Regarding mesa cards for my application - after reading PCW's comments I had determined to use the ethernet 7i76, but after following the link and reading, and putting that with my prior linuxCNC ethernet readings, I have decided that the PCIe 6i25+7i76+(std linuxcnc distro) is the simple and safe option. If you can confirm that this is sensible choice for my application then I would be very thankful.

Question: Is there any downside to 6i25 + 7i76 + standard linuxcnc distro ?

Regards
Jono

Jono wrote: Question: Is there benefit to bringing the encoder signals back to linuxCNC ?

It sounds like the drives need the encoder data for commutation. So the encoders need to connect to the drives. With serial encoders it is very unlikely that that they can also connect to LinuxCNC.
Then the question becomes whether there is a way to get the absolute encoder position from the _drive_ to LinuxCNC. This could be handy, as it would mean that there is no need to home.

It can be advantageous to run the position control loop inside LinuxCNC. This is because you can "see" the PID loop, which makes tuning easier, and also means that the PID is running in a place where extra information is available (velocity and acceleration feedforward, for example. HAL knows the required velocity, whereas the drive can only see a single position command.)
To do this you would usually run the servo drives in velocity mode. (velocity loop internal to the drives, position loop in LinuxCNC). This traditionally uses analogue voltage control to signal the velocity command.

Question: Is there any downside to 6i25 + 7i76 + standard linuxcnc distro ?

It ties you to step/dir control, which isn't ideal for velocity control modes, but works very well in position control mode.

Andy, I thank you so very much for your information. It prompted me to a flurry of reading and study. I have also checked that my servo drives indeed have velocity control mode, and the servo drive I/O connection has Encoder A+, A-, B+, B-, Z+, Z- outputs/pins which I presume will be compatible with the encoder interfaces of a Mesa 7i77 analog servo control card (6 axis analog servo control, 6 x 8pin encoder inputs).

I have hurriedly canceled my 7i76 (twin boards) order and will place the new 7i77 order.

Please do correct me if I am misunderstanding the encoder output situation. I just need to get the initial Mesa card selection done right, then I will be able to get on with it without bothering these forum boards for a while!

Regards
Jono

Ps: Application servo design parameters (gantry router):
- Axis travel velocities (max) = 1 m/s
- Axis accelerations = 2 m/s2
- Servos = 3000rpm
- Reductions = 10:1 gear ratios

No, I don't think that you are misunderstanding the encoders.
It might even be the case that the encoders "count up" to the current absolute position when powered up and that you retain absolute position feedback. (if not then you will need home/limit switches, as on any other similar machine.

Hello Jono,
I am also building a CNC very much like yours. I would be very happy to share some information. How are you builinding the BC head? With harmonic drives or planetary gear or slew drives? I am wondering a lot at the moment about this.

Best regards,
Peter