My new printer, the Tevo Tornado

October 27, 2018 - Reading time: 4 minutes

I'm Jason Firth.

 

Late last year, I decided it was time to jump into two technologies I really wanted to play with that I'd been putting off for a long time: Virtual Reality, and 3d printing. At the time I selected what appeared to be good choices for both off of Amazon: The Oculus Rift for VR, and the FLSun Delta Kossel for 3d printing.

 

At the time, I expected virtual reality to be the thing with staying power and for the 3d printer to be a quick toy. What I quickly realized is that Virtual Reality isn't really for me in a lot of ways -- I've played many hours, but never really gotten sucked in the way I thought I would. On the other hand, 3d Printing has become a hobby I really enjoy.

The FLSun Delta Kossel was an inexpensive unit. Today you can buy it on Amazon for about $200 CDN. It was really a cheap unit, and I've written about my experiences with that unit.

 

Plutarch wrote of the Ship of Theseus: "The ship wherein Theseus and the youth of Athens returned from Crete had thirty oars, and was preserved by the Athenians down even to the time of Demetrius Phalereus, for they took away the old planks as they decayed, putting in new and stronger timber in their places, insomuch that this ship became a standing example among the philosophers, for the logical question of things that grow; one side holding that the ship remained the same, and the other contending that it was not the same."

 

The printer over the course of the year has become like this. I've replaced virtually every component, upgraded everything in some way or another. Is it still an FLSun Delta Kossel? That's difficult to say. What I can say for certain is it's now a very impressive printer that tends to put out excellent quality prints.

 

After my year with the printer, I realized how much I've enjoyed 3d printing, and I wanted a larger printer that's a bit more standard so I can start printing larger things and spend a bit less time tinkering with the printer itself.

 

To that end, I've bought a Tevo Tornado. It is a popular model of printer, lots of support out there, and overall I feel it's going to be a good choice long-term.

 

My first impression: I'm really impressed with a lot about this printer. The FLSun came in a million pieces and took me a full 2 days to assemble. By contrast, it took me all of 2 minutes to assemble the Tevo Tornado when it arrived. It homed immediately and I found it simple to level the bed, contrasting the Delta's bed which was always a pain. I'm really happy with the first 15 minutes with the thing.

 

Before I even get started with this printer, however, I want to replace the main board. It came with an MKS Gen L, identical to the FLSun. There's no problem with this board for straight 3d printing, but I want a board with a processor instead of a microcontroller, having seen the limitations of the Atmel mega while using my Delta Kossel, and I want a board with built-in Wifi capability. Using Octoprint on my previous printer was a great experience, running around with a memory stick is ridiculous when I can just press one button to start a print. I purchased a DuetWifi clone board. 

 

I'll pass on my notes as I work with this new printer.

 

Thanks for reading!


Too many software engineers

May 27, 2018 - Reading time: 4 minutes

I'm Jason Firth.

At one point, most instrument software was written by instrument specialists. As a result, it was small, simple, and specialized.

This was good. Specialized software may be ugly, but it works, and is often designed with specific technician use cases in mind. Moore's software packages for communicating with their smart instruments are a good example: with one utility and an RS-232 cable, you could configure, query, troubleshoot, and test an instrument.

Software engineer types would rather create flexible platforms to develop software on top of.

Now, that is a very legitimate desire. If you can build that one tool, then you can make it easier to access a large number of devices with one tool, and you simplify the development process for vendors, who can focus on the job, rather than the surrounding elements.

There are problems with creating a flexible platform if it isn't done carefully.

One problem with this is that flexible platforms add complexity for end-users. PactWARE, for example is a marvelously flexible piece of software. It allows you to not only use a number of point-to-point hardware devices such as HART or Endress+Hauser's proprietary communication cable with a simple swap of the DTM; it also allows you access every single device in your plant using multiplexers, or to access IP HART devices. The problem is that all this flexibility is extremely cumbersome to navigate.

ProComSol Devcom2000 is a piece of software that only speaks HART through a serial port or USB modem. Its simplicity allows a technician to connect their modem to the PC, connect the modem to the HART instrument, and run the program. The software will immediately connect to the instrument, after which you are ready to go.

By contrast, PactWARE requires you to connect and start the software, followed by installing the HART communication DTM, followed by configuring the module, followed by opening the autodetect window, then running a scan, then selecting the correct DTM, then closing the autodetect window.

This is one example of one software package compared to another, but the fact is that there are countless examples of software trying to do everything, only to be less useful as a result. I try to design anything for that 2am call, and a ridiculously complicated tool isn't conducive to this.

Another issue with creating these extremely complicated software programs is a simple truism: the more moving pieces you have, the more things there are to fail.

I really like Wonderware Historian for its standard SQL front-end and tight integration with wonderware and application server, but it is a complicated beast. IO Servers speak to the PLC, the Historian mdas service communicates with the IO Server, (assuming the import went correctly), which communicates with the historian storage service. To retrieve, the SQL service links up with the retrieval service. There's other services involved as well, but the bottom line is that any one of these parts is huge and complicated, and all it takes is one cog in one of these giant machines to break.

Historian isn't even the worst. I've seen instrumentation configuration utilities that require always-on services to be running, a full SQL server instance -- just to shoot a couple bits over an RS-232.

The problem is that conceptually on a software development level, using these tools makes a lot of sense -- you've got this big fancy development package and this big fancy software engineering degree, of course you've got to make use of them! A small, simple program that does one thing very well, that's not going to work. We need a platform. Something that can handle all use cases. Something that can keep me employed fixing it!

Thanks for reading!


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

March 22, 2018 - Reading time: 6 minutes

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.

March 5, 2018 - Reading time: 10 minutes

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:

![undefined](pcsettingsapp_0_o.png)

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

February 2, 2018 - Reading time: ~1 minute

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

January 31, 2018 - Reading time: ~1 minute

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.

 

![undefined](img20180131200947_0_o.png) 

 

 

Thanks for reading!