Okay. Hello, everyone. Thank you very much for attending our session this morning or afternoon or whatever time it happens to be where you are. My name is Mark Thorin. I am a systems design engineer with Analog Devices System Development Group. My colleague, Brandon Bushy, will be around for the Q&A after the session here. The title of our session is Connected Analog Instrumentation with the Raspberry Pi. And we'll get our little pointer here and we'll get started. Okay. So first, some thoughts on the motivation behind this presentation and why Analog Devices is so interested in using the Raspberry Pi. And it really boils down to bridging gaps between skill sets. And what I mean by that is giving a hardware engineer or a mixed signal engineer the ability to take advantage of Linux infrastructure, Linux device drivers and all of the flexibility and niceties that come along with a Linux-based system. And on the hardware side of things, using standard hardware to allow software developers to write device drivers, debug software examples without having to worry about hardware construction, without having to worry about signal integrity or power integrity issues. Using a common platform like Raspberry Pi and this little adapter board here allows us to replicate systems on opposite corners of the globe very easily and have confidence that the hardware is similar and matches up. It takes a lot of different skill sets to design complicated systems and complicated boxes like kernel developers or power application engineers, data converter application engineers. We want all of these people to be on the same page, both in terms of software and in terms of software and in terms of hardware. And then I've got another skill set here, Hacker slash Basic Example Developer and that is where your presenter at the moment skill set squarely lies. And we'll leave off with a couple of bold statements here that life is too short to fight with flaky hardware. When I'm working with these sorts of things, I like to bolt everything together whenever possible, use robust connectors so that I don't have to worry about things coming apart when I'm working on them. And similarly, on the software side, life is too short to fight with ad hoc software. So as a hardware guy, I can write myself a little hack together driver to talk to a data converter, but I don't trust it fully and I certainly wouldn't want to put it into a customer's hands. And using a mainline Linux kernel driver is a way for me to develop applications in a way that I can pass them to my customer with confidence. So what did things look like before analog devices started looking at the Raspberry Pi? So I actually joined analog devices through the linear technology merger and when that was announced, I spent quite a bit of time looking over various pages on the analog devices wiki to try to get a feel for how they were doing their software and driver support. And I came across a lot of pages that had pictures like this on it. So very detailed description of a software driver followed by setup and a piece of example code and then, well, what hardware setup did we use? This was typically all that was shown was the evaluation board connected up to some random Linux platform. And for a Linux developer, that's not a big deal.  But for a hardware guy, that's a pretty daunting task. It involves a lot of skills that we don't necessarily have. So you can see already that some commonality would be a big advantage here. Just a little related comment here that a lot of these early drivers were done in user space, which is very flexible. You can do whatever you want, but of course there's no standard and no reuse and no peer review. So most of what we'll be talking about today or all of it I should say are proper kernel space drivers for performance reasons and for the requisite peer review required for upstreaming. And this link is to the page where I think I got this middle photograph from. Okay, so when did the Raspberry Pi start to enter the picture? So I kept digging and digging and eventually came across this example. The wiki page for this is dated 2012. So what is that, eight years ago? And I was even playing with the first Raspberry Pi at that time. I forget exactly what I was doing with this, but it seemed like a neat thing and that I might want to have one on my workbench here. And this example was for the ADXL 345. So first instance that I could find where we're using a Raspberry Pi for showing off a device, an accelerometer in this case. So why Raspberry Pi? Why not one of those other platforms in from those previous pictures there? So this is generally not a good thing to say to a kid, but in our case it's perfectly appropriate to say because all your friends are doing it. This chart is from the EE Times Embedded Market Survey, which is a fantastic document for sort of getting a feel for what hardware and software environments your customers and your colleagues are using. And so if we look at what boards are being used in industry, of course, complicated custom designs require custom platforms, which is the most prevalent. Other proprietary designs. And then the first common platform that pops up is Arduino, which is just amazing for how simple and cheap they are. And probably that's why they're so popular is because there's such a rich sort of maker space movement behind it. But of course, Arduino is not appropriate for Linux-based systems. The first platform that does show up is Raspberry Pi. And so, you know, 16, 17% of those survey were using the Raspberry Pi followed by things like Nucleo and Beaglebone down here as well. So Raspberry Pi, very popular, very sort of rich community support. So that is a natural choice for us to use for our development. And so that begs the question, why not just use a PC? Raspberry Pi is just a little baby computer. I can run Linux on a PC. And the answer there is because of the interfaces that it provides. So a PC will typically have USB ports, HDMI ports, things like that. But nothing really appropriate for direct connection to an integrated circuit device that would typically have an I2C interface or serial peripheral interface or SPI. Whereas the Raspberry Pi has a direct connection to all of those interfaces there. And just a little photograph here, wondering if anyone, any of the attendees here, have had the pleasure or displeasure of writing a device driver in quotes to bit-bang signals on a PC's parallel port or even a serial port. When I joined Linear Technology, there were quite a few demo boards that used serial and parallel ports, often with software that writes directly to the hardware registers. So that was round about 2,000 time frame or so. That did work, but of course it's not very robust and certainly not maintainable in the long run. Okay, so that's why we're using, that's why we're not using a PC. So that was the brief look at the hardware. On the software side of things, the most, if not all of the examples that we will be talking about here, make use of the Linux IIO framework or industrial input output framework. And so this is a software framework for converter-ish devices. So not only analog to digital and digital to analog converters, but things like gyroscopes and accelerometers, current monitoring devices, light meters, and things of that nature. Devices that either produce or consume discrete samples of data or streams of data, time-sensitive streams of data. And this slide purposely has no analog devices content on it. This is an industry standard. It's not an ADI standard, although we were involved in its development and are involved in its maintenance. So a little screenshot here from kernel.org, showing a couple of analog devices drivers, as well as some drivers from our competitors. And a little block diagram of a typical IIO subsystem. And this is from ST Micro. So again, any work that you put into working through the examples we'll show here, of course, we'd love for you to use analog devices parts, but it also carries over to other parts within the industry from other manufacturers. Okay, so associated with IIO, a couple of other terms and definitions here. So lib IIO is a software library or a software API to IIO-type devices. So it's a native C library, but it does have bindings for MATLAB and C-Sharp. I believe there's also, there's definitely Python, even LabView and GNU radio as well. So it's a very cross-platform, cross-language library that's quite flexible. IIOD is a little program, and I guess we'll flip over to this block diagram here. This is a program that reflects IIO devices from a hardware platform over a network interface. And this is really useful for both debug and developing application software. So this allows us, in the case of this diagram here, I can have some devices, some data converters that are connected to my Raspberry Pi, and I don't have to run any software on my Raspberry Pi. I can do all my development in a comfortable IDE on my Windows or Mac or Linux box. And I can talk to that converter device as if I were running locally. And then this can actually be deployed in production. So you may have a case where you've got a hardware device that always has application software running on a remote machine. Or you might have a little client application that does run on the Raspberry Pi. So picture a data logger where the Raspberry Pi is out in the middle of nowhere collecting temperature or pressure samples or something like that. My application software might just read those samples and dump them to an SD card or something like that. So it's a quite a flexible, it provides flexibility in how you communicate and connect with your devices. A client application, fairly straightforward. It's whatever, it's your end application thing. And I guess the IIOD server is an example of a client application. And then if your client application is written in Python or if you're developing in Python, we'll talk in a little bit about a software library called Pi-A-D-I-I-I-O or affectionately called Pi-O-D. Okay, so sort of a 30,000 foot or a 10,000 meter look at the hardware setup, a typical hardware setup would, of course, involve a Raspberry Pi with some hardware connection to a data converter-ish device, in this case an AD-71-24, which is an ADC. And then the Raspberry Pi, maybe I don't run any software locally, but if it's running this IIOD server, then I can connect to my remote PC over sort of any ethernet connection or any network connection, whether it's wireless or wired, it doesn't really matter. And I can develop like this. I can write code using lib.io on this machine and talk to my end device here. If I want to generate test signals for my hardware, I might use something like the AD-ALM2000. This is a little oscilloscope slash signal generator digital pattern generator slash logic analyzer device, so quite flexible. I can use it to generate test signals for my analog to digital converter, or I can use it to read signals from an analog to digital converter. So on this slide, I've got basically a fully functional workbench for developing mixed signal applications. And of course, the Raspberry Pi is a full-blown computer all by itself, so I can get rid of that external computer entirely. I can develop software on the Raspberry Pi. I do a lot of work in Python, and there's a super cute little IDE called Fani that ships with most of Raspbian distributions, and so that is perfectly appropriate for developing simple application code. And this, the AD-ALM2000 will also interface directly to the Raspberry Pi, so I can get rid of that client computer entirely and do everything on my Pi. Okay, so what distribution should we run on our Raspberry Pi? So Raspbian is sort of the standard distribution that most people get started with on Raspberry Pi, and we're no different. We started out doing our initial development with Raspberry Pi on Raspbian, but it didn't take too long before we realized that, hey, there's an awful lot of other stuff we have to load onto Raspbian in order for it to do the job for us. So we started a project called ADI-Cyberlinux, and so this is a fork of Raspbian that we're developing, and what it has is all appropriate Linux device drivers for all analog devices and linear technology parts. They're all enabled in the kernel, so if I get a new part and it has a Linux driver, I don't have to go through that trouble of recompiling the kernel. Again, not a big deal for a software guru. It's a big deal for a guy like me. And let's see. So we've got the kernel recompiled along with that. We also found that there were a lot of software libraries that we would have to go in and rebuild and reinstall every time. So we've built that into the distribution. So this is lib.io along with its Python bindings, along with its C bindings. Lib.m2k is a library for communicating with this little multifunctional instruments, and pyadio or piodi. So the Python interface to IIO devices is also included. We've also got Canoe Radio. So if you want to play around with some communication applications, then that's built into the distribution. IIO oscilloscope is a little debug tool that's super useful for most of this stuff as well. Documentation and instructions are up on wiki.analog.com. And of course, this is fully open. So we are not going to enable drivers for our competitors parts, but there's nothing stopping you from building your own distribution that does include support for those devices. OK, let's head towards an experiment here. So the first example we'll look at is a connected AD7124, 24-bit Sigma Delta converter. And in fact, I've got the converter up here as well. And so what our objective here is to start taking readings from this converter so that we can start developing applications, full applications, whether it's a voltmeter or a thermocouple meter or a barometric pressure meter or something like that. So the hardware connections are quite straightforward. It's the Raspberry Pi with either jumper wires or an adapter, like this little adapter from Digilent here. So it's a very simple software setup. And our first test signal for this and a very useful first test signal for any ADD converter is either a short circuit or a very small input voltage. So in our case, we have a, what is this, a 200 to 1 divider. So we impose just a couple of millivolts signal across our first analog input channel. And so that gives us something to look at. In the old days, with a 12-bit converter, we would expect to see no codes of Flickr, either 0 or 1 or some small number of codes. But with something like a 24-bit Sigma Delta, we always expect to see some level of noise at the input because our quantization noise is so low. And so let's start digging in and take a look at that. But first, we'll talk about the software interface. So we are going to, we're going to talk to our converter through Python, through this Pioti or Pi-ADIO interface. And just this description from the read me on GitHub really says it all. It's a Python abstraction module for ADI hardware to make them easier to use. So lib.io is actually not that hard to use, but there's a lot of boilerplate. There's establishing communication with your part, setting up channels and things of that nature. And Pi-ADIO just takes care of that. And there's an example of that shown over here to the right. So the AD93.61 is a highly sophisticated software-defined radio chip. And to grab a chunk of data from that device through Pioti is three lines of code. We import the library, we instantiate the device, and then we pull data out of it. Of course, there's a lot of knobs to tweak and a lot of settings to change as well to get it to operate exactly how you want to. But fundamentally connecting to it and getting to Hello World is three lines of code, not counting comments. And of course, this is pre-installed on ADI CyberLinux, and it's available through PIPI and Kanda as well. So it's very easy to install. And so for the AD7124, this precise low-speed precision converter, this is what that interface looks like. And let's dwell on this for a little bit. So the first thing we do, of course, is open import our library. Then we establish a connection to the device. So I instantiate an instance of an AD7124. And the IIO context, I open in this case as an IP address. So it looks like what I was doing here, this code was actually running on my remote Windows computer. And the 7124 was connected to my Raspberry Pi either across my lab or maybe in the office or across the world. It doesn't really matter. As long as I have a network connection to it. And what I put here can vary depending on where you are. I can give it, if I want to talk locally, if I'm running this code on the Raspberry Pi, then I can tell it to connect to the local back end. Or I can tell it to connect to local host. So that still communicates through the IIO daemon, but it's local. It never leaves the machine. And this is super useful if you don't have root privileges. Because you can read from any of these devices, but writing requires root privileges. So talking through local host is a nice way of doing that. And then reading data and configuring the part is, again, super simple. So this part has a built-in programmable gain amplifier. So we set the gain, in our case, to its minimum value. And then it also has a variable oversample ratio. So I can adjust the speed and noise level of the converter as well. So in this case, I'm setting it to 128 samples per second. I can read a single raw value of data, or I can read some number of buffered data points. So continuous data points taken from the converter if I'd like to analyze a waveform rather than collect a single sample from a temperature sensor or something like that. And I'll make the point here is that I set a really long time out for this, because this converter is very slow. It's very slow, but also very low noise. And finally, just like with the software-defined radio chip, I collect my data. OK, and here's what the output of that script looks like, or what the output of that converter looks like. So here is an example that takes 1,024 samples from that circuit that we had set up. So a very small input voltage. We expect to see nothing but a small offset, plus the noise of the data converter itself. And so when I first wrote this script, I was all happy that I was getting data back from it. And I said, well, let's plot this and see what happens. And down here, this is the first set of data that I captured from this thing. It wandered all over the place. And of course, I think to myself, what went wrong is do I have a hardware issue, is something all messed up, or am I on the right track? And then it dawned on me that, hey, this thing is still warming up. So when you first apply power to a 24-bit Sigma Delta, the Sigma Delta itself, as well as its internal reference, everything is warming up and coming in and stabilizing thermally. And so I let it sit for a few minutes and eventually things start to calm down a little bit, but still wandering a bit. And so finally, I wrapped it up in anti-static bubble wrap and just let it sit for a couple hours. And then I start to approach data sheet noise levels. And that's what's shown down here. So if I take that data set, take the standard deviation, I get a number that matches up very nicely to the noise number in the data sheet of the 7124. So the point of this is with a very simple hardware setup and a very simple software setup enabled by the Raspberry Pi, I can start measuring the performance of this really high-tech converter. And I'm all set up to go in and develop useful applications. So it's not a stretch to go from this script to taking in a voltage from a thermocouple, applying a polynomial, calculating temperature, or taking a small voltage from a strain gauge and calculating force. So I've really not only am I set up for application development, but I can also really go in and make sure that the thing is meeting its data sheets backs all very, very easily. Okay, so let's talk about going the other direction. So that was a 24-bit analog to digital converter. So another example of some connected analog is this circuit note 531 that is in development. And this is a one part per million linear digital to analog converter. And what's shown in this plot here is the departure from a perfect straight line. So in other words, I'm creating an output voltage from negative five volts to positive five volts, counting one count at a time. And I expect to see a perfectly straight line. The departure from that line is on the order of one part per million. So this is the error in that line exaggerated quite a bit here. So again, now I have the ability to generate extremely precise DC voltages. So if I was building a piece of test equipment like a sensor calibrator or something of that nature or even just a precision voltage box, I've now got the ability to do that very, very easily. And of course, this plugs into that same adapter that we're using here. So super easy to connect up with when you're using standard hardware platforms. Okay, and it doesn't stop there. So there's quite a few parts that are either released already, I should say parts with little modules like this that are either in development or released already. Even if not, it's still fairly straightforward to wire a Raspberry Pi up to some other evaluation board. Just keep your wires short, keep everything grounded well and your setup for success. But some examples here are this ADXRS290 gyroscope. We've got the AD5593 here, which is a little eight channel, eight channels of D to A, eight channels of A to D, as well as digital GPIO. So a really flexible part for tweaking voltages across a large system board of some sort. And one thing worth mentioning is that we are working on a variant of IIO that runs on embedded targets. So that is called Tiny IAOD. And the idea there is if I'm, what that does for us is if I'm developing for an embedded application, I can have two versions of my target. I can have a Raspberry Pi Linux based version and an embedded version. I can develop software on my remote host and it doesn't know the difference. So again, just another tool in our toolbox for developing applications, both hardware and software. Okay, so let's move away from small, cute and precise onto some higher speed stuff here. And the example that we'll talk about is a signal generator, like a radio frequency signal generator. So this is something that you might use in a communication setup to generate like a local oscillator signal for a radio application or an actual radio signal. So maybe I generate a tone at a gigahertz and modulate the amplitude or modulate the frequency. So super handy device. They show up in labs all over the place here. They also get integrated into capital test equipment. So if I'm like analog devices as an IC manufacturer, our test setup might involve a stack of these signal generators in a 19 inch rack setup of some sort here. So the point being is that signal generator has lots of different use cases. They show up everywhere. And of course, analog devices doesn't traditionally make boxes like this. We make enabling technology that goes into these boxes. So what you're paying for when you buy a box like this is the user interface, the software interface, and more often than not protection. So this thing, these tend to be an awful lot more robust than just an integrated circuit on a circuit board there. So it's about the packaging. So how are we going to enable companies that make boxes like this to play with our parts quickly and easily? And I guess a follow on to that is how would we enable someone that was building a test setup to build a minimal test setup without having to go and purchase a full blown benchtop signal generator. And here's an example of a device that can do that in some cases, this AD 9166. So this is a DC to nine gigahertz vector signal generator. So it's actually, it has a digital to analog converter core. It has a very high speed GESD 204B data interface for baseband modulation data, but it also has internal numerically controlled oscillators. So at the price point for this part, for this DAC, it actually makes sense to put it down on a board and just leave the data interface disconnected. So don't bother sending any data to it, just use it as a sine wave generator. And that's exactly what we're doing with the circuit note 511. And we're using a Raspberry Pi to control it. And so here's what that looks like in real life. So it's a Raspberry Pi hat form factor board with a clocking solution, the DAC itself. And again, it has a very wide, very high speed GESD 204B converter interface that is completely disconnected on this board. It's just dangling in the breeze. But we do communicate with all these devices through the Raspberry Pi's spy port. And again, you can control it locally if you connect a HDMI monitor slash USB connector. And that's what we're showing over here. And of course, it's running ADI Kuiper Linux. And of course, all of the drivers for these devices are built into the Kuiper Linux kernel. The PLL driver is mainlined and the AD 9166 driver, the upstreaming is in process. Okay, so another shot of the hardware setup, a little close up here, so we've got the DAC and this is not a low power part, dissipates a few watts when it's running at full speed here. So it requires a heat sink. And this is the IAO oscilloscope interface to that part. So again, this is a simple GUI. The objective of this GUI is not, it's not really an end application. It's something to allow you to quickly and easily diddle knobs once you get your hardware all set up. So it's basically great for signs of life. And you can see that we can enter in a sampling frequency and then what output frequency do we want as well and enable and disable the output. Okay, so once you get bored with the, once you get bored with the GUI because it's not fun to sit there and poke buttons all afternoon, of course, you can flip over to a controlling things programmatically. So here, again, we're using that Pioti interface to connect to our CN 511 device. We set up our sample clock, we set up our output frequency. So now we have the ability to control this thing programmatically. So very powerful, powerful in a benchtop environment, even more powerful in an automated test environment where I basically have to control everything programmatically. So another example of this. So taking a step back into the slow, powerful world here is the circuit node 508. So this is a digitized power supply. And in fact, it uses the AD 7124 ADC to measure all kinds of stuff. We measure the, looking at the diagram here, we use that converter to measure the temperature of the onboard voltage regulators. We measure input voltages, output voltages, output current. Basically everything that can be measured is measured with the AD 7124. And the output voltage is controlled with a 16-bit D to A converter. So again, a super flexible 75-watt power supply and it's all controlled by a Raspberry Pi zero. Okay, so we mentioned earlier on that we're using the Raspberry Pi because of the physical interfaces it provides, the SPI interface, the i-squared C interface, and parallel GPIO. So what happens, so where do we run into the, where's the Raspberry Pi, where does it become a limiting factor? And it becomes a limiting factor as our data interfaces grow in speed, grow in width, and where timing requirements kick in. And so once you reach that point, then you basically have to go to a programmable logic solution of some sort. And the ADALM Pluto is a perfect example of that. So this is a software-defined radio transceiver chip that is basically connected up to a zinc FPGA. There is not a lot of signal processing going on in the zinc FPGA. So this just serves to swallow the data from the AD 9363 or send data to it. It manages data transfer between Linux user space and the FPGA and eventually to the transceiver chip itself. And it provides that same clean IIO interface back to a host PC. And I'll make a point here. We've said several times that the Raspberry Pi has SPI interfaces on it. Beware of that term. There are lots of data converters that say SPI very prominently on the front page of the datasheet. But the Raspberry Pi does not do precise timing. So even at a few thousand samples per second, you're gonna have trouble maintaining tight timing, which impacts your analog performance at some point. So just something to be aware of here. And then the final thought on this page is that this is not a Raspberry Pi, but boy, the software interface looks very, very similar to everything that we've talked about so far. Okay, but that doesn't mean that the Raspberry Pi isn't a little bit useful for in applications like this. And so this is an example that we put together for the GRCON conference this year. And it is an AM radio to FM radio translator. So we were, again, we're using the ADALM Pluto, that device that we showed on the previous board and the ADALM 2000. So the same device that we use to generate signals for our low-speed converter, we're using the ADALM 2000 to actually digitize a signal at 455 kilohertz. So we digitize at a high rate. We do all of that high-speed processing or high-speed data capture in programmable logic. And then we transfer that to our Raspberry Pi over USB. We do some processing and then we send it back out to our ADALM Pluto. So again, the reason we're using Raspberry Pi here is because it's convenient. You could use a Linux box, but we've included GNU radio and interfaces to both the M2K and the Pluto along with ADI Kuiper Linux. So all of the, all the software tools are built in.  So we've got an AM radio educational kit here. We are sniffing, we're picking off the intermediate frequency. We are digitizing that with our ADALM 2000. We bring that into our Raspberry Pi 4 in this case where we do our processing, send out to modulate the baseband data as FM and send out to our ADALM Pluto. So again, making full, everything is doing, is doing what it does best. So, and of course the Raspberry Pi is doing, is doing the processing. So we send out and we're using a little Hello Kitty FM radio to receive our tone back. And this is up on our GRCon GitHub page there, this example, so we can provide links up to this if anyone finds this interesting. Okay, so this, hopefully it sounded like a lot of fun. It certainly was fun putting together this presentation and developing these examples. There are a couple of publicly available tutorials and walkthroughs here. The first one is called, we call it the IIO Intro Toolbox, Toolbox and Tutorial. And this is actually the hardware associated with that tutorial. So it goes through the process of hooking up an ADXL345 accelerometer to a Raspberry Pi, configuring device trees, bringing up Python, communicating with the device. So it's really a great sort of boot camp for all of these topics. The AD7124 Precision Lab, where we go through the noise analysis, that is the Precision ADC Toolbox, also up on wiki.analog.com. And then finally, for a cheap non-analog devices example, there's a great tutorial that was one of the first ones that I followed on bringing up an LM75 temperature sensor. So this is a very common temperature sensor that's used on hard drives and motherboards and all that. And so it's a very nice write up on bringing up that parts driver and its device tree. And I should point out that the LM75 driver is enabled in ADI Kuiper Linux. I requested that one for this reason. And then finally, a little reading material here. This is an article on ADI's, an ADI perspective on free and open source software, especially things like Linux and IIO. Okay, so some acknowledgments here. So I was your presenter this afternoon, but really the real work was done by an awful lot of different folks out here. And the best way to give credit or the best way to see who that is is to look at the contributors on GitHub, in particular for Lib IIO, Pioti, ADI Kuiper Gen. And I'll point out, in particular, Merchicaprioru, Kuiper Linux is his blood, sweat and tears here. He put a lot of time into that. Travis Collins developed Pioti, the folks that developed the hardware here, Mahai, Urbe, and Tricia. And Adrian Sucu is the software manager behind Lib M2K. So all of these guys and girls are very helpful. They, and responsive on the engineer zone and as well as GitHub. Okay, and that's our presentation here. And I guess the final thought here is I really hope that this event is in person in 2021. It'd be great to run some hands-on workshops with this stuff. Okay, thank you very much.


There are various ways of lifting irregularly shaped items. While the most common lifting devices in robotic arms are flat-surfaced grippers, these types of devices are most efficient with flat-surfaced workpieces and are not nearly as efficient with round, cylindrical, or other irregularly shaped items. When used inappropriately, flat-surfaced grippers can either crush the workpiece or drop a workpiece due to inefficient grip, especially in high-speed operations. A pneumatic mandrel lifting device is used to lift objects that are hollow. The gripping action of a mandrel lift is applied to the interior of the workpiece. Low-pressure air is channeled to a chamber behind a diaphragm. The diaphragm then expands until it is firmly gripping the interior of the workpiece. To free the workpiece, the air is released from the diaphragm, which then deflates, allowing the robot to relinquish the item. Pneumatic pin lifting devices work similarly to mandrel lifting devices. The main difference is the location of the gripping action of the tool. With a pin lifting device, the gripping action occurs on the outside of the part. As the tool surrounds the workpiece, low-pressure compressed air is used to expand the diaphragm. This ensures a snug grip on the exterior of the workpiece. To free the workpiece, the pressurized air is released, which deflates the diaphragm and allows the workpiece to drop freely. The single disadvantage of these pneumatic lifting devices are the limits on the payload or weight which they can lift. However, these flexible pneumatic devices have many advantages, including their light weight, their ability to grip parts without damaging surfaces, and their ability to grip parts with irregular shapes.


We made, I did a really poor job getting us ready to go. I feel awful for our fans. Everybody showed up today. We'll do a better job at games, not going to define us. It's a long season to go, but I certainly didn't do a good job getting us ready to go today. Just that, it's a long season. Nothing matters, but what goes on there, we got to improve. We've been in worse spots. It's week one, we got 16 games to go. And a hats off to Philly. They did a great job coming in here. They took advantage of situational football. They scored in the red zone. We didn't, and then we got down, we played right in their hands. So that's what happens when you get down multiple sessions and you get obvious exactly what happened and what you saw at the end there. Yeah, I mean, the first one, I think we were first in five. Tried to plug a run in there. Went for a quick play action right there. Didn't get it clearly. And then third down, they got a little bit of pressure there, but that's what happens. Getting the third down, you're obvious. I got to do a better job. I got to go look at the film. I don't want to overreact, but that's what it looked like on the field. Second one down there, D-Led, you make every mistake.  So if we had caught it, it would have been ruled back. Those are self-inflicted wounds. And that's where I'm really, I got to do a better job there, D-Led. Sure, it's bad football. Right. Yeah, well, no, I was talking about the one we got down to two, and we kept getting backed up at the end of the first quarter, I believe, going in the second. So hats off to the Eagles. Like I said, the yards don't matter.  It changes the momentum of the game. And right before the half, the one you're talking about, yeah, we get the false start. We're trying to get it backed up to get into a drive and be smart there, because they get the ball coming out in the second half.  When you're backed up, they won the field position battle. You name it right down the list. And credit to Nick and their staff and really their players. And like I said, we didn't win that situation. You get the false start. We don't get the first down. We gave the defense a short field. They're fighting, and they scored right before the half.  I mean, when nobody's in this league, it's coaching to hold. That doesn't happen. And those are fouls within the play of the game. I got to go back and look why those ones late, what we need to do better. Again, I don't want to overreact to that. The officials have a hard job. I don't ever blame them for anything. It's just, I got to see what we're doing to make sure, if there's something obvious, that we made a mistake there. We're just dropping back, and they're playing his own coverage, and guys are going over route. So I don't know. I had to look at that, Michael. It's the stuff pre-snapped, the false starts, the things you try to pride yourself on. And we do that in a situation.  You don't get them on. You give them a short field. You get down into the two-yard line, and you have a legal formation. I've got to clean that up. So yeah, I do put that on me.  So I got to look at the film. Michael, I got to evaluate what we're doing just to make sure these guys understand. I mean, when we're getting fatigued, like, we just got to do the basics. The narrative you're going with about mat and deep shots, no, the game plan was to not let what happened at the end of the game when you get obvious, and you've got to play obvious football, and that's a damn good front. I wasn't just at there pumping their tires. It's the truth. And when you get obvious, it's hard. And then so you look at the stat line and D-led you're probably telling me what would give them three sacks late. Yeah, so you're playing three quarters in our two-position game. Certainly not pretty, but when you got obvious, you're playing right into their hand, and that's what happened. And that's what I was trying to avoid all game. And I thought we did a pretty decent job in the first half. He was pretty clean. And we obviously didn't score the touchdowns, which led us, we got down too many possessions. And that's on the offense. I mean, the defense out there fighting, and we didn't put any stress on them. No, they played there and that's not a shot at John or you know exactly what they're going to do.  And again, when you get behind the sticks and you're not moving the ball, you're playing right in their hands. And that's what happened. Yeah, I think we had four possessions right in the first half. So we had two go down. We only come away with six points, hats off to them. And then the one before the last one that D-led was talking about, yeah, we got to go back and look at that one. That was obviously we needed to get something going there. It's about scoring touchdowns in this league and about eliminating self-inflicted wounds. And we didn't do a good enough job. And I've got to do a better job. So, and then the one before the half, you're trying to play the game there. You know, you want to get going on a drive, you're backed up, but Jocelyn, I want to go three and out in 10 seconds and give them the ball back. So we had the penalty, we didn't convert and you saw the end result. They scored a touchdown and then we had another penalty on the extra point. That's the stuff, right? I mean, those are subtle things and then they ended up going for two. And that's completely on us. But that's what happened. They would have put heat on anybody at the end of that game when you're down multiple possessions like that. That's not our excuse. That's worth the credit to them.  I mean, it's a good front. Played right in their hands. We go with the rest of the team. We got to get better. I got to get better. So I think that one's pretty obvious. You know, I got to go back and look at the film. Certainly, he didn't look like they were doing anything for him the first couple of drives. But as the game wore on, you know, whether it was jailing or anybody, we didn't hold up at the end when it was obvious. Yeah, well, again, you're in the heat of the game. My opinion didn't matter. I was just pretty much asking what they're seeing up there. So, you know, it's a scoring play. So it doesn't matter whether you're under two minutes or not, they're gonna look at it and confirm it. And so, again, they got a hard job. I was trying to ask him what they were looking at. It's pretty much what I was doing. Yes, pretty much. I'm gonna evaluate everything. Jeff, whether we win or lose, you know, we got to turn around. We got 16 more of these things. Like I said, I've been in worse situations. The narratives right themselves. We have won. You know, you can write the narratives, you lose. Either one of them are true because we got a long journey ahead of us and we got to get better. So where I think I'm frustrated is I got to evaluate what I'm doing, whether it's coaching, messaging, about let's get lined up and not when you're on the two-yard line getting a legal formation. That's the stuff that really concerns me. So whatever you feel like there's there, Jeff, but that's just the truth and that's come from me. I'm not trying to be a martyr here. That's my job as head coach. I'm responsible for the entire team. When you go out there and you have those self-inflicted wounds right there, that's a problem we want. Look, if we had won or lost, you always worry about guys believing and stuff that's not true because it's such a hard journey. And if we don't come in tomorrow and correct what needs to be corrected in the film and we don't turn around and get ready for Tampa who's had a couple of days head start on us, then we got issues. And that would be the same whether you win or lose and it's gonna be my approach every Monday or I guess Friday after we play in New England. And that's the name of this game. You've got to improve. And so if you want to send a message, we're not gonna be the team today whether we won or lost that we're gonna be in October, November and December. And so we've got to get better and I gotta do better. I'd have to look at the film.