Sunday, June 9, 2019

My notes on J.B. Rainsberger's "Practical Tools for Playing Well with Others"

Presented by J.B. Rainsberger at November 7th 2013

Conversations begin with Intake - See, hear, read

This can go wrong. We can hear wrong, misinterpret, misread.

This is an area we tend to assume isn't a problem but it often is. The gorilla test proves that. While we are focused on one thing we miss other things.

After Intake, conversations progress with Meaning - We decode the signals/symbols.

We have issues with meaning all the time. Same words can mean multiple things to different people and in different contexts.

This leads to arguing with people you agree with.

It's important to clarify meaning.
"Normally when somebody says xxx, they mean this, this, and that…, What did you mean when you said xxx just now?"

We need to establish how close we are to the meaning of the words, identify potential differences and see what we can do about it.

After Meaning we have Significance - Why did this just happen?

Significance has to do with the deeper meaning. The meaning behind the meaning.

Why is the other person behaving this way. Figuring out how to interpret the message.

The last part of the model is Response - After all the first three happen, we have to figure out how to respond to that.

Checking on perception before responding can help. Check intake.

Checking on misunderstanding before responding can help. Check Meaning.

Checking on misinterpretation before responding can help. Check Significance.

What did we see or hear that leads us to conclude our choice of response?

The path between Significance and response is REALLY hard to control.

It's best to assume that this path for others is hardwired and isn't going to chance.

Timestamp: 24:50

One of the ways that you can improve your interactions with people is by assuming that if somebody responded in an inappropriate, unexpected, threatening, unusual way; that that reaction was perfectly sensible, reasonable, and defensible given how they interpreted, understood, and perceived the situation.

Being hardwired, there is nothing we can do about it and there is nothing we ought to do about it. Let's fix the other areas instead.

Misperception is a difference of perception. Misperception is a wrong assumption that our way of perceiving things is the only right way of perceiving them. When there is a difference, it's best not to make a value judgment.

Same with misunderstanding. This is a difference of understanding.

Same with misinterpretation. This is a difference of interpretation.

Because these paths are so quick, at first all we can do with this model is debug a conversation after it happened. But that's a start. It can help to work from the bottom up.

How can we figure out why they interpreted it the way they did? Or understood it the way they did… or what they may have perceived that wasn't intended.

Timestamp: 31:25

It gets even more fun when you are so practiced at this that you can use this to pre-bug a conversation. TDD for conversations.

How might one interpret what I'm about to say?
Maybe I better choose different words.

How well do I know whether this persons understands the word I'm about to use?
Maybe I should try a different word.

Am I speaking clearly enough?
Maybe I'd better speak up or check my phone connection.

Timestamp: 32:40

Things really get interesting as we consider how your response leads to their intake and their response leads to your intake. This can spiral in terrifying ways.

Timestamp: 41:00

A Few Helpful Tricks

Think of three ways to interpret what just happened… before you respond if you can.

Ask, "What did you intend by that [surprising comment, question, action…]?"

Communicate in E-Prime to reduce judgmental perception. (

Warn the other person when you need to say something uncomfortable.

Further reading:

Jerry Weinberg, "The Secrets of Consulting"
Mark Goulston, "Just Listen"
Stone, Patton, Heen, "Difficult Conversations"

Friday, June 7, 2019

Interested in Exploring Software Development?

Glad to hear about your interest.

Here’s a link to some free training courses on Pluralsight:

This is a good resource too:

This one from Microsoft Virtual Academy is free (and perhaps a bit dry): is a good resource I’m told. Here’s a link to their Development section:

My son vouches for Mosh Hamedani's C# for Beginners course:
He also operates his own site:

I tend to use which comes with a free month to explore it. Scott Allen has authored great courses on Microsoft stuff in Pluralsight. You could search for him on that site and find plenty. He’s got a good teaching style. He’s got a blog site here:

I would also encourage you to become familiar with using git (Version Control Software).

A great tutorial on git can be found here: (It talks about using the Ruby programming language but you don’t need to install Ruby or be familiar with it… they just use Ruby source code files as examples).

There is an excellent free eBook on git too:

Git is something you’ll want to use for a lot of things… it’s quite a powerful tool and I’m finding more and more value in it week after week of using it. Quite impressive.

I like to use Git Extensions for Windows:

I believe that will walk you through everything you need but it will depend on git and something like kdiff being installed. I just use their defaults and follow their installation recommendations.

If you run into problems with any of these let me know. I'm happy to help.

Thursday, June 6, 2019

Exploring Virtual Commissioning (AKA Digital Twins)

We're seeing tremendous potential value in Virtual Commissioning.

In the past, I was able to improve my control software with a focus on the handling of part passing through the line from coil to finished product. I was able to do this by writing up my own 2D simulator from scratch which we showcased at the Manufacturing Day we hosted at Mestek Machinery in 2012.

Showing this to our state senator (Charles Grassley)

Video we played to show the visitors 
on tour about some of the things 
we were using technology for

This project was a big success and greatly reduced problems we were seeing in the field for those who we upgraded with the changes.

I wanted to take that to the next level to enable better tuning and refinement of my control software at the machine level (instead of just at the line level).

I began generating a virtual 3D ductline within the Unity 3D game engine which is used in many game development environments. I replicated my 2D line simulation within Unity (using cubes as stand-ins for detailed models) and drove it by writing a networked interface between the game and the inputs/outputs from my actual machine control program running on actual hardware (in my office). This allowed us to interact in a very natural way with the parts on the line while seeing how the real-world program responded.

This showed a lot of promise but at that time we had little of the product line modeled in solids.

Times have changed since then and I was ready to re-visit these efforts when I found out about a fully integrated solution being provided by our hardware vendor. This takes things to a whole new level and promises huge payback once implemented. This enables the virtual commissioning of machinery and automation control software through something being called a "Digital Twin". Exciting times!

Friday, May 31, 2019

Brief History with Video Examples

Welty Automation contracts full time with Mestek, Inc. and works out of the engineering department in Cedar Rapids, Iowa factory location of Mestek Machinery. 

I grew up around automated sheet metal and coil processing equipment design and manufacturing. I first helped my father on a design project at around 16 years old; by programming a PLC to control a simple robot designed for use on a machine that produces downspout elbows. 

The robot took the elbows out of the machine, crimped the end, and drop the crimped elbow into a box positioned next to the machine to reduce operator repetitive motion strain.

This is a video of the newer version of that machine and robot which improved on my original design:

I started working for Iowa Precision back in 1987 as a drafter after my father's adjustable elbow machine company was acquired by them. I helped usher in the use of CAD shortly after that and later wrote the software to replace their mainframe based business management software. 

Sometime around 2007 I was asked if I could take over the control software development for a new machine which I was able to name: The DieMation

This was the project that launched my career in automated control software:

I was then asked to get involved with the controls on their flagship productline and have been writing the control software for new shipments of that product line since 2008. 

Here are some sample videos of projects related to that product line:

Customer Testimonial for Pro-Fabriduct line with partial width inline plasma table:

Residential Ductline:

Compact Ductmaker:

Working remote

One of the challenges when being out on the road at customer installations is finding a good place to work. This is my desk at times which works pretty good. 

These bad boys pay the bills
--both the machine and the laptop--

Operator Training Videos in Production!

We're currently working to create video training content for users of new ductlines. This is an exciting project I've been trying to get traction on for quite some time. I went out to meet a colleague who does video production at a graciously hospitable customer site to get screen recordings and video footage to put together with audio.

My goal is to target short video segments to cover targeted areas of focus and key aspects of the control software that I always ensure new operators understand. These videos will ideally be easy to access, easy to digest, and short enough that people won't feel that they have trouble finding the spot they want to refresh themselves on.

A first draft video showing a technique for aligning fiberglass insulation in an Insulmatic: