Jason K. Firth, C.E.T.

Instrumentation, Control, and Automation

An Uber fatality and the limitations of automation -- and the amazing powers of your human operators

Mar 222018

I'm Jason Firth.

Recently, there was a fatality in the news, as an Uber automated vehicle hit a pedestrian who was crossing the road.

The circumstances seem to be that the pedestrian carrying a bike crossed the road without seeing the car, and the car basically drove right into the young woman.

A lot of people seemed shocked that the car didn't recognise the young woman was there, and didn't immediately brake or swerve. One person invoked "fail safety", the idea that equipment should always default to the safest state.

This case is, in my estimation, more complicated than you'd think. It's true you want things to fail safe, but it isn't always clear what a fail safe state is.

I'll give you an example.

In a commonly told but apocryphal story, boiler maintenance was being done at the paper mill in Fort Frances Ontario Canada. (You've heard this story from me before) The design of a boiler (at least a recovery boiler like this) is you have tubes filled with water and steam surrounding a combustion chamber. Usually, you'll have a drum called the mud drum that contains a certain level of water. If that level is too low, that's normally considered an emergency situation. In this case, the maintenance they were doing required the mud drum to be empty, and they were still firing the boiler.

The story goes, a new operator came on shift and saw the mud drum was empty and immediately panicked. The operator immediately opened the water valves wide open (what would normally be considered 'fail safe'), and the boiler immediately exploded.

Why did that happen? What happened is the boiler tubes were red hot and virtually unpressurised. When cold water hit the tubes, the water immediately caused an explosive release of steam which caused an explosion. While the involvement of a person is unusual, boilers routinely experience explosions due to water valves having problems like this. If the boiler was running under normal conditions, perhaps dumping water into the tubes would be a safe option -- cooling everything and getting everything to a zero energy state faster.

So despite the valve opening being what you'd normally consider a 'fail safe' state, in this case it was a dangerous action to take.

Let's assume for a moment that both the car and the driver had perfect vision in that moment, and saw the pedestrian long before the moment of impact.

What is the safest action to take if you see someone crossing the street? Everyone here is immediately saying "obviously slam the brakes and swerve!", but let's think about that for a second. Most people are not going to walk directly into the path of an oncoming vehicle. Even if crossing, you'd expect a person to stop, so you can't necessarily use the fact that there's a person there to predict what's going to happen. By contrast, what happens if you slam the brakes and swerve every time you see someone crossing the street a little too close? If there's a car near you, it could cause an accident. If the person was going to stop, then that person could end up getting hit by your actions where they might not otherwise. The driver or passengers in the car might be injured -- probably for nothing, because 99 times out of 100, the person will stop before the car hits them. Often, the safest act is to do nothing.

Here's where there is a divergence between the powers of an AI, and the powers of a human. An AI sees object 15 -- perhaps even a human on bike type object -- travelling at a certain speed at a certain vector. It has to figure out what it can from relatively limited information. By contrast, a human sees a sketchy looking lady walking in a strange way not paying attention. The AI might not recognise there's a threat, whereas the human might recognise something isn't right and take the opportunity to take some of those more aggressive defensive manoeuvres for this isolated case. It isn't just object types and vectors, it's a vivid world of information and context.

Our powers of intuition, empathy, and deduction are much more than we give ourselves credit for. We know more than any purpose built AI, and can make connections that no purpose built AI presently can. Humans aren't perfect, but there's reasons why we still have humans involved with even the most high tech processes.

It's ironic to say this as an automation guy, but the world is about to realize the limitations of automation, as it comes closer and closer to our personal lives.

As interesting as this story is on it's own, I feel it's also interesting to show the limitations of raw automation in the industrial context as well. Sometimes, operations asks for a system that reacts to something the human knows but the machine does not. If you're not careful, you cause false positives and react dramatically to situations that don't exist based on assumptions, causing more problems than you'd prevent.

One I saw for a while was an operator pointing to a spike on a graph and going "That's because of [event], we need to prevent that." Then you'd go down the graph and find another spike and go "Is this [event]?", they'd say "no". You'd go down a little further and say "how about this? Is this [event]?", and they'd say "no". It turns out that the reason the operator knows what's going on is that the operator is a human with eyes and ears and an incredibly versatile mind that can understand things far beyond a series of numbers plotted along a graph. Short of dramatic changes to the process, the PLC can't know that [event] has occurred with any sort of certainty.

Thanks for reading!


Microsoft is lazy in a bad way.

Mar 052018

I'm Jason Firth.


I caught a video about Microsoft Edge today that got me thinking about something.


I find their attitude towards Edge and Windows 10 to be terribly lazy.


Let's look at some of the basic changes over Windows 7.

There's a new feature, the PC Settings app. Let's try to change the IP address:


To change the IP address, you have to open a win32 program. Oops!

To manage the SSID, you have to open a win32 program.

The settings app has many examples like this, where the new OS features are half-baked. If you want to make a change, it's time to hit the roulette wheel: Which program do you use to change this setting -- the original win32 program, or the new metro app?

Assuming, of course that the Metro app decides to work. The reliability of that framework is suspect. I routinely open the calculator to watch a screen with a calculator icon glaring back at me. When I have to head back to the original win32 versions of programs to do simple things like look at a picture or add 1+1, that's a fundamental breakdown, and Microsoft should be considering any instance of that to be an all-hands-on-deck situation.

That brings us to Edge.

In my experience, Edge just doesn't work very well, even (as seems to be a developing tradition), with other Microsoft products. I can't use it at work, because it doesn't function properly with Sharepoint. My only option is Internet Explorer. (Chrome and Firefox don't work with Sharepoint either, presumably because of the same problems that keep Edge from working). That essentially makes Edge useless for Enterprise, if it doesn't work with Sharepoint. That's lazy of Microsoft to create a new browser and ignore essential functionality for their core users.

Lazy can be good. Lazy can mean you reduce the complexity of tasks. Lazy can mean you make things easier, or that you do things in a less risky manner. In this case, lazy is bad. By half-assing the OS and the browser, you end up with programs that fundamentally can't complete the tasks they're supposed to do.

Edge currently has 1/4 of the users Internet Explorer has. Some of this is because Edge is only for Windows 10, but much of it is likely because Edge can't even do the things Internet Explorer does. Furthermore, Windows 10 has had much slower adoption than Windows 7. By this point after Windows 7 was released, it had a commanding lead over XP. By contrast, Windows 7 and Windows 10 are neck and neck. I believe the biggest reason for this is Microsoft's lazy behaviour. Windows 7 behaves like a cohesive product. Windows 10 feels like two completely different products have been inexpertly melted together with a heat gun. Unlike Windows 8 it doesn't scream in your face with its incompetence (The windows 8 start menu really is an excellent example of how not to do navigation), but that doesn't mean Windows 10 and it's associated products aren't still broken.

Sales of Desktop PCs have dropped below 100 Million for the first time in a long time. Some of that is just because laptops are so good these days. (I've been using laptops exclusively for years because I travel so much for work. I'm writing this on an Alienware R15) However, I strongly believe another reason is that Windows 10 is a poor OS, and people are choosing not to upgrade their PCs, lest they have to give up their Windows 7.

In other works, Microsoft has the ability to reverse the course of the industry. Come up with a polished OS that actually works in a straightforward manner, and I believe there will be an immediate boost to PCs.

Ironically, some of the changes have been made so Microsoft can emulate tablets and phones in form, but in doing so they've moved PCs away from them in terms of function: I can configure my android device from the settings app. I'm sure I could do the same on an iOS device. I can't do it from Windows 10. I can only imagine the nightmare that using a Windows 10 tablet or phone would be, based on my Windows 10 experience. It is completely understandable that because of their lazy choices, instead of Windows 10 being an advertisement for Microsoft's phone and tablet products, it is a case against them.

To move forward, Microsoft needs to stop adding new features and chasing the latest craze. They need to take a step back and put the work into building this platform.

It's simple, but not easy:

  1. Create a team consisting of one person with the authority to make decisions from each software team involved, a few UI designers, and a number of laymen who use Microsoft applications daily. For the laymen, reach out to customers, even! Corporate, personal, industrial, front-line users, IT users, software developers. You need their input. That input would have saved you from Windows 10.
  2. Come up with a list of every basic task users do in Windows. I bet it'll be a list of the top 1000 tasks between users and power users/sysadmins. Come up with a list of the top 100 tasks people do in each major piece of software such as Edge.
  3. You'll have a huge list, prioritize them. Personally, I'd focus on tasks that are done routinely, and tasks that are going to be major "pain points", such as configuring network interfaces. Spend the most time and make sure there's cross team interaction on the top priority items.
  4. Using the list as a template, enumerate the steps required to do each of these top tasks. Actually do the tasks to prove it.
  5. Ask yourself: "Is this really a reasonably easy way to do this? How would someone know how to do this besides Googling it?" (Being real here, Bing is garbage and you need to fix that too. Google "Windows XP Service Pack 3", then bing it. What are the top 3 links for each? Clearly, you've got problems. One disaster at a time, though) Honestly, if you look at the list of steps required for a lot of relatively basic tasks, there's absolutely no way you'd know how to do it. "Go 'run', then type 'horrentouslylong -cmdline', and choose the fourth tab and press the plus and type "arbitraryChars (seriously)". This is all garbage, and needs to be streamlined.
  6. Look for obvious stupid things. Going online to solve problems with my Internet connection just makes you guys look completely clueless. Keep the updated database of methods to solve problems with Internet connections locally! (That's just one example, mind you)
  7. Run user tests on users own hardware. Get random users to do the top tasks. I bet you'd be surprised to discover a lot of them don't actually work! At work, I often use the win32 image previewer because the Metro app doesn't work! I've erased purchased, licensed copies of windows 10 and replaced them with Linux because Windows suffers some of the worst bit rot since Windows ME, and the machine is locked solid from processes that "don't run while you're doing anything" but clearly do.
  8. Document the new methods to complete these key tasks.
  9. Ask the same questions about the new methods that you asked about the old ones.
  10. Fix the problems you find, make the changes you need to make. It's a short line, but most of the work.
  11. Have lay users test each solution to make sure it actually works and is actually intuitive! Don't use a strict test script, let users try to figure out how to do each task in their own way. In fact, if you can run a test by scenario instead of by task (for example, let IT folks set up a PC for use on their own network, or let a home user set up a PC for their own use)
  12. Use your documentation and the results of user testing to create user documentation for all these top tasks, and include the latest version of these documents offline.

Like I said, it wouldn't be easy, but in spite of the fact that the form may be different than a tablet or phone, the function would be the same: Finally, all the basic functions of Windows and its major applications would work in a fully functional and intuitive manner.

You want people to use your store? Your phone OS? Your tablets? You need to get your day 0 stuff sorted out. People need to be able to trust your software to be basically competent before they give you license to do more.

If I'm being honest (and I recognise this may be a controversial statement), Google does this very well. People trust their search engine because it does the basics well. Their mail does the basics very well. Youtube does the basics very well. Google maps do the basics very well. Android does the basics very well. Because they do the basics well, they are given license to do more. People are willing to let Google drive their car for them, because their software is generally competent, functional, and easy to use. Nobody is willing to let Microsoft drive their car for them (or their phone, or their tablet, or their search engine, or their web browser) because Microsoft isn't doing the basics well, and thus lacks license to try more. Microsoft wants to brag about the quality of their work, but their work doesn't speak for itself.

This can apply to control systems as well. If we don't do work that is generally competent, functional, and easy to use, then we won't get license to do more. Managers won't want to let us try things, front line workers won't be willing to let controllers stay in auto, and the money will go elsewhere, to other capital projects that perhaps do have histories of being those 3 things.

Thanks for reading!

You can't take the tradesman out of the...

Feb 022018

I'm Jason Firth.

Another quick post to share my latest improvement for my 3d printer (again). I wasn't very happy with how the cables hanging. In cabinets we often use sticky backs or slotted rail to clean up cables, I decided to use a similar approach on the printer. Here's the design you can use on tinkercad:



Let me know if you use it for your printer!


Thanks for reading!

Updated spool holder

Jan 312018

I'm Jason Firth.

Here's an updated spool holder. I took some ideas from Geoff King who printed up a modified version that fit with more spools. It bolts directly onto the screw holes for the original holder.





Thanks for reading!

Next step

Jan 282018

I'm Jason Firth.


I printed off a set of braces for the towers of my Delta printer, and after installing them, found that the printer was all of a sudden failing prints. The kapton tape on my bed was utterly destroyed twice in a row, and the print I was trying to do just didn't work.


My first instinct was to take a look at the home switches. They were wobbling around, so I figured part of the problem could be that my homes weren't consistent.

I swapped the square bolts that come with the FLSun printer with actual T-Bolts. I immediately realized there was a problem: The bolts were not holding the part in!


I discovered that the back of the switch had these ridges meant to hold them into the 2020 strut.


I realized the easy way to fix it was to cut away part of the ridge. I used a simple razor blade from Home depot:



Afterwards, the t-bolts I purchased fit properly:


The switches locked in solid after this.

problem: My prints were still failing!

So I looked further. Next up I realized a basic maintenance problem: My belts were very loose. It worked much better after that, didn't slam into the bed.

However, the print still failed, even though all these maintenance items were improved.

The final solution was to increase the layer height of my prints. I had it set to .06mm, but it appears that once I started tightening up everything, the printer simply isn't capable of printing such thin layers. Perhaps in its sloppiness it was just barely slopping its way into each of the next layers.

3d printers again...

Jan 162018

Yesterday, I had a revelation about my new printer. I was pretty happy with the prints I was getting (happy to be getting any prints at all, in fact) but the quality wasn't quite where I wanted it.


I ran a check of the extruder calibration and found it substantially out. I asked for 100mm, but got 57mm instead. 


I was already looking at calibrating the extruder, so I switched to the Marlin AC branch. That branch contains the latest developer patches.


Along the way, I had to move my config changes to the new firmware, so I had a deeper look. One change I made is to reduce the "slow" speed while calibrating. The stock settings shook the whole thing. I also increased the number of calibration points and changed the calibration routine to take each measurement 3 times.


One of the additions to the marlin-ac was automatic bed levelling. I assumed the auto calibration took care of levelling, but it seems that's a different feature.


Someone in the flsun Facebook page suggested that my "delta kossel" and the "mini kossel" I keep reading about might be the same printer. It does seem plausible on second thought. However, it means that the example config is just completely wrong.


The other thing is that the flsun YouTube page appears to call the delta kossel and mini kossel different things. It's difficult to figure out whether the two are the same or not.

This speaks to a fundamental of maintenance: defining your equipment. Giving it consistent naming, giving it a unique identifying number that functions within a system. For a company with perhaps 9 different products, this ought to be trivial. Perhaps a digit for product category (3d printers), one for product type (delta kossel), one for the subcategory (mini/standard/jumbo), a digit for model number, and a digit for revision number. "3ks1a" - easy. Then everyone can search for "3ks1a" and find Information directly relating to that printer.

In industrial automation, the ISA 5.1 standard defines similar naming. In industries around the world, this convention is used to name instruments in an immediately identifiable fashion.

Let's look at a typical designation:


The 66 part of the above is area number. Very few plants are monolithic. Most consist of a certain number of defined areas with defined functions. These areas often have a single number associated with them. If 66 were for a certain power boiler, for example, anyone in that plant would immediately recognise that the instrument existed in that power boiler.

The second part, "FIT" above, is a standardized designation based on the ISA 5.1 standard. In this case, the first letter tells us the process variable. In this case, "Flow". Other common process variables are Temperature, Pressure, Analytical, or Density. Each represented by the first letter of the word. The second letter above is "Indicating". It is a modifier telling us that the instrument has a display. Finally, the last letter is "Transmitter". This speaks to the function of the device. Often you'll see Switches, Valves, or Elements. Sometimes you'll see a Y, which indicates "special function relay"

Finally, the number "123" above represents the unique loop number. Every loop in the area will have a unique number, making it trivial to look for loop sheets, wires in a junction box, or PLC code.

In terms of the name you'd give it, I prefer following a few general rules.

1. Name for humans. This means naming things using natural language, and in a way that people can read. I've seen colons, dashes, And underscores in names. There's no need for that. I've also seen things named something nobody calls something. Either correct your name, or change what people call the thing.

2. Name precisely. Calling stuff pump #1 is tempting, but makes things too difficult when trying to refer to something. "Boiler #10 feed water pump #2" tells someone everything they need to know about that device. Calling the printer the "Delta Kossel" is too broad. Every printer of this type is a "Delta Kossel", and it appears the company has multiple kossel style printers.

3. Name consistently. Create a nomenclature or taxonomy and follow it. Don't refer to the same device with six different names. In this case, the "Delta Kossel" and "Mini Kossel" might be different things. If they are, that's fine. If they're not, that's a major failure of naming.


Anyway, I'm done playing with the printer until next weekend. Looking forward to the next steps. I'll keep everyone updated.


Thanks for reading!

3d printer, day 2.

Jan 132018

I'm Jason Firth.

I apologize in advance for the photos. No idea why they came out so bad.

Last time, I talked a bit about setting up my new 3d printer, an FLSUN Delta Kossel. The first day consisted of fighting with the firmware that was set up without any limits, and with some seriously wonky default settings.

I was able to complete my first 3d print, a ring from thingiverse, and then moved onto my second 3d print, a ball valve I designed:


Unfortunately, it didn't print very well, and after printing successfully once, I wasn't able to get it to print at all again.

I still had a few problems. The head wanted to dig into the bed. I tried to tape some magazine stock to the bed to protect the head and I tried to calibrate the bed that way, but that was a pretty poor solution. What I discovered is that there were a few problems with what I was trying.

The unit came with leveling springs, and the instructions on YouTube suggested I install them. This turned out to be a bad idea, because the nozzle contains a spring as well,and the two were fighting each other. I took out the spring, and because I'm concerned about the heated bed touching a bunch of plastic, I took one of the spare square bolts and used it as a spacer:


Next, I wasn't happy with the auto calibration. The entire unit shook dramatically as it auto calibrated because of the huge amount of force needed to overcome the spring. I looked at the head and realized I didn't have *one* adjustment, I had *two*. The silver set screw that set where the button releases, and the black set screw that set the spring tension:


I realized I'd have to calibrate the nozzle before I could run a printer calibration.

First, I loosened the silver screw until I heard the switch click, then I tightened it slowly until I heard it click again. I pressed the nozzle to prove the switch was actuating properly, because a couple times I just tightened it until I heard it click again but it didn't reset with nozzle movement.

Second, I loosened the black set screw until the switch opened, then tightened it back up until I heard the switch close again.

After calibrating the print head, I was getting much better calibrations that didn't shake the unit so badly.

Finally, to deal with the print head jamming itself into the print bed, I discovered a setting called Z-offset. I was able to change the z-offset from the unit faceplate.

First I went to the control menu:


Then the motion menu:


and Finally set the Z-offset:


I figured out the z-offset by setting my height (I used the faceplate in the prepare menu, but you could easily use Repetier to do it from your computer) lower and lower, until I couldn't slide a piece of paper under the nozzle anymore. I set the Z-offset to the number of mm.

The final improvement I made was to place a fan near the bed. The unit has a fan built onto the nozzle, but this didn't seem like a bad idea.

I was finally able to consistently make successful prints. Early on, I designed and built these clips so we can screw our undercabinet lighting to the cabinets:


And by the end of the day I had printed a spool holder I designed:


I was really happy how this one turned out. Not so happy about how the picture turned out, mind you. No promises how it will hold up once I place a 1kg spool on it instead of the smaller provided spool.

A few things I've discovered in a day of printing:

Don't waste time trying to save material. A 1kg spool of filament has about 330m of filament. All the designs I've been printing use less than 10m of filament.

You see a lot of prints that look like they're really substantial, but they might not be. The prints might be completely hollow inside. The above print has a 5% infill, so very little inside.

Shell thickness is your friend. I printed a tube with a 0.5mm shell thickness, and it was a great demo, but very quickly broke. I printed with 1mm shell thickness, and everything was much more substantial and is holding up much better. Given the choice between infill and shell thickness, I'll choose shell thickness every time.

I didn't need a raft or anything once I had the printer well calibrated. Suddenly the bottoms of my print were good by themselves.

Even though professional designers using molded plastic might use voids to conserve material, that seems to be a really bad idea here. I created an earlier spool holder that used a thick column with voids, and it was a really complicated print -- it was constantly retracting and spooling out and ended up being really messy.

Today's prints pushed the limits of a 40mm radius print bed, so I spent some time doing some tests. I figure I can safely print to 70mm without the print head or arms contacting anything, so I increased the print radius to 70mm in the marlin source code and re-uploaded.

I had a calibration error I couldn't figure out -- my Y axis was off, but only my Y axis. A post on the marlin forums suggested moving to the latest, so I moved to the nightly and re-uploaded. That worked perfectly. After upgrading, the printer calibrated happily and I'm ready for more printing tomorrow.

Because I don't want someone like me to have to deal with the annoyance that was my first day, I took the configuration headers and submitted them to the marlin project for entry into the examples file.

3d printing

Jan 092018

I'm Jason Firth.

This year I wanted to go on a bit of an adventure, so I got a couple of toys. One is the Oculus Rift VR system, the other is the FLSUN delta kossel 3d printer with a heated bed. I purchased both from Amazon Canada with Prime shipping.

The Oculus is more a consumer entertainment device, so let's talk about the 3d printer. It's a consumer device, but it's interesting enough on it's own.

I had never done anything with 3d printing before this weekend. It's been on my wish list for years, but I didn't feel I was quite ready until recently. This journey is still therefore fresh, I am not coming into this after I've learned everything there is to learn.

On Friday night, I got off the plane from work and found the printer box waiting for me. I couldn't wait, I immediately ripped it open and started reviewing the contents. The printer arrives completely disassembled.

Being a proud tradesman, I decided early on that I wanted the wiring to be built and wired in a neat and workmanlike manner as much as is physically possible. This turned out to be more difficult than I'd hoped later -- most of the wires attached are far too long, and a couple were just a little too short for a good install. In retrospect, I likely would have built it differently knowing what I know now. In particular, I would have planned from the beginning to have an electrical box on the side and run the extruder wires directly through it. But I'm getting ahead of myself.

The box allegedly came with instructions, but I found the written directions disjointed and incomplete. The best bet was following the videos on YouTube. The video was essential to putting the printer together, but as time went in the level of detail started to slip. Eventually they stopped telling us which screw sizes to use and when it came time to wire the board it just said to look at the wiring diagram.

If you follow their directions perfectly, you'll end up with a rats nest of wires. There's very little mention of routing the wires except for the end stop switches, and the instructions assume you'll jam the box on the table under the heated floor. I ended up pulling apart some of the printer after assembling to route the cables in the aluminium rails.

The kit comes with virtually everything you'll need to build the printer. The bolts are all metric and I didn't realize they'd done that until I'd made it part way through. It was a pleasant surprise.

I purchased a 6x6x6 electrical box from home Depot and 2 strain relief connectors. In retrospect. I needed 4 strain relief connectors: 1 for the wires from under the heated bed, one for the wires from the extruder and the 12vdc power, one for the USB cable, and one for the pair of ribbon cables going to the display. I'm reasonably happy with the result on the outside, but inside the box is a rats nest of wires because some of the wires are too short.

I had a premonition once the wires were connected and plugged the 12v power supply into the wall for a smoke test. Blue Sparks immediately started sizzling and flashing from the power supply! I quickly unplugged the supplyand discovered that the screw terminals on the supply had not been soldered down. Gives me reason to question that QA sticker. Sort of a big detail to miss. I soldered the screw terminals in and after that was getting 12.00vdc on my meter. Good enough!

There are numerous extra parts not shown in the video. Fans, heat sinks, and much more. I'm happy to have parts, but I'm concerned that I'm hurting something by not installing these parts. Before I do major printing, I intend to install at least the heat sinks.

Before I got the printer, I started reading and chose tinkercad as my first 3d modelling program. It's very simple, which I feel I need at this point. I designed a simple ball valve as my first print. I'm hoping to eventually 3d print stuff like this. Tinkercad is easy to use, web based software from Autodesk. Once you're happy with your object, you can Immediately export it as a file the 3d printer software stack can understand.

The board contains an atmel microcontroller, and is programmed using the Arduino software. The firmware it comes with is called "Marlin", and 99% of the work is already done. That last 1% is a doozie.

There is a buzzer, a knob, and a button on the front panel. The buzzer does what you'd expect, the knob is used to control the units interface (spin it left and right and press to select), and the third button immediately resets everything. I treated that third button like an emergency stop, and I needed it a lot at first.

I downloaded the latest Marlin source code and used the example configuration for the flsun 3d kossel mini. All the configuration is in 2 files, a configuration header and an advanced configuration header. You've got to tweak them in the Arduino software before you start.

There's a #define that allows you to access the calibration menu from the faceplate. I uncommented that early because it made it easier doing all the cal tests that I ended up doing.

The example configuration for the kossel mini in Marlin 1.1.18 was dangerously wrong for my printer. The more immediate problem is that the delta radius was substantially off. This meant that the print surface was extremely convex. In the middle of the print surface, I would be touching the print surface with the print head, but at +50 or -50 on the x or y plane I could fit my finger beneath the print head. I measured the radius from the print head to the pivot point on the side rail of one of the arms, and I think I found a number somewhat like 135mm. The number was very different from what the config had by default. With this massive error, the printer could not auto calibrate. The second problem was the delta height was too low. It was set for 250 or so. This caused it to try to find the bed level in the middle of the air. I set it to 318 and the height calibration worked, somewhat. More on the height later. Finally, the printable radius was set to 110. This is the dangerous part. The printer simply cannot move like that. Ultimately, I might be able to set this to 50-55, but after getting burned a couple times jamming my print head outside the print area and jamming the e-stop, I set it to 40 for now. The second number that was causing the calibration to catastrophically fail is the cal radius. It was set to something like 90, Which is simply outside the range of this printer. I set it to 36.

All this took time to figure out -- about a day, After setting these values and uploading the resulting firmware, I was finally able to get the machine to complete an auto calibration cycle.

There's still one problem: the bed height is coming up too low. My reading suggests that the problem is the spring dampeners on the bed. The nozzle has a spring and a limit switch, so when the nozzle touches the bed it is supposed to push the nozzle up and actuate the switch while calibrating. With springs on the bed, the bed bounces back as well, causing inaccuracy on the calibration because the bed moves down. I've been able to print by manually decreasing the bed height, but the inaccurate calibration has also caused inaccurate measurements on the bed level. As a result, the nozzle digs in on one side and floats on the other. I used thick magazine paper as my bed material to reduce damage to the head if it does dig in for my first 2 prints. When I get home I'm going to mount the bed solidly to the frame to eliminate the vibration error. Seeing what masking tape does on a heated bed, I purchased some kaptan tape for future prints.

Out of the box, there's nothing to hold the reel of filament. Once I have the printer working reliably, one of the first things I want to print is a reel holder. In the meantime, I noticed that the rails are wide enough to hold a jeweler's screwdriver, so I am hanging the reel off a jeweler's screwdriver for now.

The software stack the printer uses on windows is called Repetier-host. You can download .STL files from thingiverse and directly open it in Repetier. From there you choose print location and size, then send the print to software called a "slicer" which turns the 3d model into instructions the printer can print, called g-code. From there, the slicer can directly give the instructions to the printer over USB, or it can save the g-code file to an SD card. You can then directly place the SD card into the printer and print using the front panel.

I had to fiddle with a couple settings. First, I had to set the printer surface to be circular, and I had to fiddle with the slicer, telling it my filament size, extruder size (.3 it seems), and a couple other options.

Having done all this, I finally successfully printed something!

That said, it was more dumb luck than anything. I successfully printed a little ring for my wife, then I printed the valve I designed, but after that I was having issues getting the bed to stay down.

I discovered 3 things: first, the aforementioned bed springs being a problem. Second, the extruder temperature was too low causing the bed to have problems adhering. Third (paradoxically), once the filament left the extruder, it stayed too hot for to long, so the prints melted into a mess that looked like a wax sculpture of what I wanted melting in a hot car in the sun.

For a first attempt, I'm pretty happy. If it was easy, it wouldn't be nearly as fun.

I'll keep you posted. Thanks for reading!