Windows embedded (7) - repurposing a thin client PC

[Doddy]

Aha, didn't notice the "plus" range. Okay, one in the post and I'm going to try a LinuxCNC / parallel-port install.

If you'd like I'd be happy to try installing UCCNC in demo mode prior to the linux install, to understand any installation issues, though with the licensing I don't think I'll be able to drive my mill directly - but I think if the demo works then it should be just about there.

[Voicecoil]

Aha, didn't notice the "plus" range.

They give you rather more room to fit an HDD and if you wanted to run LinuxCNC using one of the Mesa controllers that has a PCI card, then there's room for that as well. However I suspect with a suitable compact operating system (i.e. not full Windoze 8/10) and using the machine purely for running the CNC, a 16GB flash DOM would likely suffice.

If you'd like I'd be happy to try installing UCCNC in demo mode prior to the linux install, to understand any installation issues, though with the licensing I don't think I'll be able to drive my mill directly - but I think if the demo works then it should be just about there.

That would be cool, thanks.

[Clive S]

, a 16GB flash DOM would likely suffice.

I used to run my Warco on a 8GB DOM using linuxcnc I still run it on the lathe. plugged into a small MB. I am following this thread with interest

[Voicecoil]

If you're looking to put Linux on a thin client PC, then there's quite a bit of useful info. here:
https://www.parkytowers.me.uk/thin/
... just wish I had the time to properly learn a new OS

[Doddy]

That would be cool, thanks.

Dammit!, the box is literally straight from a (corporate) install - it's trying to logon to their CE network servers, prompting for login/password credentials. I don't think I'm going to be able to pull anything together re. a Win7CE install.

[Voicecoil]

Dammit!, the box is literally straight from a (corporate) install - it's trying to logon to their CE network servers, prompting for login/password credentials. I don't think I'm going to be able to pull anything together re. a Win7CE install.

Does it seem to be running Windoze? if so you might be get round it by logging in as administrator - a quick google should pull up the default password. What you've got seems to be fairly common, there's info. out there for how to get round it and put on a new OS.

[Kitwn]

m-c,
My understanding is that the best controllers are simply taking their control data and the raw G-code from the PC and generating all the control pulses themselves without having any of the other calls on their processor that go with running an operating system at the same time. This has to be the best way to go in terms of optimum pulse timing but is also the more expensive option. Being able to download a G-code file via ethernet and let it run while the computer is used for other purposes is also an advantage of these more modern designs and is definitely the best way to go both technically and for ease of operation and throughput of work.

My recommendation of LinuxCNC on an old PC is primarily aimed at budget conscious hobbyists like myself. It's cheap, it works, it lets you concentrate the available budget on the mechanical hardware when you first get going. Then you can start making things while you learn just how many worms there are in the CNC can

I use a dedicated PC running only LinuxCNC and did some measurements of step pulse timing a while back. What should have been a continuous stream of pulses at 125uS intervals had most pulses at 125uS but a fairly regular pattern of intervals of 100uS and 150uS as well. There isn't any obvious vibration on the machine, but this is the only CNC machine I have ever used of so haven't any experience of perfectly timed pulses to compare it with.

In the unlikely event of finding myself with nothing else to do I could try building an oscillator to produce a well timed series of pulses and make a comparison but that's not going to happen anytime soon.

Kit

PS Doddy: Saw your reply after finishing the above blather. LinuxCNC is fairly easy to get going if you build a vanilla 4 motor machine and will run perfectly well on an old Windows-XP era motherboard. The LinuxCNC forum is very helpful.

[m_c]

Doddy, personally I wouldn't recommend using a parallel port to anyone now, as even LinucCNC has compatability issues. However, it's always worth a try before buying an external motion controller, especially if you're build is using a parallel port BOB.
A UC100 is only €80, if that fails.
And I very much doubt that if UCCNC ever gets ported to linux, it'll be free.

Kit, only standalone controllers take the raw g-code. Everything else, the PC is taking the G-code, and generating a buffer of small movements, which are then sent to the motion controller. There is a quite a grey area though, as to how much is handled by the PC, how much is handled by the motion controller, and how the two interact. I can explain more, but I've not got time just now.

[Kitwn]

I can explain more, but I've not got time just now.

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

Kit

[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.