dashwood.net -

Ryan Stefan's Micro Blog

4 Sticks of Ram = BSOD: Simple Solution

Jan 042019

I have this recurring issue where when I build a new computer I always cheap out and buy less RAM than I ultimately want to have and end up upgrading later. From this pattern I have been cursed with BSOD problems for the better part of my lifetime. I've blamed it on motherboards and I've blamed it on mixing different manufacturers, but computer issues are typically pretty hard to pin down. 

I did the same thing while building my latest computer, I bought 16GB of ram and then upgraded an additional 16GB of the same brand. However, at first I was running Linux as my primary OS. I did have some freezing when I loaded windows in a virtual box, but for the most part I was pretty much stable. 

Recently I switched back to Windows because I found out about WSL (which is great), but unfortunately I was once again plagued by blue screens. This time I went to war. I tested each stick and each slot and had zero errors, but when I had all four sticks in I would get issues. So I started playing with timings. Apparently you can set "loose" timings that give more slack, but that didn't work. So all of my slots worked, every stick of RAM worked, I had the latest bios, the latest OS, and I'm looking around on the internet running around in circles. That's when it occurred to me that every time I've had these issues is when I had four sticks of ram in my computer. I assumed that my motherboard would route the power needed to my RAM as it's needed, but apparently they are set up to use the bare minimum and when I had four sticks in the power need of my RAM would dip slightly above what it was allocated. 

Tl;dr stock bios DRAM voltage (CH A/B) settings are set up for two sticks of RAM, not four. 

All I had to do was increase the voltage by .15 (from 1.2 to 1.35) and everything works perfect. 

Flashforge Creator 3D Printing and Windows WSL Subsystem

Dec 212018

I have a Flashforge creator and was using replicator software that is essentially a crude wrapper for the GPX conversion script. I thought there had to be a better way to print despite it being an offbrand 3D printer. First I tried the proprietary software, but it only lets you print directly to the printer and does not convert STL to a file. Then I downloaded makerbot software, similar story. I then noticed there were several references to a DrLex thingaverse post that had fully customized settings for an open source 3D printing software called Slic3r

Slic3r with Flashforge Creator

Getting Slic3r to work with DrLex's settings is a little tricky and took me several attempts to figure it out. First of all, after you "file->load config bundle" you have to check the "Generate support material" box for them to show up. 


After that you're ready to start exporting to G-code, but the software does not export to x3g format by default. For that you have to connect it to an external script that DrLex provides in his post. This is the tricky part and is different depending on your operating system. If you're on a Windows OS other than Windows 10, then you will have to convert the G-code by dragging the file over the GPX win 32/64 .exe file (different from linux and osx). Note that if you convert the G-code manually without using DrLex's script you'll need to change the extruder manually by clicking the STL object in the slic3r plater tab 3d view and once you click and set the object as your active selection go in "object->settings" to change the extruder. The right nozzle is ‘extruder 1’ and is the default; the left one is ‘2’.


Automatic X3G Linux

If you're on Linux then getting the auto compiler to work is a lot easier. There are a few pit falls that I fell in that were very frustrating, but once I figured them out it was pretty straight forward. First of all, you have to actually install GPX. For linux all you have to do is open terminal and enter:

sudo apt-get install gpx

Now the DrLex "make_fcp_x3g" bash script will be able to run GPX on your G-code, but you have to make a few changes first. First you'll need to set the GPX path in the script, so go ahead and open it up in a text editor like Sublime Text. Where it says "GPX=/usr/local/bin/gpx" you'll need to change this to your GPX path. You can find that by opening a terminal and typing:

which gpx

That's it, your "make_fcp_x3g" script should be set up. You'll need to put it in a directory that has no spaces in it. Personally, I put it in my home directory where my 3d files are stored so I don't have to set chmod +x on it, but you can put it wherever. It took me a while to figure out that having a space in the file path was breaking the script. It may be possible to get around this by putting it in quote, but I haven't tried it. Now you just have to tell slic3r to run this script after converting to G-code. Note that each filament type has completely different settings, so you'll need to set the script path for each one you use. So go to "settings->print settings->output options" and enter the file path e.g. "/home/ryan/Documents/3d/3dprinter/make_fcp_x3g" and thats it!


X3G Windows & Windows WSL

To run the make fcp bash script on Windows you'll need to have a subsystem of Linux called WSL. I havent actually gotten this far yet, but I'm actually super excited about WSL. I had to switch all of my desktop computers to Linux just so I can develop things in peace. Seriously, trying to code python scripts in Windows gives me the biggest headache and I just flat out refuse to do it. But if WSL works as well as I'm hoping it does, then I can finally switch my main computer to windows again and get back to playing with my VR headset! -- just in time for a Holiday break!!! Here are the links you'll need to set up WSL and the bash script:




Ubuntu 18.04: https://aka.ms/wsl-ubuntu-1804



Python on Windows — It's Been a While

Dec 182018

So both of my desktop computers at home are on Linux despite the fact that I have an HTC Vive beckoning me to dual boot Windows and play some Pavlov VR. It's a long story as to why I'm not using my VR headset, but to summarize my computer is running a script and I don't want to lose progress. 

However, even when I did have it on Windows about 6 months ago, I still wasn't developing on it. I just loaded Linux in a virtual machine and did all of my coding inside of it. It took me many months to get my Linux environment for coding just how I wanted it and I really didn't feel like dealing with messy windows when I could have a nice clean pipenv with pip lock files. Once you get Linux set up just right it makes Windows look like a living nightmare. Or at least... it did. 

Well, my job built me this really nice Windows machine and I decided to get python tuned just right so that I can run scripts on the fly without having to load a virtual environment. Turns out there are some emerging tools or at least tools that I did not know about that are very easy to use similar to Linux pipenv. I just stumbled upon virtualenvwrapper-win which lets you create a virtualenv directory and then you can move to whatever directory you want and set it as the root working directory. Then you have some nice bashrc-esk aliases for setting the directory, activating, and deactivating your venv.  Here are the things you need to know:

pip install virtualenv
pip install virtualenvwrapper-win
mkvirtualenv HelloWold #or whatever you want to name it
setprojectdir #sets current dir as working dir
workon HelloWold #similar to pipenv shell or source /bin/activate

Easy peasy right?