The idea of motion segments is where this has been heading from the beginning. Phase accumulation for frequency synthesis is very interesting but frequency is a side issue for CNC. The axes could all have different acceleration slopes (set by the user in Mach3) and yet they all manage to output pulses in the exact instant as part of the 3 dimensional motion. A single G01 command can move all 5 axes (if the machine has 5 axes) and expect everything to work out.
So, now that dealing with motion segments is laid out, maybe your idea of implementing it in a CPLD is the way to go. Then let the Arduino (I would prefer ARM) do the number crunching to build up the motion segments.
I have been thinking about this all the way home on my moped... nearly hit a car when I realized this direction of following grbl won't help me
making motion segment packets is all good for CNC as you don't do any interruptions while it's operating. I guess I never specified this in full detail when we began discussing, Here is a project summery:
Level 1 (User Interface Level / PLC)
The user interface consists of an IDE allowing the consumer to program the unit with a basic scripting language. This language allows people to program it in a high-level way, telling the controller to execute commands based on I/O, timing and serial input commands. The user can also link Interrupts from I/O and timers to commands (Moved back and forth every 2 seconds, begin turning at a speed relative to an analog input, or go to a position in relation to the analog voltage range.) Consider it programmable in a way similar to a PLC.
Level 2 (Motion Controller)
The Motion Controller does what the Level 1 Abstraction layer instructs it to. The motion controller is responsible for Profiled Velocity and Position (It handles acceleration, deceleration and position) It can take an encoder feedback. Settings such as Max Acceleration, Max Deceleration, Max Velocity can be set by the PLC Abstraction layer. I would like to include some form of Jerk control too in the future.
There will need to be some form of PID loop for the closed loop encoder feedback, however I consider the encoder feedback to be a secondary goal, my first design generation can do without it.
The unit needs to be a real time motion controller that is coupled with a PLC like implementation on the MCU, possibly using an arduino as a co-processor for the user to program in entirety. The user at any time could change the destination position, set it to go at a specific velocity etc and the motion needs to follow as so. This is where I'm focusing on.
The user at any time could change the destination isn't supported by physics. It simply isn't possible to be running full speed in some direction and make a sudden left turn. The previous motion command would need to be complete before another command could be accepted. Sure, it is possible to abort a previous command but some deceleration is still going to be required. Unless mass is VERY low.
We had this very problem in the early days of NC where the programmers weren't thinking clearly about deceleration into a corner. They were trying to make a right turn with a gantry weighing tens of tons with hundreds of cutting horsepower. Of course there was overshoot! And a lot of equipment damage...
Following error, that's the trick! There was a lag between commanded position and actual position. That difference was measured and used to control the hydraulic servo valves, PID like. This automatically takes care of acceleration and deceleration. I have no idea how to use that concept with stepper motors.
You took that too literally, this is already a system implemented on all motion controllers.
You set an acceleration and deceleration for your motion controller
if you command a velocity, it accelerates up to said velocity, then if you command a new one, it decelerates down to the velocity.
If you set the controller to go to position A in one direction, then tell it to go to position B in the other direction, it will decelerate and accelerate in the opposite direction.
Sorry if I'm not stating it clearly enough, I forget not everyone is in the same field as me (I'm primarily a motion control engineer)
Stepper motors operate on a simple 'you input a pulse, I move one pulse' if you put too many pulses in without acceleration, it stalls. Quite simple really.
I'll be adding in closed loop later, but for now that won't be needed (I'd implement the closed loop in the MCU anyway, I don't fancy doing PI loops in a CPLD / FPGA yet.)
The actual project I'm working on for my HNC will be used for automation primarily, it's not for CNC machining(only one axis)
An example might be that a user has an endstop on a bandsaw with a stepper motor, the stepper motor moves it in and out so that he can enter the distance it wants to be at.
The user would program my project to home to a known distance on power up and follow commands from a RS422 port for example on where to go.
Or maybe it's taking advantage of the analog input, following the position to the potentiometer, the position controlling, for example, a gantry crane arm:
The user has programmed the drive to scale the 0-1023 / 0-4096 counts to the full distance (possibly with a filter) so the potentiometer is a scale version of the gantry,
the gantry will then follow along and accelerate at a programmed speed verified to be safe for the unit.
These are the kind of applications the company that pays for my HNC course comes across, we currently distribute products for this, but they are often over-complicated / over featured for what is needed, this is where my unit fits in. (We have controllers suitable for 64axis linear motor arrays for nano-motion / automation, but nothing for more run-of-the-mill applications.