Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Deftware Industries

A member registered May 30, 2015 · View creator page →

Creator of

Recent community posts

Oh boy. If another program is able to use GL2.1 then it sounds like your drivers are at least installed right, but something is blocking PixelCNC from using them properly and Windows is defaulting to the fallback Microsoft driver.  In all my days of programming and using Windows I have never seen anything like this, that's 20+ years. The closest I've seen is that if one program can't use OpenGL, none of them can.Well, this gives me more hope than ever before that we can get it running for you but it looks like the ball is fully in my court now and you've nothing left to do on your end. I'm going to do some investigating and I'll email you a link in a day or two to one or more new PixelCNC executables you can place in your PixelCNC folder to run  instead, so we can start narrowing down the problem. Good work!

Maybe? But you wouldn't have been able to run the 64-bit driver packages if you were running a 32-bit windows, unless for some reason the driver packages were just 32-bit extractor/installers and you've been installing 64-bit drivers on a 32-bit OS. You can right-click the My Computer icon on the desktop and click Properties, or open System from the Control Panel.

Ah, the chipset drivers may play an important role: they support the underlying system. Considering that your 'GPU' is actually a piece of the CPU I think that maybe it's a good idea to make sure you have all of those drivers up-to-date. I know that you already updated your BIOS to the latest version, and there's a distinct possibility that updating your BIOS without running up-to-date chipset drivers could lead to something like other devices not operating properly (like the integrated GPU). From what I've read a lot of people have had problems getting drivers to work right on older laptops, especially when it comes to getting OpenGL to work, which is something I've never had problems with.

I suppose you could go back to the Dell support page for your laptop and have it auto-detect all the drivers you need, and download/install them. Be sure to reboot between driver installs!

Drivers can be finicky, and they take some finesse. I know that it's possible to get your laptop running properly, it just takes time and persistence.

The GL extensions viewer won't work if you don't have the right OpenGL driver installed - it works by interacting with OpenGL, which in your case will be stuck dealing with the Microsoft GDI/Software rendering driver, and will not show you anything about your Intel GPU.

Visit the Dell website and let the auto-detect tell you everything that you need to install. Install the chipset drivers to make sure that Windows isn't unable to control the low level hardware systems.

Also, yes, the 32-bit drivers will not work because you're running a 64-bit version of Windows. You could install a 32-bit version, and then only be able to run 32-bit drivers/software. Windows 64-bit can run 32-bit software just fine, so there's really no reason to run a 32-bit version unless your CPU is 32-bit, at which point you'd have no recourse anyway.

There's always the option of emailing Dell, and telling them you had Windows 10 but decided to downgrade back to Windows 7 because your OpenGL drivers weren't working, and you still haven't been able to get them working. I don't know if they'd help someone with an older laptop that was bought second-hand, but you never know!

I'm a bit baffled that no driver has managed to make the Microsoft OpenGL driver budge at all. There must be something we are missing, or something that you could be overlooking simply due to being less experienced with PCs. I can't imagine what it could be, but it seems like there must be something. Right now it sounds like there's a very good chance the chipset drivers could be the issue. Be sure to install them and *then* install the graphics driver afterwards. I'd suggest sticking with the newest graphics driver that pops up for your i5-520M CPU on the Intel website.

 According to Dell's specs for the e6410 your CPU is either a i5-520M, i5-540M or i7-620M. You can look up your CPU on Intel's website (or Google it, and the Intel page will show up first) and from there go to the downloads link on the left side of the page. From there I'd try the first Intel Graphics download there is. I suppose you could continue extracting the drivers to a folder and manually installing, just to be safe.

Also, be sure you reboot after each driver install. If you install the right driver but try running PixelCNC without rebooting it will still be using whatever driver was already present - instead of the newly installed one. Windows needs to boot with the new driver installed in order for software to be able to utilize whatever functionality the driver exposes, otherwise it just lies dormant, waiting for the reboot, so it can fully swap in the new drivers in place of the ones already being used.

I think the key is definitely going to be finding the right driver for your CPU's graphics functionality. You should be able to see exactly which CPU you have in the device manager under 'Processors', and google that. It should be something iX-YYYM where 'X' is either 5 or 7 and YYY is a 3-digit number.

All I know for sure is that your machine is plenty new to have at least GL 2.0 hardware built into it, and it's just a matter of hunting down the right driver.

(2 edits)

I would try manually downloading the drivers on Intel's website if their auto-detect just directed you to the Dell website. At first glance it looks like there's a couple viable options, but you're going to want to go back to the oldest Intel version they have (i.e. definitely not 4th gen). The driver that will work is probably also either only Windows 7 or a combo of Windows 7/8.1. You might want to try just downloading a couple of them that look like they might be right, I'd start with the oldest one they offer and work your way forward in time, trying each one.

(1 edit)

Dang! EDIT: I think that your system does not have the GMA, and therefore wasn't going to install the drivers for it. The Intel Turbo Boost is just a CPU feature that's unrelated. You either have an Nvidia 3d gfx built in ontop of your Intel HD, or we need to try drivers straight from Intel.

I did just find this:

It's not the exact same as your laptop, but apparently some people have had better luck installing drivers directly from Intel, instead of from Dell. I also just realized that the Minecraft forum guy also says to download the drivers directly from Intel, and not the Dell website. I wonder if this would've worked for you with Win10 installed still (Win7 is still better).

I suppose you could use the auto-detect utility they have on their site:

You might already have perfectly usable drivers for everything else already, so I'd suggest just manually seeking whatever graphics/video driver is listed by the auto-detect results. Then go ahead and try a manual extract/install like you were doing before with the Have Disk route. This *has* to work.

Fingers are crossed!

1.948 GL_VENDOR: Microsoft Corporation  <--- this should say 'Intel'
1.948 GL_VERSION: 1.1.0

It is still saying that you're running the default Windows driver for OpenGL, which is just a placeholder/last-resort/fallback when either there's no graphics hardware present, or no proper driver for graphics hardware that's present. I suggest trying to install the 'Intel GMA' driver that I mentioned previously instead. It might just do the trick.

Also, I did find a forum post where a guy explained a solution for people with Dell Latitude laptops that couldn't get their Intel HD drivers to install properly to play Minecraft because of OpenGL problems just like you are having. His solution was to manually install the drivers instead of letting the downloaded EXE file install them automatically.

So there's two things I suggest you try. First see if the Intel HD 'GMA' driver solves the OpenGL problem: (

If that still does not work then I believe that this guy's forum thread he started about fixing OpenGL support on Intel HD for Dell laptops might be the key. He said that instead of installing it using the driver download EXE's built-in driver installer, he said to go for the 'extract only' option beneath that - where it simply writes the files out to a user-specified destination (i.e. a folder on your desktop). From there you can go into device-manager and into the Intel HD display adapter properties, and click the 'Update Driver' button (which is visible on the last screenshot you posted). From there you can direct Windows where it should seek for the drivers you want it to install, pointing it to the files extracted from the downloaded driver EXE package. He says that after hours of trying to install drivers to play Minecraft it was the only thing that worked, and several other people replied saying that it worked for them too. I believe this sounds promising.

Similar to PixelCNC, Minecraft also has a minimum OpenGL version that it requires (and so do a lot of other OpenGL programs) so it stands to reason that perhaps the Dell driver installer for your laptop (or the specific Intel HD hardware it includes drivers for) does not work properly when it comes to making sure it sets up an installed OpenGL portion of the driver.

I believe that it's worth trying both installing the GMA driver, to see if that works, and also trying the manual installation of the driver via the 'Driver' tab's "Update Driver" button that I explained above ...and I just remembered, I read that there's also (potentially) an Nvidia GPU in your laptop - which makes Intel HD look amateur by comparison, performance-wise and in its functionality. I assumed that what I read about your laptop meant that there are certain versions of it which either include the Nvidia GPU or the Intel HD, but not both, but maybe your laptop actually has an Nvidia GPU in combination with Intel HD (Intel for 2D, Nvidia for OpenGL/DirectX graphics) and it could be the "Unknown Device" listed in your Device Manager? You could try downloading the Nvidia driver on the Dell drivers page for your laptop. There seems to be two of them, one just named 'Nvidia Graphics Driver' and then another called 'Nvidia Quadro FX .... NVS 3100 ...'  Perhaps they might be worth a shot too. You're definitely going to want to figure out how to get legitimate 3D software running on your machine one way or another, otherwise the laptop as a whole will not be able to run anything but 90's 3D software :(

"Nvidia Graphics Driver"
"Nvidia Quadro FX... NVS 3100M"

The big clue is that it still says 'Microsoft Corporation' as the driver provider, which means that there has yet to be an actual legitimate Intel OpenGL driver installed for the graphics hardware, so to my mind it's a matter of figuring out how to wrestle the proper driver in there. I think that the guy who claimed that manually installing the drivers from the Device Manager might be on to something, because I know for a fact that even the version driver you were running in Windows 10 supports GL 2.1, but it still said you were running a Microsoft OpenGL driver, so perhaps his 'trick' is the only way to get the OpenGL component of the driver to properly install for your system. (Here's the Minecraft forum thread:

Between the GMA driver, the manual driver-update, and the possibility of an Nvidia GPU hiding under your keyboard, I believe that there's a high probability that all of your efforts will pay off and you'll finally be able to use PixelCNC (among other 3D software).  After you try these last ideas I can think of, and it proves unsuccessful, we can discuss what options there are for your compensation or reimbursement - for your purchase that you're unable to use. You could always hold on to your copy until you find a way to get it running, whether on a new machine, or by managing to find a way to get the driver situation figured out. But, I cannot in good conscience keep your money if you're unable to use PixelCNC, not unless you were to otherwise agree to some kind of new terms or conditions, or we come up with another specially-tailored peripheral deal first. I think that one of these ideas has to work, and that you'll be generating toolpaths like it's going out of style soon. My fingers are crossed! :D

Good luck, and godspeed!

Also, are you sure that the driver is installing properly? I'm also wondering if it's the Intel GMA driver you should be installing. The other one was working for people on Windows 10 just to get their system working, but I don't know for a fact that it was also giving them OpenGL 2.1 functionality as well. I suggest trying the GMA driver (, and make sure that it's actually installing by going back into Device Manager and checking out the driver tab on your Intel display adapter's properties dialog box. You should be able to right-click the "My Computer" icon on the desktop and click 'Properties' there to get to a system control panel screen - where there is a 'Device Manager' link on the top left.

It's important that you make sure the driver is actually being used by the graphics hardware, because installing the wrong driver will cause it to automatically revert to one that worked previously.

Oh boy, I can't believe it. The Intel HD in there should be able to run at *least* OpenGL 2.1, even with the driver version you had before. The log file should be in a very similar place: C:\Users\<username>\AppData\Deftware Industries\PixelCNC\

I'm curious to see what it says now, but if the GL version is at 2.0/2.1 then the problem is something I think my workaround will actually fix!

Yes, as long as you can log into with your account (which you seem to be able to do if you can post on this messageboard) then you should still have access to the latest PixelCNC download. I admire your courage and persistence! :)

My apologies! I forgot that on Windows 10 "hidden items" must be enabled via the 'View' menu when looking at the DELL folder's contents - and then the AppData folder will appear. Alternatively you can type the folder name in the address bar and it will still allow you to access it whether or not you have hidden items enabled.

Okay, this right here is pretty funky:

7.573 GL_VENDOR: Microsoft Corporation
7.584 GL_VERSION: 1.1.0

GL v1.1 is the very oldest version of OpenGL. Right now PixelCNC tries to create a v2.0 rendering context, which grants it the functionality it needs to draw everything to the screen quickly, and utilize the graphics hardware for some peripheral calculations. According to some Google searches, your Intel HD driver (v8.15.10.2900) should support up to OpenGL v2.1. The fact that it says Microsoft has me thinking it's not even using your Intel HD hardware at all, and is running an OpenGL driver that is emulating graphics hardware on the CPU (aka 'software'). That's not going to fly.

It looks like your only options are to either install a new driver from the Dell support page, downgrade to Windows 7 if the driver doesn't work, or find a new computer to use. Honestly, this entire situation originated from the fact that Windows 10 should not have been installed on such an old machine. Windows 7/Vista would've been fine. 

There's a good chance the driver will work and you'll be on your way:

The biggest problem people seem to have is their screen becomes 'disabled' after installing the driver. If this happens when you boot your machine back up just let it sit for a minute, and then try pressing Windows Key + P simultaneously to switch through the various Screen/Projector modes and it should bring the screen back up after one or more tries. For some reason the driver will default to outputting on the video port, for a projector or external monitor, which just requires switching it back to the internal display.

Good luck!

(1 edit)

No worries about the delay. Your search did, however, show you exactly the folder path I suggested your PixelCNC log files would be in. Here's the search result that was in your first screenshot which you can click on to see the log files:

You can manually navigate the folders on your harddrive to get to the folder indicated by a filepath, which in this case is 'C:\Users\DELL\AppData\Roaming\Deftware Industries\PixelCNC\'.  Just open each folder successively that is named in the filepath, no need for performing an excessive search. Your computer is just a little machine with some files/folders and configuration options organized hierarchically, like a tree :) It's nothing like a vast world wide web, and as such can be navigated much more succinctly.

Just go to your C: drive and open the 'Users' folder, and then the 'DELL' folder (the name of the Windows user that you are logged in with), then 'AppData' (where programs store peripheral/auxillary information), 'Roaming' (application info that is shared between users of the machine), 'Deftware Industries' (where any of my software would store its stuff) and finally 'PixelCNC' (the specific program in question). The log files will be in there. Easy-peasy :D

On a personal note, I suggest that it wouldn't hurt to sometime go crazy and just surf your machine and all of its options, menus, and folders, just to familiarize yourself with the where-and-how of everything. It's an investment that will pay back in dividends, guaranteed. There are many more folders all over the harddrive, but the important places are really just "C:\Users\", "C:\Program Files\" or "C:\Program Files (x86)\" depending on whether a program is 32-bit or 64-bit, and the "C:\Windows\" folder - which you will probably never need to go into unless you become a total PC expert. The rest of Windows comprises Windows/system configuration stuff, which is not on the harddrive but instead located in Windows' menus and interface.

The big one is the 'Control Panel', which has been around since Win95. You can get to that by right-clicking the start menu button (in Win10) and clicking 'Control Panel'. From there you can work with any and all of your computer's installed devices, hardware, etc.. and their configuration. The other powerful Windows dialog is the 'Task Manager', (around since Win95 too) which is also accessible from a right-click on the start menu, or by pressing Control-Alt-Delete (famously referred to as the 'three-finger-salute') and clicking 'Task Manager' on the options that popup. The task manager will let you see all of the running programs, their resource consumption (CPU/RAM/Harddrive), as well as running background 'services', which are basically programs that operate 'behind the curtain' to make Windows happen. Don't be afraid to get to know your machine! :)

Let me know how I can send a link to you privately. The link will be to a download of a custom version of the PixelCNC executable file, which you can then replace your existing one with to see if my workaround resolves your OpenGL driver issue.

(2 edits)

Okay, I've done some more reading, and I think that you are possibly running a usable driver, but something is off. Could you find your PixelCNC log file and paste it here for me to see? It should be located somewhere such as:

"C:\Users\DELL\AppData\Roaming\Deftware Industries\PixelCNC\"

There will probably be a few log files, one for each time PixelCNC was run, but because you're experiencing the same issue they are probably all pretty much identical. Open the most recent one and paste its contents into a reply and we'll see what we can figure out. I might be able to code a work-around. Your hardware is right on the edge of being compatible so maybe something is tripping it up and causing it to default to an older version of OpenGL where glActiveTexture isn't supported.

EDIT: I think I found a way to work around the problem and get it working. I could still use the log file if you don't mind, but other than that you shouldn't have to worry about doing anything more to your system. I'll have a download link for you to replace your PixelCNC exe with to test out the patch in a few hours from now.

(2 edits)

Hi Macboy, did you determine which  graphics hardware you have in your laptop? I'm still fully confident we can get you up and running but I'm going to have to be up-front in saying that it appears as though you may have downloaded and installed a driver for your laptop other than the one for your graphics hardware. Can you tell me which driver(s) you installed?

EDIT: Before you follow through on the instructions I provided below, the black/console window that you snapped a picture of provides more information about your graphics hardware that it detects, and other useful information that will help me solve the problem. Scroll to the top of the window to the beginning of the output that PixelCNC generates there, and it should mention a GL_VENDOR and GL_VERSION. You don't actually have to take a screenshot, just telling me what it says there would be useful, but it sounds like you'll need to do a bit more work getting your system properly configured.

You mentioned BIOS updates, which are not related to graphics drivers, and should've only installed if you made it a point to install all of the drivers that the Dell page auto-detected that your system needs - which should've included the graphics hardware driver. Otherwise, if you made it a point to manually seek out and install the graphics driver by itself then BIOS updates would've only installed if you had accidentally mistaken a driver with "Intel" in the name as being the graphics driver. There are multiple drivers for your system with 'Intel' in the name which are not actually graphics hardware drivers. The Intel graphics drivers are distinguished from other various Intel drivers by the 'HD' or 'GMA' suffix that follows 'Intel' in their name. This is because your system has an Intel CPU and other Intel components, and therefore uses multiple Intel provided drivers.

Apologies if I am completely underestimating your aptitude, ability, or awareness, and you actually managed to install the proper graphics driver. I cannot stress enough that am not trying to be insulting or condescending by assuming a mistake, I am just going on the clues and evidence I have available to me, and I recognize that there's a distinct possibility that you may have simply installed a motherboard/BIOS Intel driver instead of the graphics driver, purely by mistake. There's also the possibility that because you have Windows 10 installed on an older laptop that is no longer supported by Dell that the automatic driver detector simply did not provide a graphics driver in the list of drivers it displayed to you - because there are no Windows 10 drivers for your laptop. If that's the case then you will simply need to manually install an older  driver, which will work fine regardless. Likely a 32-bit Windows 7 driver, if your system actually is 32-bit as you mentioned before, as Windows 7 was the last OS that Dell supported for that laptop, and thus provided drivers for.

I can assure you that whether your laptop has an Intel 'HD'/'GMA' or an Nvidia graphics processor that it will run PixelCNC - and be able to access long-existing OpenGL functions such as glActiveTexture which have been standard for nearly two decades. So something must be preventing your machine's graphics capabilities from being utilized, and in my experience the wrong drivers (or missing drivers) are the culprit. Also, the link to the glActiveTexture bug page you found was actually a discussion between programmers about writing software that utilizes the function, and erratic behavior one programmer was experiencing, which is unrelated to the problem you're experiencing.  "glActiveTexture" is one of many graphics functions that PixelCNC is unable to utilize from your hardware, and is only the very first one that it attempts to confirm accessibility for. A failure to access the function automatically prevents PixelCNC from attempting to access the rest of the graphics functions that it needs so that users are not bombarded by a barrage of error boxes for all of the missing graphics functions. The fact that PixelCNC errors out with "glActiveTexture" as being what the error specifies is purely incidental, and not specific to the glActiveTexture function itself. The problem lies in the graphics hardware not being properly configured for software to be able to access, which just means we need to make sure it's configured properly ;)

We can get to the bottom of the graphics hardware situation directly by seeing what Windows says about it. To do that you can look for yourself to see what graphics hardware you have, and what driver is currently installed for it - which I imagine is the default "Microsoft" provided driver that only grants very basic minimal functionality. It's provided as a last-resort graphics driver when the correct driver is not found. Without this default fall back driver Windows wouldn't be visible on the screen at all when the proper driver can't be located, so Microsoft provides it for convenience purposes. The problem is that it doesn't implement the advanced graphics features that the hardware offers, or that modern software utilizes, so it causes problems like the one you're experience when running proper hardware-enabled 3D software.

Take a look at what you have installed, and we'll have all the information we need. Start by right-clicking on your start menu button, which will pop up a 'context menu', and go to 'Device Manager', just like in this screenshot:

Device manager in the context menu

Once you're there look under "Display Adapters" by clicking on it to see what graphics hardware your system includes:

 I'd like to know what it says under there. I'd also like to know what driver is installed, so once you see what's listed under Display Adapters go ahead and right-click on whatever display adapter is listed under there and click 'Properties'.

This will pop up a dialog with information about your graphics hardware. There will be a row of tabs across the top: "General", "Driver", "Details", "Events", and "Resources".

Click the "Driver" tab and tell me what it says under "Driver Provider", "Driver Date", and "Driver Version", along with the name of the graphics hardware immediately above that. In this image from my netbook you can see it says "Intel(R) HD Graphics" as the adapter name at the top, next to the screen icon, and then "Intel Corporation" for the provider, "11/10/2016" for the date, and "" for the version.

These pieces of information will tell us for sure whether or not your system's graphics hardware's drivers are properly configured, and point us in the right direction. Lets first make sure that your graphics drivers are properly installed and we'll go from there.

Good luck!

Whoa nellie! It has never taken more than 2 weeks for me, usually somewhere between one and two weeks.

Well looking at your machine's specs it should be plenty capable of running PixelCNC. The OpenGL rendering function error is a red flag to me indicating that something specific to the Windows installation on your machine is not properly configured, or that some kind of software is interfering with normal program operation. The function the error mentions, 'glActiveTexture', is something that 20 year old graphics hardware supports, so it could very well be a driver issue with your system.

The problem with Windows complaining about not knowing how to open a common everyday program EXE file indicates that something has taken the liberty to interfere with your Windows installation. It could be a virus, antivirus, or some adware/malware that tried to work its way into your system, or possibly has worked its way in.

Since it looks like PixelCNC did eventually run, in spite of the "search for an app" problem, and wasn't able to properly initialize OpenGL, I think there's a good chance you can at least get it running if you update your drivers. I suggest you visit the driver page for your machine and have it automatically detect which drivers to download. The important one you're going to want to get PixelCNC running will be a video/graphics driver. Your specific laptop model came in two flavors, apparently, one with Nvidia graphics and one with Intel HD graphics. Either one should be able to run PixelCNC.

The driver page should be able to automatically determine if you need the 32-bit or 64-bit version of the drivers, just click the "Detect Drivers" button:

It should show you a list of drivers specific to your laptop, and you could go ahead and download all of them and get your system properly setup, but if you want to just quickly skip to seeing if you can get it working then download only the graphics driver that it shows you, it will either say Intel HD, Intel GMA, or Nvidia, depending on the actual hardware you have. It will also likely say "graphics" somewhere in the name. Go ahead and download/install that, reboot, and try running PixelCNC again. You will probably encounter the same "search for an app" issue, but once you get through that PixelCNC should startup, if it managed to show you the glActiveTexture error before - which means PixelCNC did actually start at some point.

I did manage to find this, which might help you fix that problem with Windows, but it won't fix the OpenGL/graphics driver problem, which must be fixed in order for PixelCNC to use your graphics hardware for rendering.

Good luck!

Hi Macboy, thanks for taking an interest in PixelCNC. What kind of computer are you trying to run PixelCNC on ?

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

Thanks for the info. If parallels supports multithreaded applications I could likely just force it to run, or at least give an option to the user to 'force run' if they want to see if things will work anyway. I think I'll do that. It sounds like it's just the implementation of the windows API for checking how many logical cores a machine has is not reflecting the actual machine itself - but surely multithreaded programs are properly utilizing multiple cores on there (Parallels). Also, I suggest moving to v1.18a, otherwise the new big v1.20a update that's in the works will include a better simulation system, tool diagrams depicting the profile of the cutter specified via parameters, and a few other tidbits.

Thanks for checking out PixelCNC! ..and yes, please share your PixelCNC creations :)

(2 edits)
A coarse horizontal milling operation and fine step parallel finishing operation.

(Note: If images are hard to see right-click and open in a new tab for full-resolution)

Intro: This tutorial demonstrates how to go about creating a work with sizable pockets that demand the removal of a relatively significant amount of material. This can be achieved using a single parallel operation with a workable depth of cut that results in multiple passes until a max depth is eventually reached at the bottom of the project - which is determined by it's Z dimension. In this case we're going to employ a larger cutter that can remove material more efficiently and in less time and then come in with a smaller tool to remove the remainder to produce the final product. Just about any operation can be used to perform the rough cut but we're going to use the 'horizontal milling' operation. This operation will remove material with horizontal cuts at fixed cut depths. Afterwards we will come in with a smaller ball nose cutter to remove the remaining material and bring out our desired form and detail in our workpiece.

Simulation Setup: For this project we're going to want to see a fast approximation of what our generated toolpaths are going to cut like, so start out by changing the simulation settings to a depthmap resolution of [1024] and mesh quality of [.90]. You can use larger values if you wish but these values will keep the generation time down in exchange for faster simulated cut preview generation. 

Simulation settings for fast and reasonable quality cut previews.

Project Setup: With a new project at the ready (File->New Project) click the 'Load Image' button and open 'pandemonium.jpg' from the included 'examples' folder in your PixelCNC folder. The image should load and generate a mesh in the 3D view. Click the 'Image Size/Origin' button to reveal the project's current dimensions and origin parameters. Set the project size/origin settings to a width of [12] inches and a depth of [1] inch. The 'Autoscale Contrast' option should be enabled here to ensure that the darkest shade and lightest shade from the image are considered the very bottom and very top of our project, respectively, even if they're not absolute black and absolute white. Set a 'downscale' factor of [1] to use the full resolution of the image. Then we'll use the top center of the project as our machine origin so our offsets should be X-Offset:[50%] Y-Offset:[50%] Z-Offset:[100%]. Once your parameters match the screenshot below press the 'Apply' button and the mesh will adapt its dimensions and position accordingly.

Setting up our project dimensions and machine origin.

Cutting Tools: Next we're going to define our cutting tools. Click the wrench icon button to see the project's list of cutting tool definitions. For our horizontal roughing operation we're going to use a larger flat end mill. Click the first tool slot labeled [tool01]. The number in the brackets '01' is the tool index that the generated G-code will expect the physical tool to be in for CNC machines with automatic tool changing capability. For machines without automatic tool changing we will simply break up our operations into two G-code files at the end of this tutorial, one program for each tool.

Roughing Tool: In the tool definition parameters on the right side of the screen we can set the name of the tool to something more descriptive for readability purposes. I'll be changing it to [1/4" endmill]. Click the 'Type' button to select the [Cylinder] option. This will reveal the tool parameters necessary for defining a cylindrical cutting tool. For this tutorial we'll pretend that our tool has a length of 1.5" from the chuck to tip and as such set 'Total Length' to [1.5]. This is to keep the spindle chuck from crashing into the highest parts of our workpiece when cutting the deepest areas, at least with this project image. Our imaginary tool also has a flute length of [1] inches, a 'Flute Diameter' of [0.25], and since it's a flat endmill we'll set 'Corner Radius' to [0] inches. Now we hit 'Apply' to save these parameters to our tool.

Defining our 1/4" flat end mill for our horizontal roughing operation.

Finishing Tool: At this point we can either create our roughing operation first and then come back and define our second tool and its finishing operation, or we can go ahead and define our finishing tool right now while we're here. This is entirely up to the user and their own preference. For this tutorial we'll just go ahead and create our finishing tool right now while we're here. So, click the second tool slot labeled [tool02] and we'll name this one [1/8" ballnose]. It is also a [Cylinder] type, and we'll say it also has a total length of [1.5] inches, a flute length of [1] inches, a flute diameter of [0.125] inches, and a corner radius of [0.063] inches - which is equal to the radius of the tool (rounded to the nearest thousandth) in order to yield a hemispherically rounded ball-nose tool profile. Press 'Apply' to save our finishing tool's definition.

Defining our 1/8" ball-nosed endmill for our finishing operation.

Operations: Now that we have both of the tools we need for our project we can move on to creating both of our machining operations. Click the line graph icon button to bring up the project operations. Click the first operation slot in the list on the left side of the screen labeled [op01]. This will bring up the operation definition on the right side of the screen, just as with the tool definitions editing mode. For this tutorial we'll change the name of the operation to [horizontal roughing]. Click the 'Tool' button and select our [1/4" endmill] we defined from the list. Click the next button, labeled 'Op' and select [Horizontal]. This will reveal the relevant parameters for defining a horizontal milling operation. We'll set the cutting direction to [Climb], which will create toolpaths that engage the tool with the material so that the clockwise rotation will scoop the material in the opposite direction that the tool is moving. This helps to preserve tool life by causing less rubbing than conventional milling.

Speeds & Feeds: For cutting 'speeds & feeds' you can use a special calculator to calculate these based on the capabilities of your machine. For those more experienced with CNC they will likely have evolved a sense of what speeds and feeds to use based on the material they're cutting, size of their cutter, number of flutes, depth of the cut, and capabilities of the machine they're working with. We'll assume that all the variables in play work out to a cutting feed rate of [60] inches per minute, and a tool rotation speed of [10000] rotations per minute. For a 2-flute cutter this comes out to a chip load of .012" being removed per tool revolution, which is perfectly acceptable for a 1/4" tool cutting most woods. If you have a hobby desktop machine with a router spindle such as the DeWalt DWP611, the minimum RPM is 16000 on the lowest dial speed setting. We can just scale up our feed rate accordingly. Our new feed rate for 16000 RPM is: 60IPM x 16000RPM / 10000RPM = 96IPM

Step & Depth: Since this is our roughing operation we want to save time by moving a lot of material, fast, so we're going to set our 'Step Size' to just over half the diameter of our 1/4" cutter, and use [0.15] inches. We're going to cut the diameter of our cutter deep and use a 'Cut Depth' of [0.25] inches. The operation should be allowed to go as deep as our project image goes - the full 1.0" of our project's Z depth, so we set our 'Max Depth' to [1] inches. 'Min Depth' sets the high cutoff point where any cuts shallower than this depth are culled. For this tutorial we'll set it to [0.001] inches. Both the min/max depth values are relative to the top of the project, not absolute Z coordinate relative to the machine origin.

Safe Z: As long as our raw stock material is sufficiently flat we can allow our tool to move between cuts relatively low to the top surface. This minimizes total operation run time by reducing the amount of time that's spent traveling vertically when retracting from a completed cut and feeding into a new one. I almost always keep the 'Safe Z Height' at [0.1] inches unless I absolutely need to optimize for speed, at which point I'll get as low as ~0.025" but this is only in extremely specific situations. Once we have our horizontal roughing operation specified we can generate our toolpath by hitting 'Apply', just as we do with defining a tool.

Our horizontal roughing operation's toolpath for economical removal of material.

Adjustments: The horizontal operation is one of the slowest operations to generate a toolpath for and this is determined entirely by the depth of cut and step size. We can't really rely on having a larger step size to reduce the number of cut paths without causing some lone island spikes to form in tight corner features, which may or may not pose a problem, depending on the project. We can more realistically fiddle with the cut depth, however, but this depends on the machine and the material being cut. A less rigid machine might flex too much or not have a powerful enough spindle to handle to deep of a cut. These parameters should be tweaked to suit the machine that the code will be run on. Here's an example of changing the cut step size to [0.2] inches and the cut depth to [0.3] inches, you can see the reduced calculation time:

Observing the calculation speedup of using larger step size and cut depth.

...However, this leaves more material for the finishing operation to come in and remove, which may or may not prove problematic, depending on the tool used. If a finishing cutter does not have long enough flutes it may not be able to cut high enough when at the bottom of a pocket to remove the larger remaining stock, or it may just as well overwhelm the machine depending on its rigidity and robustness.

View Repositioning: Once we have a decent looking toolpath we can examine it visually by rotating the view around by click-dragging the left/right mouse buttons and spinning the mouse wheel to zoom in/out or click-dragging it to directly control the zoom. Pressing the home icon button on the view button bar top-center of the screen will return the view back to its default birds-eye vantage.

Taking a closer look at the toolpath generated.

Simulation: We can get an even better idea of the cuts our toolpath will create on a CNC using the simulation preview mode by clicking the film play button. This mode also shows a list of the project's operations which can be clicked on to generate a simulated toolpath cut for users to examine and get a much clearer idea of what their parameters are going to physically produce:

Previewing the simulated cuts of our horizontal roughing operation toolpath

Finishing Operation: Once we're happy with our roughing operation we can go back into our operations mode via the line graph icon button and select the second blank operation slot. Here we can name the operation [parallel finishing]. We'll select our [1/8" ballnose] as the tool used, [Parallel] for our 'Op', and [Mixed] for our cutting 'Dir' so that the tool will cut in both directions in a zig-zag fashion instead of lifting up and rapiding to the opposite side to continue cutting in a single direction.

Speeds and Feeds: With the speeds and feeds it gets a little trickier here than with horizontal cuts being that our tool is going to be taking vertical plunge cuts almost half of the entire time the tool is engaged with the material in order to perform the 3D contouring cuts involved. This means that the center of the tool will be doing quite a bit of cutting. The center of a rotating tool is a very tiny radius that will be rotating. As such the flutes will be moving at a very low speed relative to the cut feed rate and the flutes on the circumference. We'll compensate by using a lower feed rate to give the tool tip a better chance at removing material. For our 1/8" ballnose tool, which we'll imagine has 3 flutes, we'll use a feed rate of [20] IPM and a spindle speed of [10000] RPM. This gives us a chip load of 3(flutes) x 20IPM / 10000RPM = .006" inches per revolution. We could go slower, or turn up our RPM, and the center of the tool will do an even better job of actually cutting. In the case of woods and plastics this isn't as much of a concern as it is with machining metals, so we'll call it good.

Step Size: For a finishing pass we need a tiny step size that will minimize the size of the 'scallops' between each cut pass, the little peaks along the midpoint between each cut path. For this tutorial we'll use just a little under 1/4 the diameter of our finishing tool, and set 'Step Size' to [0.03] inches. We want the tool to be able to travel from the top of the project workpiece to the bottom in one fluid cut so 'Cut Depth' should be the full Z depth of the project which also requires that our tool's flute length is at least this large so we'll set it to [1] inches (this is to prevent an operation from potentially cutting deeper than the tool is capable of but this will be changed in the future).

Confinement: 'Max Depth' obviously should be the full project depth, [1] inches, and we can re-use a 'Min Depth' of [0.001] inches which will leave the very top most surface of the project untouched on the left/right sides bordering the project. We could reduce 'Safe Z Height' but we'll keep that at [0.1] as well. For fun you can play with the 'Angle' value and modify the direction of the cuts, but for this tutorial we'll leave it at [0] degrees. Click 'Apply' and the toolpath will generate and it should complete a bit quicker than the horizontal roughing operation we created due to the simpler nature of the toolpath.

A freshly generated parallel finishing toolpath, and parameters

Once we have a toolpath we can examine it more closely by moving the view around.

Taking a closer look at the toolpaths for our finishing operation.

..and again we can go into simulation preview and click our [parallel finishing] operation to generate a preview that is the culmination of both the roughing pass and finishing pass. Granted in this situation the parallel finishing operation will look identical whether or not the horizontal pass is present but in reality, on a machine, the tool or machine might not be so cooperative removing all that material with the tool making so much vertical plunge cut motions through so much material.

A simulated cut from our parallel finishing toolpath.

Toolpaths can be hidden by clicking the visibility eye icon button on the top center button bar to toggle drawing of any toolpaths, this especially helps with viewing simulations where dense toolpaths are in play:

Revealing the simulated cut by toggling off drawing of toolpaths.

Exporting Separate CNC Programs:

If we go back into operation editing mode by clicking the line graph icon button we have a few buttons for each individual operation. There's four buttons that appear on an operation in the operations list when they are selected for editing.

The eye icon toggles visibility of that operation's toolpath, and only applies if the global toolpath visibility toggle isn't already hiding rendering of all toolpaths The pencil icon toggles whether or not the G-code for the operation will be included in exported G-code as well as a generated simulation preview. The up/down arrows allow re-arranging of the order that operations are in.

If we want to export each operation separately we can start by clicking the pencil icon on our parallel finishing operation to prevent it from being included when we export G-code. Now we can export our roughing pass G-code by clicking the 'File' menu and clicking 'Export G-Code'. A file save dialog lets you navigate where you wish to save your CNC program code, with a name like "".

Toggling off writing of finishing operation's toolpath to exported G-code for a roughing program.

Now we can disable writing of our horizontal roughing operation to G-code and re-enable writing of G-code on our parallel finishing operation and repeat the G-code export steps, being sure to save to a different file name, such as "".

Toggling off roughing operation's inclusion to exported G-code for a finishing pass program.

The End :)

Fantastic, what a relief! I'm going to post a tutorial in the morning, I have some tutorial ideas sketched out for mostly just demonstrating the basics of using individual operations and then also a few things that employ a few operations used in combination. I'm all ears to suggestions if you are curious how to go about doing anything in particular.

Thanks Donnie. I made a new build that uses some different compiling options and a sort of in-between version of SDL that still has SVG loading capability as a sort of last resort before I pull out the big guns. I was hoping you could check it out, it's labeled v1.16a on the downloads section. I'm still not entirely sure what's going on here, other than it sounds like something is severely slowing everything down and not giving very much CPU to the main PixelCNC thread that's running, which is very strange.

Was the toolpath that slowed down rendering very complex? Or was it pretty simple? Did toolpaths of equal complexity cause a slowdown in previous versions? The toolpath visibility button sticking is also extremely strange, as it's constantly refreshing the cursor position (from SDL, so maybe that's the culprit) and doing a simple check to see whether or not the cursor is over each rectangle for each button/editbox/checkbox/menu item on the screen, where it hilights green if it is and otherwise defaults. That information isn't even stored in memory, it's re-generated each frame, so I'm at a bit of a loss other than it being SDL, which could be remedied by completely removing it from PixelCNC entirely and just going with the raw method. I haven't seen problems like this with SDL in the past, but that was also before SDL was as big and complex as it is now, so maybe the devs have become somewhat overburdened with keeping compatibility and reliability up to snuff.

Another thing I'm looking at right now is some better debugging systems I can build into PixelCNC to make it easier to track down and determine issues on end-users' machines without requiring them to get their hands dirty, we'll see what comes of that. Anyway, let me know how v1.16a works out when you get a chance, and thanks for taking the time helping me to figure these issues out.

Actually, if you find that the old DLLs fix all the performance problems then I'll probably just revert back to using those and get SVG support in there another way, which is somewhat roundabout, but it would save a lot of extra work that would otherwise not really be necessary.

I've got some ideas for some sweeping changes that will be made if you observe that replacing the v1.15a DLLs with the v1.14a ones resolves the slowness issues. Some other people are having serious problems with v1.15a as well: crashing when loading images, etc.. Going through the code with a fine-toothed-comb comparing everything I changed between v1.14a and v1.15a I just don't see anything that would cause the severe slowdown that you're seeing, nothing was changed that I would imagine would affect it like you're seeing - except for updating the SDL DLL files to the latest versions.

It's still spawning the same number of threads for doing background work and allocating even less memory than before - but we're seeing the slowdown globally affecting everything. What should take a fraction of a millisecond is taking multiple milliseconds, which is pretty crazy. I can only imagine it has something to do with the SDL DLLs and how they're spawning the window. I'm thinking I'm just going to strip all those dependencies out and hand-write the Win32 code to do everything super raw, and then use an alternative image loading library that some people I know are suggesting. It's a bunch of work I wasn't planning on doing, but at least it would eliminate the black boxes.

SVG support is the ability to import SVG image files.

Okay, now one thing I want to try is running the v1.15a exe with the v1.14a DLL files. Just unzip the v1.15a into a new folder and then copy all the files ending in .DLL from v1.14a to the v1.15a folder, and then run that. Testing that on my system doesn't cause any problems, but it will disable SVG support.

(1 edit)

Hi Bill, 

You could create a tool that you want to use for cutting it out and then use an outline with the cut depth set to the bottom of the project, so that it cuts all the way down. If you think that your tool shouldn't be cutting through too much material you could do it incrementally with a lesser cut depth, just make sure your max depth is large enough to reach the bottom of your material.

So, if you have a .125" end mill, for instance, you could create an outline operation that has the cutoff level set really low to where the outline is delineated (where the background color is separate from the rest of the logo) and then set a negative step size offset that's the radius of the tool, so .0625, so that it follows the outside of the logo on the darker side of the division around the cut off level. A positive step offset will shift the toolpath into the lighter area by the specified distance.

Hi Donnie,

The log file looks pretty normal except that everything looks like it took quite a long time, even just starting up, and that doesn't involve a whole lot other than loading some images for the fonts and allocating some memory, which should be rather instantaneous. It almost seems like Windows was not happy at all. I mean, REALLY unhappy, and this wasn't the case with v1.14a? I'm going to put v1.14a up as a complete self-contained zip (instead of an update to v1.13a) which I'm assuming you didn't have problems with, and I want you to test that just so we can make sure it's specific to v1.15a.

Just off the top of my head, do you restart your computer often or just let it sleep when you're not using it (and it hasn't been fully rebooted in a while)? I almost never reboot my machines, unless it starts causing problems (which it does) and I've seen it cause problems like this before once in a blue moon. If you don't usually reboot your machine regularly could I suggest trying that? The log is showing that the simplest actions are taking an unusually extreme amount of time to complete, which has me leaning more toward it being a system-related issue. Perhaps there's some kind of software that is running in the background hogging resources, or Windows is just clogged up from being up for too long without a reboot? I'm somewhat at a loss here. I feel like I've seen something like this before, and it was a cache-related issue but it involved there being many calculations per program frame. In this instance PixelCNC isn't even doing anything and it's going really slow.

The only other thing I can think is that the SDL dll files PixelCNC v1.15a is using are different, which are used for support functions, like loading images and dealing with creating a window and gathering user input. If v1.14a runs fine but v1.15a does not then I think it's safe to say that they are the problem, which leaves my hands somewhat tied if I want to keep SVG support the way it is right now. I could likely find a different route, but ideally SDL would just work the way it's meant to across all Windows systems.

I can only suggest doing a reboot and then running PixelCNC, because I don't see any problems on any of my machines, and I'm running Windows 7, 8.1, and 10 across 5 different machines that don't exhibit the symptoms you're experiencing. I am almost thinking it's something like a program updating itself, maybe even Windows itself, unless it's the SDL dlls. If you're running an antivirus you could try temporarily disabling that and running v1.15a too I suppose.

What are your system specs? CPU, memory, graphics card/GPU, Windows version? This information may help lead us get to the solution.

Go ahead and download v1.14a and unzip that to a separate folder, and see if that still runs fine for you. If it does, try v1.15a again. The goal is to determine if it's a system thing or unique to something that has changed between v1.14a and v1.15a.

I decided to just remove the update and just go back to uploading the complete versions themselves. All of this will be a thing of the past once I move to beta version and incorporate an auto-update system in there.  Also, the update didn't include a new font image file for a new icon. If you see a printer button on the top bar then I suggest downloading the new complete v1.15a zip and extracting the icons_big.png from it to replace the existing one in your fonts folder. It's a button for enabling/disabling depth-testing on the toolpath render, so that you can toggle whether or not they are occluded by the depthmap mesh itself.

Yes, eventually I will have some videos up. I'm currently working on a promotional video just to demonstrate what PixelCNC is, for promotional purposes. I have been collecting some raw material to use to create example/tutorial videos and be able to show them actually cutting on the CNC, and what the final result is like. I might plan out the video tutorials by posting text versions on this messageboard first, because that would be a valuable resource for users as well.


(2 edits)

It is an update that you install over the v1.13a files (which may have been updated to v1.14a, but that's not required). Testing it on my end works fine. You need all the files that are in the update, not just the EXE, and they all need to overwrite existing files. Maybe I'll switch back to just having the full version downloads, I just didn't like requiring people to re-download files that largely remained the same (example files, font files, etc). This version the DLL files changed because of the SVG support that was added.

Hi Bill, I was just tweaking some little things with it before I put it out. I'll get it out here in about an hour or two. Apologies for the delay! Thanks.

By the way, setup both of your tools and operations in one project and if you want to export separate G-code files for each operation (i.e. if you need to do a manual tool change) you can set which operations to include/exclude in the outputted CNC program by clicking the little pencil icon in the operations list next to each operation (when in 'operations' mode). This toggles whether or not the operation will be included when G-code is exported. This is useful for smaller CNC machines that don't have automatic tool changing capabilities.

Hi Bill,

For roughing you could setup a horizontal operation with a step size of half the tool diameter, a cut depth from 1x tool diameter to about 2x diameter, depending on the actual flute length and the tool size/project size. The horizontal operation in the current public release is a bit temperamental, and has issues with smaller cut depths. I'll be releasing v1.15a sometime this next week which has a lot of the problems with the horizontal operation resolved. So far it's still not quite 100%, but it's pretty close, maybe 98-99% reliable, while previous versions are more like 75-80%. In the 1% case where it does break, it at least won't crash the whole program anymore, so that's good. If you do encounter a problem with the horizontal operation usually tweaking your step size and cut depth values, by a small amount like .05", can make all the difference.

Otherwise, you could setup a parallel operation and set the step size to ~75% of the tool diameter, and the cut depth to the same you'd use on the horizontal operation. Be sure to use the 'mixed' cutting direction, so that you're not spending time moving the tool back to one side of the project. That way it will just zig-zag back and forth across the whole thing in one long cut. The conventional/climb options are there for finishing passes, really, as they can really make a difference in the cut quality in most cases.

For a finishing pass most of the other operations will work, just set your cut depth to the same as the tool flute length. If your tool doesn't actually have a flute length as deep as your project's Z size just pretend and that will let you setup one of the 3D contouring operations (i.e. parallel/spiral/chevron/labyrinth) with a deep cut depth so the tool will be able to reach the bottom of the project without having to make successive passes of flute length depth.

If you don't know already, be sure to use good speeds and feeds that won't cook the material or wear out or break your cutters, there are online calculators that can help with that. I'm thinking about integrating an 'auto speed/feed' button to operations which will look at tool flute count and everything else.

Once PixelCNC no longer has new features being added and it leaves alpha to enter beta I will get a step-by-step how-to guide going, as the existing guide is more of a reference that just documents the interface. If I took the time to write one now, with PixelCNC still evolving somewhat, I'd have the extra work of updating and revising it. There's already plenty of work to do just on the software side, especially now that PixelCNC is available to paying customers. I'm going to spare myself the added work just for the duration that PixelCNC is in alpha. Once we're in beta all that's really left are bugfixes and minor changes, so I'll be able to focus more on marketing, promotion, and all the peripheral stuff like tutorials and demonstration videos.

(1 edit)

Good idea. I've been thinking about how to have a public roadmap that indicates all the major features that are planned and some smaller stuff that needs to be done along the way. For a public feature request this will work fine.

With cropping images I have half of a system setup for specifying project stock material size/shape, allowing users to set either a rectangular or circular/round stock which toolpaths will be confined to. After getting everything in there on the UI side, and rendering the user's stock material as specified, I ran into a problem integrating it with the toolpath generation itself and decided that solving it was going to delay the public release further than I was willing to bear at the time, so I temporarily removed the existing code until I can determine the best strategy. User stock material specification is more in line with conventional CAM packages out there and will serve the purpose of a cropping tool, as well as being able to eliminate toolpaths from generating in project image corners if the user is going to cut a round piece, which is the original reason that I personally wanted to add the feature.

I do need more little things like the max Z depth thing to be found. I know the current UI is riddled with them. These are the little things I easily overlook while focused on other things. Having more sets of eyes on the lookout for these will get them solved much quicker than seeking them all out myself. Keep your eyes peeled for more stuff like this!


Thanks for the heads up. If the FAQ otherwise indicated a payout ETA of about week I wouldn't have given it a second thought. Believe you me I can appreciate how easily documentation grows stale and how difficult it becomes to maintain documentation when working to fix bugs and implement new features. No biggie :)

Patience, engage!

Oh okay, that was pretty much as I expected. Thanks!

(1 edit)

I don't mind the wait if this is typical, but on the FAQ it says 2-3 days and I haven't received a response from over the past day either.

Hey Donnie, sorry about that. I replied to your thread over there. Thanks!