Windows embedded (7) - repurposing a thin client PC

I'm thinking about using a thin client PC for controlling my machine. They're small + low power (so you could mount it inside the control box) & pretty cheap to get hold of. The issue seems to be the operating system, which typically is an embedded version of Windoze set up to run as a thin client - a small computer with little local storage on a network, all settings, apps and data are downloaded from the central server worked on and then returned to it. As such there are a lot of lock downs and pretty well everything is wiped at the end of a session. However Windoze embedded can do a lot more I'm told (I believe it's even been used in one or two In Car Entertainment head units) and would seem ideal for running a CNC machine as it has the power to run normal programs but without all the stuff like Office, Movie Maker and other such floobydust. And it's much smaller than a standard install and I guess might run a bit faster. The issue is how to configure it, the standard thin client setup isn't ideal, has anyone got any ideas please? I know it would be possible to simply delete Windoze and replace with Linux, but I don't have any experience of that and want to get machining ASAP - and I do rather like the look of the UCCNC controllers/software.

Had a quick look at the UCCNC website. They sell some little single board computers on there, presumably all compatible stuff with instructions.

Kit

Quote:

---

Originally Posted by Kitwn

Had a quick look at the UCCNC website. They sell some little single board computers on there, presumably all compatible stuff with instructions.
Kit

---

I see them, thanks for the suggestion. They look good, but they're not exactly cheap, likely £200 is by the time you've included carriage and an OS. My suggestion of the thin client was because there's loads of them available secondhand for between £20 and £60, if some way could be found to easily convert to a more friendly OS they might be a good solution for lots of us.

I know you didn't want to play with Linux but the cheapest option is to do a clean install of LinuxCNC and follow the instructions for updating to the beta version 2.8 (it's been a beta for years and is pretty solid by now) that allows seperate homing of two motors for one axis. You don't need to play with the OS and the setup is straight forward if a bit fidly. See the link below.

I'm not well up on using anything other than parallel ports for this, that may be the downfall for using a modern thin client though legacy machines may have one and you can get PCI cards with them on. Might not be quite so 'thin' once you've fitted it though:chuncky:

I'm no expert but is a low power, possibly low speed Windows machine going to have timing issues? Neither Windows or Linux are real time OSs and pulse timing isn't entirely accurate even on a full power board using LinuxCNC or MACH3. Other people will know more about this issue than I do.


http://www.mycncuk.com/threads/12687...LinuxCNC-v-2-8

Kit

Surely you could just wipe the embedded install, and install a full version of windows?
I'd guess that if it's capable of running windows embedded, it'll run the full version provided you're sensible about what options you install, and use a reasonably specced unit. A basic Win10 install doesn't need that much space, and performs well even low power machines.


Kit, provided you're using an external motion control, timing issues in windows are very unlikely to be a problem. As soon as you use an external motion controller, all motion is buffered, so provided the computer is capable of keeping the buffer topped up, it's not a problem. Those who do experience problems are normally pushing things to the limit, like a computer that meets the absolute bare minimum of specs, or using the same computer to do something processor intensive. There is also the potential issue of windows updates if you leave the computer connected to the outside world (I'd actually suggest win 10 pro, as it gives you much better control over updates if you do plan to have the computer online)

It's also worth mentioning that even in generic LinuxCNC there is a motion buffer, much to the chagrin of the zealots who brandish the whole 'real time' nugget without actually understanding what it means, or how it applies to the whole control process. Every CNC has buffers, it's just that some implementations are not exactly that robust or reactive (Mach3 with an external motion controller is probably one of the worst examples!).

Much depends on the target platform. For the el-cheapo thin clients, for which their price is a major differentiator, then these /tend/ to be the older, less capable platforms. I've been looking for parallel port support and these often come in with 1-2GB of flash storage, maybe 4GB at a push. MS advertise a 16GB/20GB install for 32/64 flavours of Win10. Going motion controller tends to kick the low-cost solution into the long grass unless you already own such a controller. I've been looking at the thin clients for very much the same reasons as Voicecoil, for a lathe install. Because UCCNC is not particularly lathe-friendly I'm now looking to avoid the whole mess of windows and trial LinuxCNC for the first time, but for that I think I need a machine with a parallel interface. I've got a couple of old desktops - not an ideal form-factor to bolt onto the side of a myford cabinet, but it's starting to look like the best, cheap solution for me.

We need to petition CNCDrive to port UCCNC to Linux :-)

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:numbness:

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.

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.

Quote:

---

Originally Posted by m_c

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

UCCNC on linux was a bit tongue in cheek, I’ve bought it and an UC300ETH for my mills, and would happily slave a couple of I/O for the lathe as well... but it doesn’t do Lathes well. The only reason I have any windows boxAnywhere in the house now is for UCCNC. I do most of the CAD/CAM in the warmth and use the cloud to transfer from Mac to windows in the shed where it gets final fettle before cutting.

Parallel ports?, if they work they can be reliable, they/the signaling doesn’t scare me. If I could find a reliable but cheap Ethernet motion controller for Linux CNCdrive then I will but first stop is trialling Linux CNC in anger before committing to a rabbit hole technology. My plan is to avoid windows where possible.

Doddy: If you need help with this I have my Myford s7 running on linuxcnc but through a mesa card with 2 mpg's so I can use it manually.

I am also setting a lathe up for a forum member with a PP running linuxcnc with an encoder (just A + Z) for threading you need 2 pins on the PP for this so three left for homing switches if you need them (I don't bother)

Doddy,
Using parallel ports has to be on the way out, it's still a cheap starting option for amateurs but it can't last. Trouble is there are now several other options available at various price levels with no clear winner for the inexperienced to choose.

Clive, much appreciated, I might well bend your ear. Encoder = shaft encoder I take it?, that was my plan, with one limit switch to avoid crunching the stepper on the cross slide (I foolishly went for a low profile stepper on the rear of a mount plate instead of the jefree front mount and it will impact the handle for the split nut engage lever

Quote:

---

Originally Posted by Kitwn

Doddy,
Using parallel ports has to be on the way out, it's still a cheap starting option for amateurs but it can't last. Trouble is there are now several other options available at various price levels with no clear winner for the inexperienced to choose.

---

Engineering is the art of doing for ten shillings what any fool can do for a pound. :-)

Quote:

---

Originally Posted by Doddy

Engineering is the art of doing for ten shillings what any fool can do for a pound. :-)

---

And for those of us who only have ten shillings available for this specific part of the project, the seventeen-and-sixpence solution is not an option. And having now totally confused all of our non-UK readers and all of our under-50-yearold UK readers, I'm done for today.

Kit

Quote:

---

Originally Posted by Doddy

Clive, much appreciated, I might well bend your ear. Encoder = shaft encoder I take it?, that was my plan, with one limit switch to avoid crunching the stepper on the cross slide (I foolishly went for a low profile stepper on the rear of a mount plate instead of the jefree front mount and it will impact the handle for the split nut engage lever

---

I actually made a 64 slot disc with slot opto sensors. https://photos.app.goo.gl/66KmdtD7TzUziNih7 you have to be able to move the sensors around to get the correct sync

edit: if I was to do it again I might have used a rotary encoder (it would have to be low count with a PP) But its been working for at least 3 - 4 years

https://photos.app.goo.gl/JH1GWVQbhxe6Z6Yo7 This is it simulating an arc that I needed to put on a roller for my belt sander

<sorry, tried to post elsewhere>

Yes sorry to the op

Quote:

---

Originally Posted by Doddy

We need to petition CNCDrive to port UCCNC to Linux :-)

---

+1 - If that happened I'd likely bite the bullet and go Linux - after my recent experiences with Windoze 10 I'm kind of over all things Microsoft. As I have Balazs from CNCdrive's email I might just suggest it ;-) - maybe others can do the same?

Quote:

---

Originally Posted by Doddy

Much depends on the target platform. For the el-cheapo thin clients, for which their price is a major differentiator, then these /tend/ to be the older, less capable platforms. I've been looking for parallel port support and these often come in with 1-2GB of flash storage, maybe 4GB at a push. MS advertise a 16GB/20GB install for 32/64 flavours of Win10. Going motion controller tends to kick the low-cost solution into the long grass unless you already own such a controller. I've been looking at the thin clients for very much the same reasons as Voicecoil, for a lathe install. Because UCCNC is not particularly lathe-friendly I'm now looking to avoid the whole mess of windows and trial LinuxCNC for the first time, but for that I think I need a machine with a parallel interface. I've got a couple of old desktops - not an ideal form-factor to bolt onto the side of a myford cabinet, but it's starting to look like the best, cheap solution for me.

---

Check out the HP T510 thin client. It has a parallel port, has a dual core CPU that benchmarks twice as fast as my old XP machine, can be found with 16GB flash and according to parkytowers takes Linux well. There were one or two on the bay of fleas for £50 ish last time I looked.

Quote:

---

Originally Posted by Kitwn

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.

m_c,
Thank you so much for that, it's cleared up a lot including exactly what Clive S meant in this comment from a thread I started last year...

"I am not sure why you sure why knocking linuxcnc saying that it "especially one requiring an antiquated parallel port" as that is not true. Stick any Mesa card in it and you will have pulse timing as fast and accurate as you will need. If you want Ethernet connected card then use a 7i76e card."

I've had a look around for information on using LinuxCNC with a MESA card and came across a YouTuber called Marco Reps in Germany. Slightly eccentric (I liked him immediately) he has an interesting video on exactly that. It drags on a bit (14 mins) and the first minute or so are not relevant but he goes on to describe some of the tools in LinuxCNC which I had no clue about, some of which are only used when tuning servo drives. He recommends the MESA 6i24 card

Kit

PS I should probably appologise to Voicecoil for starting what has amounted to a complete hijack of his original thread.

https://www.youtube.com/channel/UC1O...1N3jGf6_9t-9mw

It's worth mentioning that the parallel port was a good option for many years, and is more than adequate for the vast majority of machines. The main reason I wouldn't recommend it now, is there are too many potential issues in getting it working. You need a suitable motherboard. You've got to make sure the port settings are correct. You've got to hope Mach/LinuxCNC will play nicely with the motherboard. In the case of Mach, you need a suitable version of Windows.
None of which are insurmountable, but it's all things that can potentially add additional time and cost to getting a machine running.

To me, it's worth spending the extra money on a dedicated motion controller, as it removes quite a bit of uncertainty from the setup process. Plus it usually means you get improved support to get it working in the first place.

I wouldn't get too hung up on the ideal theoretical option, as in practise, and as the parallel port proves, things can still work very well even if they're far from theoretically ideal.

Servo tuning is whole other topic, but most closed loop capable controllers will have some form of tuning tools available. Dynomotion/KFlop tools are pretty advanced, and let you plot/adjust all sorts of things. CS-labs include a tuning screen, but IIRC it's pretty basic. Galil you have to buy their GDK to get servo tuning.

Quote:

---

Originally Posted by mekanik

https://www.youtube.com/channel/UC1O...1N3jGf6_9t-9mw

---

Oh yeah! I forgot the link! The video I watched is this one https://www.youtube.com/watch?v=1dy8Dgzcgq4

Thanks mekanik.

m_c,
Maybe I got lucky, but never had any trouble getting things working with the parallel port and LinuxCNC. I think some people have had trouble with add-on parallel cards rather than using an old mobo with it built in and I do remember some problems when I tried to use the on-board graphics of my current board rather than a separate card after the graphics card failed.

I've been using the same old PC and cheap chinese parallel break-out board since I built my forst 'proof-of-concept' machine out of scrap and the cheapest components I could buy and am still entirely happy with it. LinuxCNC is the only software I've ever used and have no desire to change if I can avoid it.

The risk with this approach is the lack of quick recovery from a computer failure. Not a problem for a pure hobbyist like me at present but for someone taking paid commissions the ability to grab any current motherboard, load the software, copy the .hal and .ini files (everyone DOES have a safe copy of those don't they?) and be confident of geting back in production is important. An external controller using a USB or Ethernet connection from the controlling computer is going to be a more reliable option in that regard.

Kit

Quote:

---

Originally Posted by Doddy

We need to petition CNCDrive to port UCCNC to Linux :-)

---

Well I did just that, and Balazs said he'd canvassed opinion on making it OS independent a year or so back, but didn't have much in the way of a response, and hence dropped the idea as it promised to be a lot of work.

I have the SAS on standby to recapture my hijacked thread (lol) - and did find this which could be a solution:
https://www.youtube.com/watch?v=R3g8VtJUdb4

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.

Quote:

---

Originally Posted by Doddy

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.

Quote:

---

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.

Quote:

---

, 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

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

Quote:

---

Originally Posted by Voicecoil

... just wish I had the time to properly learn a new OS

---

Just wish I had the available memory to properly learn ANY OS!

Glad you got your thread back, but it's been a very informative exchange.

Kit

Quote:

---

Originally Posted by Voicecoil

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.

Quote:

---

Originally Posted by Doddy

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.

I can get a new OS on okay, it's trialling UCCNC on W7CE (native install) that's problematic

Experience so far, dry-fitting a LinuxCNC install. Wheezy (Debian 7 based) has the latency test spiking around 130us, and Stetch (Debian 9) around 180us. Looking at the graphs these are frequent large spikes (circa 1-second, short duration - interrupts? but seemingly random in nature) against a baseline of around 20us. I've looked at SMI and power management - no gains there, and similarly with disconnecting Ethernet and WiFi. Under Wheezy I couldn't get WiFi operation (and it's too archaic to be a comfortable installation). Upgraded 4GB ram to 8GB ram under Stretch with no improvement (though general usage feels better).

Beautiful, small form-factor - the T610Plus is a nice, silent and cool running PC (the fan on a Raspberry Pi 4 drowns out the HP), good connectivity, but not good real-time performance out-of-the-box.

Having scrimped on this, I've now had to spend £300 on a 7176e card to support (though that's as much for the I/O that I want for MPGs and spindle encoders) - I don't think there was much mileage in using the PP for this. Of course, for a linux buff, if you can set core-affinities to OS/interrupts onto one core and LinuxCNC onto the second - your results may vary.

Quote:

---

Experience so far, dry-fitting a LinuxCNC install. Wheezy

---

I think Stretch is the preferred version for Mesa cards.


http://linuxcnc.org/downloads/

Clive - Cheers - clearly I shouldn't write early in the morning - I meant Stretch (not Squeeze) - I've amended the post above.

Quote:

---

Originally Posted by Doddy

Of course, for a linux buff, if you can set core-affinities to OS/interrupts onto one core and LinuxCNC onto the second - your results may vary.

---

That's cool, didn't realise you could do stuff like that.

Okay, perhaps a little premature but this is the first day that I've had a controller wired-up (standalone stepper), the Mesa 7i76E and the thin-client (T610 plus, 8GB memory).

I knew the latency test was a bit mheh!, averaging around 200us but figured having an Ethernet motion controller would offset that. Prior to this I'd been doing all the Debian updates, updates to non-free graphic drivers, increasing system memory, and following as many (diverse!) opinions on tuning a LinuxCNC installation as I could as well as disabling all power-management under the BIOS. Now, this was the first time I've had to configure an interface (previously ran under the simulation mode for familiarisation), but in a nut-shell... it's pants! Frequent error messages through through what appears to be loss of ethernet packets. I've tried point-to-point as well as through a standalone switch - I can run from seconds to minutes, but ultimately it fails.

Still treading carefully on new territory for me, I've reconfigured an old XP box (Viglen Genie - great little boxes) previously used for Mach/PP/Ethernet to LinuxCNC (latest, and same install as the thin client). 40 minutes later I've got rock-solid performance and latency in the 3-6us range.

Perhaps will a bit of tlc the thin client is a possibility, but facing a number of learning curves at this time I'm taking it off the table for now and sticking with a standard machine, which, thinking about it, cost less than the thin client and is only marginally larger.

Your experience may vary.

EDIT:

For S&Gs, if I get time this afternoon I might try walking the path of getting LinuxCNC onto a RaspPi4 that's otherwise collecting dust.