Makerbot Replicator – The Cure for the Curl

I really enjoy my Makerbot (5th Generation Replicator).  The only maddening part about it was getting good adhesion of prints to the build plate.  I tried all the standard tricks – blue tape, hair spray, hair spray and blue tape…

I designed a clamp system to hold down the raft during the print, and that was somewhat successful.

Recently though, I discovered a cure for the dreaded raft/print curl that plagues this and most 3D printers.  It is a mixture of old tech (Aqua Net hair spray) and new tech (Polyetherimide sheet).

Supplies for this upgrade:

–  Polyetherimide Sheet (PEI), available from GizmoDorks in all sizes:
–  Aqua Net Hair Spray

Lightly scuff the PEI sheet with 800 or 1000 grit sandpaper, then apply the PEI sheet to the glass plate according to the directions.

Then, before each print, spray a liberal amount of Aqua Net on the PEI sheet, covering the entire area where the print will reside.  Use about 3X what you would use if you were spray-painting the plate.  To cover the whole plate area, figure on spraying for about 7 seconds.  

The Aqua Net will go on cloudy, but will turn clear in a minute.  Wait about 5 minutes before printing.   For me, the raft sticks extremely well   Invest in a good putty knife or scraper to remove the print!

I don’t bother cleaning the PEI between prints – I just apply more Aqua Net with each print.

Now, even prints that take up the entire build plate will print with no curling.   Below is a group of brackets that I printed with this method that printed perfectly true.  I hope that this information helps others with their curling prints!

Look – no curl!


Industrial IoT – What is it all about?

Industrial IoT – What is it all about?

Today’s Industrial IoT is an outgrowth of the Machine to Machine (M2M) technology that began with the ladder logic and SCADA systems of the 1980’s and 1990’s.  Increased monitoring and computerized control has demonstrated the ability to make machines last longer and run more efficiently.

Connecting machines together and to back office systems over the Internet has transformed the simple M2M into the Industrial Internet of Things.


A Different Kind of Calculus

When considering or planning an Industrial IoT system, the benefits of the system must be weighed against the costs (and the risks – see Security below).  An Industrial IoT system may add some capability to its machinery, but more often the value of Industrial IoT is in increased visibility or control on the industrial system rather than new capability.  A smart electric meter will likely still just meter electricity, it won’t have additional abilities like streaming movies or brewing coffee.  But it will be able to help the power grid regulate for peak use and it will not require a meter reader to drive around the neighborhood reading meters by hand.

The cost/benefit calculus used in planning Industrial IoT should focus on increased visibility and control.  Some questions to consider:

With better visibility, can preventative maintenance be more effective? For example, a vibration sensor can alert when a pump or motor bearing is days or weeks from failing.

With finer grain measurement and control, can the industrial machinery be more efficient in terms of electricity, materials use, or time? This often involves Local Processing (see below) as well as analytics performed on vast amounts of data collected in the cloud.


The Industrial Environment

The harsh environment of some industrial machinery gives rise to challenges in building IoT hardware.  Industrial settings may include:

Extreme heat, cold, or humidity that require special industrial rated electronic components and enclosures.

An abundance of metal and RF noise that makes wireless communications difficult

Remote location, which may limit internet connectivity and make battery replacement a challenge

Each of these challenges may place very strict requirements on the IoT system in terms of power consumption, bandwidth use, or physical construction.


Local Processing – Computing at the Edge

Most IoT diagrams depict a standard 3 tiered architecture.  The Edge Nodes are generally simple sensors, which are aggregated together by a Gateway, which is usually Internet connected.   The Gateway transmits the data up to the Cloud where the data is analyzed.   Perhaps some simple control is passed back down from Cloud through the Gateway to the Edge Node sensors.

Many Industiral IoT systems have requirements that drive the need for Local Processing to occur on the Edge Nodes.  There are several factors that can drive this need:

Bandwidth to the Gateway or the cloud. It is sometimes highly advantageous to send ‘the answer’ to the cloud rather than all the data that gets the answer.  For example, a traffic camera that does license plate recognition inside the camera and sends only the license plate number and state would send many thousand times less data than one that sends pictures of license plates up to the cloud for recognition.

Latency in making local decisions. A temperature sensor and cooling valve can form a simple control system to keep equipment cool rather than waiting for the cloud to receive a temperature and send back information to open or close the valve.  The minimum latency permitted on the control of many industrial systems is measured in microseconds or miliseconds, several orders of magnitude slower than a round-trip to most cloud based systems could provide.

Simple IoT sensors and cloud based processing will not replace the ladder logic and SCADA control systems.  But it will augment those systems and provide a way to analyze data and make broader decisions than those localized systems could make before.

Look for upcoming articles on the pros/cons of Local Processing.


Security in Industrial IoT

Security in all systems (computerized or not, networked or not) should be a key component in every design.  As industrial systems were enhanced with electronics and eventually connected to (un-networked) PCs, the security of these systems did not take into account the new ‘attack vectors’ quickly opening up.  Soon the PCs connected to the equipment were placed on local networks, and sometimes the equipment itself was placed directly on the local network, or directly on the internet.

Recent major security breaches with IoT devices (e.g. Miria-bot, BrickerBot) have demonstrated that the industry is not keeping pace with bad actors when it comes to security.  Recent legislation attempting to dictate solutions is likely to be out of date before it is enacted.  What is needed is a holistic approach to IoT security that uses the best of what we have learned from 20 years of desktop security and adjusts for the unique nature of IoT.

Look for upcoming articles on best practices for IoT Security.

IoT Security – What’s our Vector?

IoT security failures such as the Mirai bot DDOS attack have served to remind us that failing to secure IoT devices can have serious consequences.  

As we rise to the challenge of securing the next generation of IoT devices, it is important to start by identifying the vulnerabilities in IoT systems before launching into building solutions.

Security is a Weakest-Link Problem
When planning the security for any system, keep in mind that security is a weakest-link problem.  Consider all the security aspects of your system as if they were links in a chain.  When tension is placed on that chain, it will be the weakest link that breaks. For example, you may have the fanciest encrypted secure booting features enabled in your system, but if you ship with a default password or JTAG pins populated, all your efforts in other areas will be nullified by these mistakes.

Consider your Attack Surface
The concept of an attack surface is as old as computer security.  The attack surface is all of those points of vulnerability (called attack vectors) where attackers can attempt to access the system to cause harm.  Attack vectors can be in firmware, hardware, system design, physical design, or process.

The Simple Stuff – Lock the Front Door.
Millions of IoT devices have been placed into service with their default access passwords left unchanged.  Simply requiring passwords to be changed during installation is table-stakes level stuff in security.

Reduce the Attack Surface
Many IoT systems are built on full featured operating systems such as embedded Linux.  By default, these operating systems have a plethora of interfaces into the system – Telnet, FTP, serial console, SSH.  These may be a required feature in the system.  Or, they may be just an unnecessary door left open, a weak link in the security chain.  Even if they are necessary, there are strict protocols for securing each of these interfaces which are well know from the server community. 

Physical Attack
Unlike PCs and server based systems, embedded systems have a long history of physical style attacks.  The same electrical engineering skills, development tools and in-circuit emulators that are used to build embedded systems can also be used to pry them open and attack them.  Signals on a board can be traced, snooped, and decoded.  In a few minutes, firmware can be siphoned out of an EEPROM, to then be examined offline for hours.  The best prevention from physical attack is to prevent physical access to the system, but this is not always possible.  Techniques such as secure encrypted boot, and encrypted file systems can protect ‘data at rest’.  Encryption of data during transmission can protect a system from excess scrutiny while it is running.

Remote Update – a Double-edged Sword
The ability to update the software in an IoT device in the field is important for security.  If a software vulnerability is found, the software must be updated to fix the vulnerability.  If not properly protected, this same remote update can be used to install all sorts of malevolent software into the system.  For that reason, in-the-field update should be combined with application verification and/or secure encrypted boot to validate whatever image is loaded.

Security is an integral part of any IoT design, not something to be left as an afterthought to be bolted on at the end of a design.  The first step in building a secure system is identifying where it is likely to be insecure.  Then security can be properly considered in every step of the design process.

The technology behind stores like Amazon Go

Amazon Go
Amazon has announced their cashier-less Amazon Go store, opening in beta, for selected Amazon employees to try out.  Upon entering the store, a shopper checks in using a mobile app.  Then, the shopper can simply gather all the items they need from the shelves and walk out.  Their Amazon account is charged for each item they remove from the store.

Observers were quick to make the connection between the descriptions of this store and an Amazon patent filed in 2014 which describes a number of technologies that could be used in such a store.  Let’s examine this patent and pick through the technologies that are described there.

Lots of Sensors
Of course, all this tracking of people and products requires the coordination of many different types of sensors.  This includes:

Cameras Gathering images for use in everything from facial recognition to image recognition of products
Depth Sensing Cameras Depth sensing cameras can accurately determine distances and relative position of customers to products, for example to determine if a customer is near enough to a product to be picking it up.
Pressure Sensors
Load Cells
Volume Displacement Sensors
All of these types of sensors can be use to determine if the current inventory of a product (in packaged or bulk form) has just changed.  In addition, sensors in the floor at the doorway can be used to basically ‘weigh’ the customer when they enter the store, and again when they leave, to validate the purchase
Infrared Sensors Infrared sensors can distinguish between (generally) cold products and warmer customers.  This can be used to tell when a customer’s hand is reaching into a product area and removing a product.
Light Curtains These simple sensors can detect interaction of customers with the products by detecting when a customers hand enters the region near a product.

Sensors in Action
An illustration from the patent filing below shows how all of these various sensors might collaborate to track products and customers.


Two Basic Questions
All of the tech in a cashier-less store like Amazon Go is focused on answering two basic questions:
 1) Who has entered the store (or who is now leaving)?
 2) What items has that customer interacted with, and which are they taking with them?

The ‘Who’ question is at least as hard as the ‘What’.  The current Amazon Go takes the easy way out on this one – customers are required to check in with an mobile application while they are standing in a ‘check in area’.  From here, it would be reasonable to assume that a combination of object tracking and facial recognition would be able to follow such customers throughout the store.  Although it would be fun to see if a human version of Three Card Monte shuffling in the aisle could confuse the tech.

The ‘What’ could quite reasonably be solved using RFID tags on every item, but where’s the fun in that?  Seriously though, the cost of RFID tags continues to be just too prohibitive for it to be placed on every single bannana, can of vegetables, or box of mac-n-cheese.  Plus, it requires either the stores to affix these tags, or the suppliers to include them.  This is why more ‘passive’ technologies which do not require modification to the packaging of each item are favored.


Brave New World?
Using cameras to track shopper behavior isn’t new.  For years, the same cameras that were used in retail stores to watch for shoplifting were also being used to gather retail analytics. Retailers can track which displays are receiving the most foot traffic.  They can measure ‘dwell time’ to determine whether customers are stopping to review a product, or just walking by.  Shoppers can be classified by age or gender and the effectiveness of displays judged on each classification.

Customer self-checkout is not new either.  Most retailers have some form of it, usually requiring interaction with an actual barcode scanner either at a standard checkout kiosk or as the customer places items in the cart

The Amazon Go experiment is taking each of these paths one more step, enabled by the newest sensor technologies, recognition algorithms, and computing power.  

Cashier-less stores may appear revolutionary today, but compare this to the first remote access self-service gas station, which opened on June 10, 1964.  The technology for remotely activating the pumps, maintaining safety, and controlling theft was primitive by today’s standards.  Few companies were convinced that drivers would be willing to pump their own gasoline.  But by 1982, 72% of all gasoline sold in the US was self-service.

Applying Agile Methodology to Embedded Systems Development

By Ed Kuzemchak

The Agile Methodology, which was conceived in the early 2000’s, has since achieved broad acceptance in software development and beyond for improving schedule reliability, product quality, and even overall team morale.

Agile brought together a number of previously successful techniques such as Barry Boehm’s  Spiral Model1 and Sutherland and Schwaber’s SCRUM Process2 into a overall methodology that has become widely adopted in general purpose software development.

Until recently, the iterative development model championed by Agile was difficult to achieve in embedded systems projects.  At the same time, the growth of Internet of Things and mobile devices have applied pressure to embedded designers to build larger software systems on every tighter deadlines.

New tools and techniques allow embedded designers to leverage the benefits of Agile to meet these demands.

In a series of articles, I will discuss how Agile methodology can be integrated into embedded systems and IoT projects.

System Architecture and Rapid, Early Prototyping

In early phases of an embedded systems project, many important architectural decisions are made that will have a lasting effect on the project. Selection of processors, real-time operating systems, and development tools for the project will be made at this time and those decisions will be difficult to change later.

By creating early prototypes and proof-of-concept systems, much of the risk and uncertainty of the project can be resolved before significant effort, time, and expense are invested. An article on how recent advances have enabled early prototyping in embedded systems is forthcoming.

Off the Hardware and Software

Leveraging pre-existing modules, both hardware and software, has allowed desktop and enterprise software developers to deliver more capability on shorter timelines with fewer bugs than ever before.  Embedded systems have additional size and power constraints that, in the past, have led to a complete ‘from scratch’ approach to development rather than building from off the shelf components.

More recently, using off-the-shelf hardware and software has become a viable option for embedded systems designers. In an upcoming article, we will discuss the performance, security, and flexibility factors that must be considered when using off-the-shelf hardware and software.

Continuous Integration and Test

Continuous integration and automated testing is the backbone of a successful Agile process.  Continuous integration automates the build process and continuous automated testing provides rapid feedback on quality through regression testing.

Automating the build of embedded software is often challenging, and automating a regression test suite that involves embedded hardware can be a sufficiently daunting task that many developers pass on this valuable tool. An upcoming article will describe how embedded build environments can be integrated into popular Continuous Integration systems and how automated testing can include embedded hardware.


Using Agile methodology in embedded system projects can provide value in every stage of the development process.

[1] Boehm, B. (1988), “A Spiral Model of Software Development and Enhancement,” IEEE Computer 21, 5, 61-72

[2] Sutherland, Jeff; Schwaber, Ken (1995). Business object design and implementation: OOPSLA ’95 Workshop Proceedings. The University of Michigan. p. 118. ISBN 3-540-76096-2.