Windows embedded (7) - repurposing a thin client PC

[m_c]

I'm sure you would have many grateful readers of a detailed write up on that. Me among them.

Kit

The condensed version.

At the start we have the Trajectory planner, that takes the raw g-code, applies the machine parameters (acceleration, max speed, tolerances etc), and generates lots of little movement segments, with the time frame that those segments have to happen.

Those little segments then go to the motion controller, which generates the physical steps that cause the machine to move. The trajectory planner might output 1mm segments, it's up to the motion controller to convert those 1mm segments into step/dir pulses.


The motion controller is the time critical part of the process. The TP isn't. You could quite realistically run the TP and generate a huge buffer when you load your g-code, but I'll get on to that.
Now this is where real-time OS's come in. The real benefit of a RTOS, is it's deterministic, aka you know exactly when things will happen. If you want something to happen in 20uS time, it'll happen then. System interrupts won't stop that from happening in 20uS time. Another process using processor time won't stop that happening in 20uS time. It will happen in 20uS, which is something you can't guarantee in Windows, as it is not a RTOS.
This is how the core of LinuxCNC works, with the priority being updating the IO. The GUI has no priority over the IO, and can cause the screen to appear to crash during highload situations, as processing is directed to keeping the machine moving, not updating the screen.

Now the way Mach got around this problem, was Art essentially hacked the windows kernel, and attached a deterministic interrupt to drive the parallel port.

The limitation for both systems is you can only service the parallel port at a fixed speed, which is why you'll see lots of pulse jitter at certain speeds, as the motion controller fits the number of pulses needed to the available refresh rate (I.e. if you need 24'999Hz pulses, and you update speed is 25'000Hz, the only way to achieve that is to seemingly randomly drop a pulse and have a single pulse every 24'999 pulses that is twice the length of others).


To keep the motion controller going, it needs a regular stream of segments, which is why the TP creates a buffer. Due to the often complex nature of trajectory planning, some moves can take a lot of processing power, so you never want the risk of the MC becoming starved of moves, as the only option then is for things to grind to an abrupt halt.
As I've mentioned you could quite realistically buffer the entire g-code on loading, and provided nothing changes, everything would work perfectly well.

However, what if something changes. You hit Pause, or adjust a FRO?
This is where things get very murky.
You either need the MC to handle it directly using what parameters it knows, but that may result in moves out of tolerance, or for the TP to update the buffer.
How smoothly this happens, relies on how well integrated the TP and MC are, which for Mach with a parallel port, or LinuxCNC they are integrated and interact well.

However, this is where Mach3 falls down quite spectacularly using certain external motion controllers. Due to it's 10Hz update cycle, you have one delay as the MC updates Mach that something needs changed, Mach then has to implement that change by re-generating the motion buffer in a controlled fashion, then push the new buffer out to the MC, which it often doesn't have the ability to flush, so you have to wait for the previous buffer to be used before the adjustment physically happens. Have a 2 second buffer, and you're going to be waiting 2 seconds for that change to happen. Have a 0.1sec buffer, and you're very likely to suffer from regular buffer underrun errors.

Something else worth being aware off, is when using the parallel port, is each update takes a fixed amount of time. And that is time the computer won't be doing anything else, and is why there are limits on parallel ports speeds, although admittedly with modern processing speeds, it's much less of an issue.