The right answer would be very comprehensive, so I will try to answer the basics.
You are right about using counters to determine position setpoint.
does its performance differ from a servo drive that uses serial
interface to get the required position directly ?
Yes, because digital data is being sent cyclicaly at detrministic time, while Step/Dir would require a FPGA/ASIC to calculate speed setpoint from frequency/period measurment of pulses, making the setpoint information non-deterministic which indeed is not a good thing for forwarding to the PID loop. There is a first order lag filter to bring the velocity setpoint more smooth.
Further, digital data can have both velocity and position setpoint, no need to derivate from pulses frequency.
the main concern is motion planning because in such drive you are not
feeding the steps slowly at start and stop to control the acceleration
and deceleration ?
This is incorrect. The setpoint has to have the implementation of motion profile, where acc/decc speed has taken into account. Things are not to be driven with a burst of pulses, rather a controled way of sending pulses with specific motion profile.
There are different drives/approaches:
1. Single axis, non synchronized: You can have a motion profile generator built in the drive, then you just send position setpoint, the drive does the rest with parameters jerk, acc, dec, speed.
2. Mutiaxis, sychronized move: The drive works like a velocity controller, the motion planning and position regulation loop is calculated in a host system. The digital data are: speed,...
Single Axis (built-in motion profile generator). Usually you send over serial comm. Target position and control bits:
- Servo on, Enable: applies power to the motor and disengages the brake (if equiped)
- /Stop: the drive coast to standstill with determined ramp, used for stopping the machine in a frindly way
- /StopE: the drive coasts to standstill with very high deceleration, to be used for emergency stop
- PosEnable - set this bit to enable positioning move, drive moves to target position
Then you have some status bits, for your app, maybe a bit that indicates position done is important. When drive reaches the target position it sets this bit, but due to the communication lag you never exactly know if this bit refers to the actual or to the previous movement. You should do some tricks to evaluate this bit according to actual position and target position and make a your own piece of code that will look this bit when the drive is in the tolerance window. Or another good way is to loopback the target position from the drive to the host, this is possible if you can set up a user defined communication telegram.
Drives I was working with (Siemens, Lenze, SEW, Indramat) allow the change of target position while positioning is active, new profile is calculated from actual position, speed,...I think this is a basic function of all drives with built-in profile generator.