¶¼ÁéÌåÓýÖ±²¥

Release date: 13 July 2020

Episode 29: Ben enjoys watching his neighbor struggle with their sprinkler system. Stephen hopes to have the end-of-arm-tooling (EOAT) for the xArm soon. Ben and Stephen host Russ Waddell, the Managing Director for MTConnect at AMT for some standards learning. Ben brings up an article on the future of robot safety. Stephen closes by drooling over the Sony PlayStation production line.

- - - - - -

Subscribe to the Weekly Newsletter Amateur Machinist Blog Music provided by

Transcript:

Benjamin Moses: Hello everybody, and welcome to the Tech Trends podcast, where we discuss the latest manufacturing technology, research and news. Today's episode is sponsored by IMTS, ReBuilding the Supply Chain Starts NOW. IMTS is building a knowledge warehouse to ReThink, ReEngage, ReEstablish manufacturing supply chain. The past few months have unveiled underlying issues with supply chain, and it's time to discuss these problems and how to move forward. Visit imts.com/supplychain for more information. I am Benjamin Moses, the Director of Manufacturing ¶¼ÁéÌåÓýÖ±²¥, and I'm here with...

Stephen LaMarca: Stephen LeMarca, the Manufacturing ¶¼ÁéÌåÓýÖ±²¥ Analysts, and Ben, we have a guest today.

Benjamin Moses: Awesome. Who do we have on?

Stephen LaMarca: Russ, would you like to introduce yourself? We have Russ Waddell here.

Russell Waddell: I'm Russ Waddell and the Managing Director for MTConnect and AMT.

Benjamin Moses: Thanks for doing half the intro there, Steve. I'm glad everyone's on here today. Before we get into the testbed and potentially articles, I wanted to bring up observational by neighbor. I'm living in a standard planned community with HOA and my neighbor installed a automated sprinkler, underground, went full in. I still have my above ground hoses everywhere, timed sprinklers. And I'm happy to say that his lawn looks like crap. Well, I feel conflicted about it because I think he put in some effort thinking that automation or putting a automated sprinkler system would solve his problem, but he forgot the support that the lawn also needs. You still got to cut the grass regularly, still got to feed it. You still got to do all these other things, and I think that's one thing I've taken away from observing his failure. One is automation is not just a solution. It's always a support to an overall problem. And there's a bigger picture that needs to support a full system. Also, the HOA won't be yelling at me because the lawn looks like crap. They'll be going to him first. But I just wanted to talk about that and bring that up [inaudible 00:02:05] we get into some articles.

Stephen LaMarca: My question, Ben, is you've reported to us via the podcasts on all of your struggles with home automation and how you overcame the challenges and you've documented your progress through optimizing it. Are you going to share with him, your neighbor, what he can do to make it better? Are you going to try to help him at all? Or are you just going to go over to his house and be like, hey, you need to cut your grass?

Benjamin Moses: I might give him a few pointers or put a sign for a service he can probably go to. I feel like he's not putting any effort... He doesn't want to put effort into the lawn. I think I'll refer him to some Scott's Lawn Service or something like that.

Stephen LaMarca: Slide some business cards under his door.

Benjamin Moses: Slide some business cards, yeah. I think that's the way go. I mean, I'm still keeping my distance too, because I don't want to talk to people still during the pandemic. That's my excuse right now. Once the pandemic is gone, I got no excuse. So Steve, what do we got going on in the testbed? Why don't you walk us through your-

Stephen LaMarca: We don't have much, but there is something that hopefully celebrate about. This week I was thinking over what's next on the testbed, and I remembered, wait, we got this, relatively new to us, collaborative robot, freshly bolted down on the testbed and functional, but we're still waiting on... It's been two years now and we're still waiting on the end of arm tooling to show up, the gripper. So I reached out to UFACTORY, because the last I heard from them, they were like, "Hey man, the pandemic is crazy over here. We're looking to get it to you around March." Then I realized, well, March was a long time ago. Let's reach out to them and find out where this gripper is. So middle of the night last night, I sent an email to Zoe, who's my primary contact there, and she's like, "Oh snap, we'll get you the gripper by next week." I was like, "Send me a tracking number." It didn't happen, but we've got one on the way, finally.

Benjamin Moses: That's promising. That's good. I'm glad to hear that they're in a state where they can move forward also.

Stephen LaMarca: Yeah. Didn't hear any sob stories, no complaints, just next week.

Benjamin Moses: Good, good. Now hopefully we'll be transitioning back to the office on a regular basis, some in the next couple of weeks, months, so we can get projects up and running also.

Stephen LaMarca: Yeah. Also, with the testbeds, since we have Russ here, he introduced himself earlier, I don't want to do it again. But anyway, part of the testbed is proof of concept for MTConnect. We run MTConnect on our devices and whatnot. I remember my first year here at AMT, I put an MTConnect simulator on a Raspberry Pi with the help of Russ, and the MTConnect user portal, so mtcup.org, I believe. Now, we don't really have the need for an MTConnect simulator anymore because we have actual manufacturing devices on our testbed, like the Pocket NC and like the xArm and Shaurabh has gotten both of those devices up and running with MTConnect adapters and agents. My question to Russ is what did it take to get MTConnect on the testbed machines, like the Pocket NC and xArm?

Russell Waddell: It took an afternoon of copying and pasting code, and watching it slowly go on to the entry level computing that powers the devices that we have. The Pocket NC and the xArm are both run off of relatively lightweight computing platforms. To actually install them to connect you need a couple of components. You have to have an adapter which takes whatever the native terms that the controller uses, and puts those into the MTConnect dictionary. For the Pocket NC, that thing runs on machinekit, which itself is a derivation of linuxcnc. Linuxcnc has this nice public facing Python API where it'll tell you what every single data item in the linuxcnc software is, and you basically have to write a little translation table to go from what it is in linuxcnc versus what it is in MTConnect, so that's terms like spindle on, emergency stop armed. There's a very specific way that you would write that out in MTConnect, and that's not the way that any controller is going to spit out that same information off the shelf, so you have to write that adapter. Engineer extraordinaire, Shaurabh Singh wrote the Pocket NC adapter, installed that directly on the BeagleBone Black, which is the control board for the Pocket NC. Then the second piece you have to install is the MTConnect agent, which essentially serves up the data, so it aggregates the data into a human or machine queryable format. Then you can get to that data from another application, or you can get to it as a person. That piece is free open source software. We didn't have to write anything for that, just install it and configure it. The BeagleBone, that runs the Pocket NC, doesn't have enough computer resources to run the adapter and the machine and the agent, all at once, so we stuck that external to the Pocket NC onto a Raspberry Pi, sitting next to the machine connected via ethernet.

Stephen LaMarca: Awesome, because that was my next question. What was the purpose of the Raspberry Pi stack now, because we don't just have one Raspberry Pi, now we have four Raspberry Pis stacked on top of each other. But before I even get into the rest of them, like how does that work with the xArm, I do remember when Shaurabh was setting up MTConnect on the Pocket NC, that first time he did it, it took a week or two, and he found, and reported to us, that the Pocket NC was most similar to a particular Mazak machine. And he started with, if I remember correctly, he started with the MTConnect agent that was for that particular Mazak machine and just adapted the terms and definitions from that Mazak machine to the Pocket NC, is that correct?

Russell Waddell: You're mixing up the agent and the adapter. The agent is the HTTP server that aggregates the data and puts it on someplace that a machine can get to it. The adapter is the translation piece. I think he may have referred back to an empty connect adapter from Mazak. The nice thing about the Mazak adapter is that they have a public data stream that you can access, so just like the Linux API, he can see MTConnect data off of a Mazak machine. I don't think there's any open source of free adapters directly, but you can see the output from an adapter. It's basically just this kind of cascade of examples to follow. Mazak did one, they publicized data from it on a mazac.com website, and then looking at that and seeing how do I want my adapter to behave? I would say that the similarities stop with the adapter itself. I don't think [crosstalk 00:10:07] that's the way to it for [inaudible 00:10:10] commercial user equipment.

Stephen LaMarca: And like I said, that one took like a week or two. Once Shaurabh got MTConnect running on the Pocket NC, it seemingly only took like, as you said, an afternoon to get it up and running on the xArm. Did he do something similar to get it running with the xArm?

Russell Waddell: A couple things happened. First of all, the long time to install on the Pocket NC had more to do with IT requirements than it did with the actual adapter, so we were kind of going back and forth about static versus dynamic IP addresses that were set by the firewall that's installed. Basically, the testbed itself is on its own network. It has four Raspberry Pis like you said. It has a Pocket NC, it has a SonicWall, I think, firewall, that works as the network switch and also security hub for all that stuff. The hard part was matching up the network requirements of the network as it was configured, with the requirements of the MTConnect agent and adapter, with the networking configuration of the Pocket NC. So getting all of those things to play nicely together required back and forth with the IT department on a pretty regular basis. That was the holdup. It wasn't so much the actual development of the adapter or the installation. A lot of it was configuration and IT overhead. What was your other question? I think I forgot one thing.

Stephen LaMarca: How was that similar to set up on the xArm and what was different, better said?

Russell Waddell: Right. The purpose of installing MTConnect on a testbed is to emulate real world implementations and real world installs. See what problems there are and see how those problems can be addressed with stuff that tweaks to the MTConnect standard, or guides and references to best practices. If the parallel with the Pocket NC here... I talked about sticking the agent on a Raspberry Pi instead of on a controller. That's pretty much analogous to having an older CNC or a manual machine that doesn't have a controller on it at all, and having to use some supplemental hardware to get the MTConnect components. The layout of the system architecture where you have Pocket NC machine, adapter on machine and agent on external computing device, connected over ethernet, that architecture is specific to what you're trying to do for basically ease of connecting the stuff and getting some data spitting out. That's exactly the same process you'd go through on a factory. If you have your standard [inaudible 00:13:04] machine and you want somebody to connect data out of it. What you have to do is figure out where you got an adapter? Where are you going to install the adapter? Where are you install the agent? How are you going to connect to the agent and what's the networks actually look like? It's the same thing that we're doing. With the robot, it was essentially easier because we had better access to information on the robot. The robot manufacturer actually supplied its own API, and adjusting the adapter from the last one that Shaurabh had done, was quicker because we had a whole set of APIs already supplied by the robot builder. We basically just did the same thing we did the first time but we didn't have to do as much work to find out what the native terms were. I think the architecture for the robot is a little bit different. We're not running any of the pieces directly on the robot. We're running the adapter and the agent separate. That's one of the reasons we've got more Raspberry Pis than just the one that connected to the Pocket NC.

Stephen LaMarca: Awesome. That answers my question about the Raspberry Pi stack.

Russell Waddell: You can't forget that at least one of those is basically just full-time Minecraft.

Benjamin Moses: That explains it.

Stephen LaMarca: Awhile back, and I reported this on the podcast, I want to say a couple of months ago, awhile back Shaurabh and I actually went into the office amidst the pandemic and we recorded some programs that we ran, on both the Pocket NC and the xArm, and we recorded them so they could be looped and then streamed externally. Russ, what was the purpose of this project and how can people, like our listeners, access that data stream?

Russell Waddell: We're basically just trying to display for testing and development purposes, what data coming off MTConnect, or off an MTConnect agent, would actually look like. You can go to agent.mtconnect.org and that'll give you access to a couple of machines that are running in a machine shop at the National Institute for Standards and ¶¼ÁéÌåÓýÖ±²¥ in Gaithersburg. We're trying to basically emulate and copy what works about their system to get another source of data, so rather than just a single machine shop with a single approach to how they've configured it, we want a slightly different configuration for developers who want to create applications on MTConnect data. So showing reporting, or analytics, or trying to simulate an operation or verify a CNC program or something like that. We want the developers to have access and we also want examples for machine builders or device builders and it will show you this is what it should look like when you're done. Then finally, for customers who are basically, again, sitting in their shop, staring at a machine saying, hey, I think I might want someone to connect data," give them some idea of what that would actually look like when it's working correctly, so that they're not just sort of fumbling around in the dark. They get some numbers and data coming up on the screen and say, well, I've got data, so this must be right. It's basically just to give an example for those three categories, the end user, the software developer and the equipment builder.

Stephen LaMarca: Did you say people can actually see our data stream and this data stream off of the NIST website?

Russell Waddell: This data stream is public now. That's it. You can get there at agent.mtconnect.org. There's also a live stream from Mazak Corporation in Kentucky here in the States. I think that's mtconnect.mazaccorp.com, and that's a couple of machines in their showroom, I believe. Our stream is not live at the moment. You can get to a demo application at demo.mtconnect.org, which currently defaults to those NIST machines. Once we have our stream up and running, it'll default to the NIST machines, as well as the AMT machines. You can also stick in to see data off of whatever other machine you want. So if you already have a connection and you want to debug it, or if you want to demonstrate MTConnect to somebody, you can use that web demo. Basically plug in an IP address of a device that's on the same network and it'll display a nice tidy table of data for each of the devices on the agent at that IP address.

Stephen LaMarca: Awesome. Sweet. So we will have a stream someday. I thought [crosstalk 00:17:32]

Russell Waddell: Someday soon, it's right around the corner, and the spot to look is demo.mtconnect.org; it'll be up there as the default device reference, here in the next week or two, I think.

Benjamin Moses: Awesome, and we'll add the links in the show notes also.

Stephen LaMarca: My last question for you, Russ, what are your future plans with testbed, with respect to MTConnect? What would your next devices that you'd like to see on our testbed be?

Russell Waddell: I don't necessarily need to see a lot more devices, although if I had to pick something it would definitely be some sort of inspection equipment. I don't care if it's digital, calipers or little... Like a CMM, one of the ruggedized ones that's smaller desktop, sits next to the machine and that kind of thing. Or a 3D scanner or something like that. Just anything that covers the quality piece, because we've already got a material handling and machining, and the last piece of filling out, basically like a closed loop process, conceptually. It is, it doesn't have that inspection piece included. For us, though, it's all a proof of concept. Any material that we publish as a research paper or any findings that we push back to the MTConnect standard through the MTConnect Standards Committee, and actually put into the standard itself, any of that stuff, the testbed will serve as a small scale initial demonstration, and hopefully stoke interest in doing the same thing at a larger scale in a university setting or in a commercial or industrial setting.

Stephen LaMarca: Awesome. Well, thanks Russ. That was really helpful.

Russell Waddell: You're welcome.

Benjamin Moses: Excited to see. Hopefully we get some quality equipment and also I've been looking around to get something within our budget. The struggle's been real.

Stephen LaMarca: Metrology is so expensive.

Benjamin Moses: Yeah. We may have to-

Russell Waddell: There's still a lot of unturned ground. I mean, there's a lot of stuff that we can publicize in terms of how the pieces interact with each other, and just on the software side we can talk about security. We can talk about simulation versus real equipment. We can talk about toggling between simulation and real stuff. We can talk about kinematics and can you actually show a simulation of what we're doing? Can you model the entire thing in CAD and put a live simulation using MTConnect data. If the cost is too much, look to software at this point.

Benjamin Moses: Yeah, [inaudible 00:19:54]. That's a good call.

Stephen LaMarca: Well, we are in the middle of... We've made actually great headway in modeling the entire testbed as a whole, but you've really piqued my interest on the digital calipers. We've got a sweet pair of Mitutoyo digital calipers that are actually solar powered and whatnot, all the bells and whistles. Wonder if we could get MTConnect on that somehow. But, anyway.

Benjamin Moses: Awesome. I've got an article or two to talk about as we start winding down here. I've got an article on advanced vision for the future of safety robots, from The Robot Report. It talks about existing collaborative robot safety and potential futures using vision systems for safety on a robotic systems, mainly robotic arms. The article covers current safety standards for collaborative robots and industrial robots. The main mechanisms it talks about for current collaborative robots are monitored stop, hand guidance, power and force limiting, speed and separation monitoring. The standard they refer to is ISO/TS 15066. The article shifts to vision systems for safety and I thought that was pretty fascinating to look at basically putting a camera on a robot that's traditionally not considered safe, but using the vision system to enable it. There's three key areas, I think, that are valuable from the report, that the vision system kind of classifies different areas in the cell that the [inaudible 00:21:39] can move into. It has empty space, occupied or unknown. Based on those three classifications, the robot is allowed to move or not move based on that space. I thought it was a pretty fascinating look at the potential next step in future iterations of how robots are integrated safely into factories.

Stephen LaMarca: Yeah. I actually have a cool article. Ben, you and I are gamers and so, of course, people like us have heard that the PlayStation 5 will be released later this year, like holiday 2020. Sony's done something really cool, and it's not related to announcing anything new for the PS5, like its ray tracing capabilities or whatever, but they've actually opened their doors, so they're super secret facility that currently produces the PS4, and this is something wild. Because this is Sony's primary source of income, selling the PS4. At least they claim that. I'm not sure how true that is. This is like a super secret facility. They've never let people in. And this article, the author was actually allowed to go backstage with Sony into their PlayStation 4 factory. It's wild. I don't know if you remember that scene from the first Terminator, that's towards the end of the movie where they're running through this huge factory, but it looks like that. It looks like there's not a lot of place to step because it looks fully automated. There's not a lot of human interaction in this place. It also gets pretty deep into the design of the PS4 on how every component inside that little black case has a purpose. There's no waste. It's a totally lean product. It's just wild. I would expect to see three to seven robot arms working on like a car through an assembling line, but there's one scene that has three robot arms reaching towards one PS4 as it's going through the assembly lion, and it's wild because they're pretty big robots in this one picture, and the PlayStation 4 is pretty small, so yeah.

Benjamin Moses: Yeah, and that's a fascinating look. Consumer electronics at that kind of scale is a fascinating look. I remember a couple years ago, Steam released a controller for their system. They talked about their automated cell and the manufacturing process, and one of the interesting things that they talked about was the flexibility of their end of arm tooling for their automation equipment, being able to switch over production lines to different designs and their ability to change over. It was a fascinating look.

Stephen LaMarca: Yeah. I also really like one of the pictures that they have is just this massive bin of flat ribbon cables, all of the exact same flat ribbon cable. It's just like, that's how much they're going through in a day of manufacturing. But, anyway.

Benjamin Moses: Yeah, I do like seeing final end assembly manufacturing. I was at Spirit AeroSystems where they did final assembly for Boeing aircraft, and it's in these massive equipment. I mean, the inventory room, inventory stuff that they bring in for supplies, is amazing to watch and how they manage, so the whole ecosystem of final assemblies are underrated. It's great to watch. Awesome. Thanks. This is a really great episode. I'm glad we covered everything on the testbed. Got a couple of articles in. It's a wrap up-

Stephen LaMarca: I'm glad Russ could join us.

Benjamin Moses: Absolutely. Thanks for joining us today, Russ.

Russell Waddell: You're welcome.

Benjamin Moses: Today's episode was sponsored by IMTS. Checkout imts.com/supplychain for more information about rebuilding supply chain. I recommend the interview with Roy Gentry from Mazak and in the article on ReBuilding the Supply Chain: How Did We Get Here? Steve, where can they find more info about us?

Stephen LaMarca: You can sign up for the weekly tech report at amtnews.org/subscribe, and you can find more from me at the Amateur Machinist blog at swarthysteve.blogspot.net. Lastly, you can find more of us and our podcast by searching AMT Tech Trends on your favorite podcast app.

Benjamin Moses: Awesome. That was great. Thanks guys.

Stephen LaMarca: Bye everybody.

Benjamin Moses: Bye.