Windows embedded (7) - repurposing a thin client PC

[Voicecoil]

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.

[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

[Voicecoil]

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.

[Kitwn]

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-Auto-Squaring-with-LinuxCNC-v-2-8

Kit

[m_c]

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!).

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

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

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

[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

[Doddy]

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.

[Clive S]

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)

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

[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

[Doddy]

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. :-)

[Kitwn]

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

[Clive S]

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

[Doddy]

<sorry, tried to post elsewhere>

[Clive S]

Yes sorry to the op

[Voicecoil]

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?

[Voicecoil]

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.

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

[Kitwn]

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.

[mekanik]

https://www.youtube.com/channel/UC1O0jDlG51N3jGf6_9t-9mw

[m_c]

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.

[Kitwn]

https://www.youtube.com/channel/UC1O0jDlG51N3jGf6_9t-9mw

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

Thanks mekanik.

[Kitwn]

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

[Voicecoil]

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

[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

[Kitwn]

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

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

[Doddy]

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

[Doddy]

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.

[Clive S]

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

I think Stretch is the preferred version for Mesa cards.


http://linuxcnc.org/downloads/

[Doddy]

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

[Voicecoil]

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.

[Doddy]

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.

[Voicecoil]

That's kind of odd - you would have thought that with a thin client in it's intended role getting all it's data and apps from the central server decent ethernet would have been the first thing they'd get right.

[Doddy]

Light weight IRQ handling? I don’t know.

As OP to this thread if you have the inclination to take this thread to a conclusion then I’d happily throw the 610 in your direction if you can source a W7CE install/licence. PM me if interested

[Voicecoil]

Well I've been using the machine for real for something like 4 weeks now, so thought I ought to report on what I ended up with computer-wise. My original plan to run UCCNC on the HP610 that Doddy kindly gifted me (or an old Dell I had knocking about) came to nowt as they wouldn't support the version of open GL that the latest version of UCCNC uses, so I swapped out for the Dell/Wyse D90D7 I was using to run my audio test gear (£30 from the Bay of fleas). Some probing about revealed that you can't easily get these devices to run any other version of Windoze apart from what they came with, so I set about trying to make it work on Windoze CES7. I deleted all the networking stuff and had a few fights with the FBWF (File Based Write Filter) that's used when it's a thin client, but after that it seems to work pretty well. To change anything you have to log in as Admin, but when it comes to actual machining, I just turn it on and plug in a USB stick with the G code files. If I wasn't working remotely from my design PC I's have had a shot at networking it, but since they're 3 miles apart we'll leave that for a bit.

[Doddy]

Interesting write-up - I think we all like the idea of a dedicated, small, contained (and in my case, cheap) controller. Something that doesn't bugger off on a 2 week vacation whilst it updates to the latest and greatest patch.

I have to admit that I don't practise what I preach and I prefer a machine that I can CAD/CAM and machine as an all-in-one, simply I do not have the space for multiple monitors, keyboards and mice (even now I'm behind KVMs for linux and windows with a WAN and two LANs for the two separate machine controllers).

Just a thought - and I'm showing my ignorance for CE - is there no general "config" file used to configure what is supposed to be a deployable embedded system - that you could offer as a starter-for-ten for others here that may want to use a similar thin client? (I'm thinking if the settings are held in a single file, rather than the usual bloated windows registry crap.

EDIT: "gifted"?, hardly, we came to an arrangement that you honoured.

[Voicecoil]

Just a thought - and I'm showing my ignorance for CE - is there no general "config" file used to configure what is supposed to be a deployable embedded system - that you could offer as a starter-for-ten for others here that may want to use a similar thin client? (I'm thinking if the settings are held in a single file, rather than the usual bloated windows registry crap.


Well, I spent a bit of time looking into that side of things - being a bit perfectionist I wanted to slim down the Windoze Compact Embedded (WCE) as much as possible - but didn't really manage to sort it. It appears you're largely stuck with what you've got, the only way to thoroughly customise it is to create your own WCE image which you then install that can have as few or as many features as you want. To do that requires a development kit, one day if I'm feeling brave and with a lot of time to kill I might just give Microsoft a buzz and find out how you get one, however I can't help but feel it will be expensive:disillusionment:.

PS there seem to be some 3rd party developers doing development kits which might be worth a look at too. With WCE7 coming to end of life in 2021, there might be something going cheap? :eagerness:

PPS Another thing I discovered is that WCE (unlike NT based versions) is a real time OS.



EDIT: "gifted"?, hardly, we came to an arrangement that you honoured.
Yes, with all the chaos of the last few weeks I'd forgotten that - but it was a generous arrangement and I thank you for it.

[jessieba]

You can easily do this using Windows. Compatible with DOS applications. Working in a Windows environment does not force you to give up using DOS programs. Moreover, to run DOS programs, as a rule, there is no need to exit Windows. However, DOS programs running Windows are slower. By the way, what I like about Windows is that it is absolutely unpretentious in terms of licenses. You can always find even Windows activation keys. For example, using a website mysoftwarekeys.com (https://mysoftwarekeys.com/product/microsoft-windows-10-pro-license-key) . I hope this information will help you.

[mra4nostop]

I found your write-up on repurposing a thin client PC quite interesting. I totally get the appeal of having a dedicated, compact, and cost-effective controller that doesn't go on vacation for software updates! Personally, I prefer an all-in-one machine for CAD/CAM purposes, considering the space constraints.
Regarding the configuration of embedded systems, I'm not an expert, but I think it would be great if there were a general "config" file that could simplify the process for others. Maybe someone in this forum knows more about it and can offer some insights.
Have you checked out the Reddit sub that discusses various Windows-related topics (https://www.reddit.com/r/cheapwindowskeys/comments/wjvsae/cheap_windows_keys/)? They might have some helpful information for you. It's a great community to connect with fellow Windows enthusiasts.