John tells me that the latest and greatest flap handle ClearNav remote caddy version is alive and doing well in his glider. The flap grip section fits over the metal flap control handle nicely, and the redesigned remote caddy section with its beefed-up quarter-turn fastener seems to be holding up OK so far. The ‘caddy garage’ piece also seems to be working to hold the remote caddy in an out of the way place when not in use, allowing John to enter/exit the glider without worrying about damaging the caddy or breaking a cable. Only time will tell, but for now it looks like I might be DONE!!!
In our last episode of the Flap Handle Follies, I was sure I had all the bases covered.
- Larger set-screws in grip – check!
- 1/4 turn locking latch connecting flap grip to remote caddy assembly – check!
- Rotatable remote caddy with spring-plunger detent every 10 degrees – check!
Unfortunately, one essential item for success with this version was missing from my checklist, and its absence spelled doom:
- Non-gorilla pilot – check!
A few days after sending the latest version to John, I got an email with some photos and suggestions, and a few days after that I got my folded/stapled/mutilated flap handle assembly back – boy was I embarrassed! What I had thought was a *brilliant* solution to a problem turned out to be not-so-brilliant when exposed to a pilot who expected things to go together in a particular way. I had designed the 1/4 turn locking mechanism so the locking direction was opposite the normal “righty-tighty” direction because by doing so, the pilot’s normal thumb position on the remote caddy tended to hold the caddy locked onto the flap grip, as opposed to tending to unlock it. Unfortunately, I had forgotten to mention this feat of brilliance to my friend, who expected everything to conform to normal lock/unlock conventions – oops!
Ah, well – it wasn’t a total failure, because we learned some things in the process:
- The 3-piece assembly (flap grip, grip-to-caddy converter, caddy) was too long; John couldn’t reach the CN remote’s buttons with his thumb while his hand was comfortably placed on the flap grip.
- The 1/4-turn locking mechanism was way too fragile (jokes about gorilla pilots notwithstanding)
- The dimensions of the rectangular slot in the grip piece seemed to be just about right.
So, back to the drawing board yet again. hunting through the forest of design possibilities for just the right combination.
- Minimize or eliminate the grip-to-caddy converter to reduce overall length
- Enlarge/strengthen the 1/4-turn locking mechanism (but keep the opposite direction actuation)
Minimizing or eliminating the converter piece required that I drop the caddy rotation feature. This was kind of overkill anyway, as John had marked the correct (for him) rotation much earlier in the game; I was trying to generalize his preference into something other pilots could use as well. I just needed to think about the rotation feature as something ‘baked in’ to the design, rather than something pilot-adjustable.
Enlarging/Strengthening the 1/4-turn locking mechanism shouldn’t be too much trouble, as the latch parts were available in their own separate design files, so a simple scaling operation should do the trick there. The only limitation on size being that the latching mechanism has to fit into the top of the flap grip and the bottom of the converter piece.
Based on my now extensive experience with printing parts on my PrintrBot, I also added the requirement that each part be printable in a way that preserves the quality of the mating surfaces. I have come to understand that there is a right way and a wrong way to print parts; the right way result in very clean and smooth mating surfaces, while the wrong way results in ugly, bumpy surfaces that no amount of sanding can make right. Fortunately, the combination of careful design and clever positioning of the part on the print plate seems (so far) to be effective. The trick here is to make sure that parts are positioned so the mating surfaces are either perfectly parallel or perfectly perpendicular to the print plate; in either orientation the result is nice, clean surfaces. In the case of the converter part, the mating surfaces aren’t parallel to each other, so it was placed vertically on the print plate so the larger mating surface (remote caddy interface) was perpendicular to the print plate, and the smaller (flap grip) surface was tilted 20 degrees from the vertical. Near-vertical surfaces also print very well, so this resulted in both mating surfaces printing nicely, but the cost was a much longer printing time (2 -3 hours vs about 15 minutes!).
In the previous version, the thickness of the grip-to-caddy converter part was driven by the need for the caddy to rotate on the converter-to-caddy mating surface, which required that the converter have a hole deep enough to accommodate a reasonably sized axle post on the caddy part. Eliminating the rotation feature allowed me to eliminate much of this thickness. I still had the following requirements:
- The caddy has to be rotated about 25 degrees CCW with respect to the fore-and-aft centerline of the flap grip, when looking at the top of the caddy. This value was measured from John’s marks on an earlier version.
- The caddy has to be tilted vertically about 20 degrees with respect to the flap grip mating surface (again taken from John’s feedback).
To implement the ‘minimized’ grip-to-caddy converter piece, I went back to Autodesk 123d Design’s ‘sketch loft’ feature. This is a very cool capability, and makes it (just) worthwhile to deal with 123d Designs many other ‘non-linear frustrations’ (see 2014/10/tinkercad-vs-123d-design-vs-meshmixer-pick-poison/). I started with a 2D ellipse that matches the flap grip cross-section, and then added a 2D sketch of the caddy. Then I tilted and rotated the caddy sketch as defined above, and then ‘lofted’ the ellipse sketch into the caddy sketch – voila!
Now that I had the grip-to-caddy converter design worked out, all I had to do was to insert the scaled up 1/4-turn latching mechanism into the top of the grip and the bottom of the converter, and print all the parts. Scaling and inserting the latch parts turned out to be pretty easy, as I already had all the latch geometry issues worked out from the time before, and all I had to do was use Tinkercad’s uniform scaling feature to ‘grow’ the latch about 150% or so. After scaling the parts, I latched and unlatched them in Tinkercad a couple of times to make sure that Part A did indeed fit into Part B, and then simply copy/pasted them into the grip and converter designs.
There was one complicating factor; due to printing concerns, I decided to print the converter and caddy parts separately, and then screw them together using 2ea 4-40 screws. I designed matching 2mm pilot holes in both the caddy and converter mating surfaces, and I added thickness to the bottom of the caddy so I could countersink sufficiently (about 3mm) to hide the screw heads below the bottom surface of the caddy. However, when I got everything done, I wound up just gluing the parts together with gap-filling superglue from my local hobby shop, and this seemed to do much better than screws.
In summary, I was able to quickly design and implement a new flap-grip version with ‘baked-in’ caddy twist and tilt, and was able to get the caddy about 12mm (about 1/2 inch) closer to the flap grip than in the old design.
As an added amenity for the pilot, I decided to design and implement a ‘caddy garage’ so John would have a place to store the caddy when it wasn’t in use. As part of the original testing program for the 1/4-turn latch, I had built some thin test pieces with the same cross-section as the flap grip – one with a plug, and one with a socket. I did the same thing for the larger latching mechanism, so all I had to do was to put some mounting holes in the socket test piece and throw it in the box with the completed flap grip/caddy assembly. John can mount the ‘garage’ in some convenient location in his cockpit, and simply latch the caddy assembly to the ‘garage’ after unlatching it from the flap grip.
OK, off to the Post Office tomorrow to mail the new stuff to John. I hope this new version will survive the ‘Gorilla Pilot’ test in better order than the last one did! 😉
I started into the 3D Printing world just a few months ago with a PrintrBot Metal 3D printer, a strong commitment to learn, and and very little else. Since then I have spent countless hours with the printer and several different 3D CAD applications to design and instantiate various 3D designs. In the process I have learned a LOT about AutoDesk’s Tinkercad, 123d Design, and MeshMixer applications. These are all free applications that purport to make it easy and intuitive to create 3D designs for 3D printing, and all three offer some amazing capabilities and features for free apps. Unfortunately, it can also be very frustrating to discover that after many hours trying to incorporate some specific feature into your 3D design, ‘you can’t get there from here’ and you are left high and dry with nowhere to go. MeshMixer is such a different program than either 123d Design or Tinkercad that I don’t plan to discuss it in this post – maybe later.
I have decided to coin the phrases ‘linear frustration’ and ‘Nonlinear frustration’ to describe the differences between 123d Design and Tinkercad.
Linear Frustration (aka Tinkercad)
Tinkercad is an absolutely amazing 3D design application. It has a very intuitive GUI, and it takes almost no time to become proficient and productive with its very simple set of primitives along with a robust set of manipulation features (WorkPlane, Group/Ungroup, Adjust/Align, and Solid/Hole). The Workplane concept is particularly powerful in that it allows you to quickly define the plane on which the next primitive will be placed and manipulated. This makes it child’s play to construct fairly complex objects in rotated and/or displaced local coordinate systems. Unfortunately, Tinkercad runs out of gas fairly quickly when designs require sophisticated treatment like morphing from one shape to another (an ellipse to a rounded rectangle in my case), or when reshaping objects after rotation. This is what I refer to as a ‘Linearly Frustrating’ in that the problem isn’t so much a failure of the package as much as a limitation on how much you can do with the limited suite of primitives and manipulation tools offered. Every tool does what it is supposed to, but the combination doesn’t allow an infinite pallet of options. With added work and persistence you can go a LONG ways with Tinkercad, but eventually the law of diminishing returns will get to you and you’ll be looking for something else with more horsepower.
There are a couple of other frustrations with Tinkercad that have more to do with the way designs are stored and managed; I’m a complete neat-freak when it comes to project file organization, so this is a big deal for me.
- although Tinkercad offer the ability to assign collections of designs to a ‘Project’ folder, all Tinkercad does is create a soft link from the corresponding design in the ‘All Design’ collection to the Project view. This means that if you happen to edit, or god forbid delete the ‘All Designs’ design, the ‘Project’ design gets deleted too – ouch! The ‘Project’ idea is nice, but it is basically useless unless designs are copied to Project folders rather than just linked.
- Along the same lines, there is apparently no way to copy or delete multiple designs at once. I have over 150 designs now, but many of them are early versions that I no longer need; it would be pretty nice if I could multi-select designs for deletion.
- And last, but not necessarily least – Tinkercad is apparently a victim of its own success, as the Tinkercad server(s) have been unreliable of late due (I think) to extremely high activity levels. Maybe Autodesk should consider fixing some of the more egregious problems with 123D Design (see below) so more of us would move off Tinkercad and onto 123D Design ;-).
Non-Linear Frustration (aka 123d Design)
And along comes AutoDesk 123d Design… I swear this app represents Yin and Yang, Good and Evil, Blissful Marriage and Ugly Divorce, Superman and Kryptonite, Batman and The Joker and all the other polar opposites you can think of, wrapped into one super-powered but fatally flawed 3D design program
Whoever was in charge of implementing the GUI (Graphical User Interface) for 123d Design gets my vote for Evil of the Century. The very first mouse-driven user interface was created back in the late 1960s by Douglas Engelbart, at Stanford Research Institute, and ever since then the GUI has been evolving. It used to be that ‘bad’ GUIs abounded, with weird menu modalities and nonsensical procedural rules, but these evolutionary dead-ends have been mostly driven extinct. GUI paradigms have now evolved to be nearly universal, to the point where humans can transition from one program to another with very little effort. Everyone expects and demands top-level menus that are activated with a left click, context menus that are activated with a right-click, and so on. Programs that don’t conform to that expectation immediately create a cognitive dissonance in the mind of the user, who now has to spend processing power just trying to figure out how to talk to the program, rather than how to transfer the 3D image in his/her brain onto the drawing canvas. Imagine you have rented a car at some distant airport, and you discover that the steering wheel is connected to the wheels in such a way that turning the steering wheel to the right causes the road wheels to turn to the left, and vice versa. It has been proven over and over again that it is virtually impossible for humans to recover from a crossed-control situation like this, even if they know up-front that the condition exists! This is because they have gotten so used to subconsciously controlling steering in one way that the car is off the roadway and into the ditch before the driver even realizes something is wrong. Thus, a deeply embedded interface paradigm cannot be violated without extreme consequences. In another context I had occasion to research the results of crossed rudder pedal control accidents in aviation. What I found was that in every case of crossed rudder pedals, the pilot was unable to recover without crashing the plane, regardless of the experience and/or expertise level of the pilot. In most (but unfortunately not all) cases, the crash happened during the takeoff roll, usually without fatal results. I belabor this topic to emphasize the dangers inherent in screwing with GUI paradigms just to be different or because the designer “has a better idea” – it may be ‘better’ but if it is too ‘different’, it will be perceived to be (and will be, in fact) worse!
In the case of 123d Design, I swear the application design team was divided into four different sections.
- The math team was from India, spoke only Hindi, and worked entirely using paper and pencil. They devised elegant and (mostly) correct transformation algorithms for things like the spectacular ‘loft’ algorithm that allows a user to morph one 2D sketch into another one, and the chamfer/fillet feature.
- The object-interface team was from Nepal, spoke only Tibetan, and used 1980s Micro-Vax machines with an early version of X-Windows to create the low-level screen widgets that expose object parameters to the user. While also mostly correct, these interface modalities died out right along with the Micro-Vax (and for a good reason!)
- The main GUI team was from Mars, spoke English learned from study of “I love Lucy” and “The Jetsons”, and programmed on the latest MARC (Martian Artistic Research Center) 3D design tablets (unfortunately for us humans, MARCs inherited their GUI paradigms from “The Jetsons” as well).
- The integration team was from AutoDesk, spoke Valley English, smoked pot on the weekends (and on the weekdays, and at lunch, and…) and were experts at putting lipstick on pigs. They spent a few days and used up a 55-gallon drum of lipstick, and vioila-123d Design!
- The testing team – What testing team?
OK, OK it couldn’t possibly be that bad – I’m sure the Martians had access to other TV programs too ;-).
123d Design has some wonderful features (like the ‘loft’ feature) that can be a treat to use. Unfortunately 123d Design is also one of those evil-ridden applications where you cannot make three mouse clicks in any one direction without falling into yet another devil-spawned GUI trap of one sort or another. To mention just one or two:
- You can non-linearly scale any 3-D object, but you can’t non-linearly scale a 2-D object, even though the non-linear scaling fields are exposed and can be edited! It’s just that nothing happens when you do! I would die from embarrassment if I had to admit I was part of a design/programming team that couldn’t even remember to connect all the numerical entry fields to their corresponding class variables – I mean c’mon guys!
- When using the ‘Transformation’ (move/rotate) feature, there is a single numerical entry box presented to the user with no label. One has to mouse over the box to find out what it does, and what it does changes depending on what axis you last clicked on! So you could enter a number and discover it does exactly what you wanted – or not– depending on the recent past history of your mouse clicks. You have to click on an axis, and then hover over the entry field to see if the hidden label now says the right thing. This is more than stupid – it’s EVIL!
- When you want to open a locally saved design file on the PC version of 123d Design, it takes 3 mouse clicks instead of the one click for every other application on the planet. First you click on ‘Open’ (well, duh!) – but then you get a dialog urging you to “Sign In!” so AutoDesk can “Access Your Projects” – NOT!! Then you have to click on the “Browse My Computer” tab, and then you have to click on ANOTHER ‘BROWSE’ BUTTON!! – grrrr. And, you have to that every time you want open a design file on your own damned PC!! No ‘Recent File List’, no MRU (Most Recently Used) exposure, nothing! Even AutoDesk should be aware of the MRU concept by now!
- The main window of the 123d Design PC version cannot be resized below a certain size, which occupies about 2/3W by 1/2H of the real estate on my 1920 x 1080 monitor. No other application on my PC, and almost no other application I have dealt with over the last decade or so does this. Can you say “f###ed up”?
- It is apparently impossible to Ctrl-C/Ctrl-V an object from one 123d Design instance to another one on the same PC – a feature that has been in every multiple-instance application since Gates and Jobs were in diapers. In order to copy a single object to another 123d Design instance, you have to save the file containing the object, open that file in the new instance, and then delete everything but the object you wanted to copy.
- There’s no File Save As… menu selection; instead you have ‘Save’ and ‘Save a Copy…’, which has ‘To My Projects…’ and ‘To My Computer’ sub-menu choices – argghhh!
- Ctrl-A doesn’t select everything – give me a break!
- There is NO ALIGNMENT FEATURE! you can group objects, you can arrange objects in circles, lines, or the Ohio State ‘Block O’ for all I know, but you cannot align them! What kind of drawing program doesn’t have an alignment feature? Rumor has it that the wonderful Tinkercad alignment paradigm has found its way into the iPad version of 123d Design, but not into the Windows version – the one used by about 70% of the 3D designers in the world.
- There is no HELP! There are lots of YouTube videos showing how to do this or that, but most were done with significantly (sometimes radically) different GUI’s from earlier versions. Also, the videos ‘cherry-pick’ the features they like and avoid the features that don’t work (and they are legion!).
- The help forum sucks big time; there are at least two different forum views, and I haven’t been able to figure out which view comes up when. Posting questions or problems is a real nightmare, and there is the infamous problem where you can write up a long post only to be confronted at the end with an error message that says ‘You can’t submit this post because you haven’t yet logged in – please log in and we’ll bring you back to this page (and if you believe that we have a bridge we’d like to sell you)”. Every other forum package on the planet puts up the ‘not logged in’ error message up front, or even better, simply disables the ‘Post’ button if you aren’t logged in! And, if you do manage to finally get your post submitted, you’ll not find anyone on the other side of the curtain; Posts there have been unanswered for months if not years.
You may say that these are trivial gripes – and I would agree with you. Except the same sort of passive/aggressive “I know better than the rest of the universe and you can do it my way or the highway and by the way, my way doesn’t even work half the time” behavior is rampant throughout the program. So, instead of getting nice and warm and cozy with the program, my relationship with 123d Design is more like a series of running battles; I know I’m going to take casualties, but I need that particular feature and I have to hope I won’t get my ass completely shot off (this time) in the process.
Where to go from here?
Some posters on this subject have suggested that Autodesk has deliberately released 123d Design with such major and obvious flaws to get users hooked on 3D design so they can be sold their paid products like Fusion 360; sorta like giving away introductory heroin doses to capture more addicts. My personal opinion is more like ‘Hanlon’s Razor’ – “Never attribute to malice that which is adequately explained by stupidity”.
The title of my last post on this subject had the word ‘Finished?’ with a question mark, because I suspected that John and I weren’t really ‘finished’ with this project (and for that matter, may never be!), and sure ’nuff, the ‘finished’ version came back to me with some suggestions for improvements. However, as has happened at every stage of this journey, lessons learned with each trial opened up avenues for improvement. One of the many cool things about the current 3D printing world is that a single individual or a small group (in our case, a ‘group’ of two!) can traverse the complete trial, re-design and re-implement cycle in a very short time at essentially zero cost. This short cycle time and low incremental cost means that failure isn’t only an option – it’s an expected and accepted way of rapidly stepping through many design variations in the quest for truly useful and cool ‘things’. After all, who would have thought that a clay model of a joystick-mounted ClearNav remote caddy created by one pilot long ago would have evolved so rapidly into a detachable and rotatable flap handle mounted caddy at all, much less in the 2-3 months we have been working on the project (and this time includes several ship/return cycles to move trial pieces from my lab to John’s glider and back again!).
So, anyway, back to the current design cycle: At the conclusion of last week’s episode, I had completed a new version and sent it off to John for testing. This version included the following improvements:
- Deleted the cable channel in the flap grip piece
- Resized the rectangular slot in the flap grip piece
- Removed the finger scallops on the front of the grip
- Offset the caddy piece slightly forward of the flap handle centerline, and rotated it about 20 degrees ‘up’ relative to the top surface of the flap grip
- Used a round vs rectangular post to couple the caddy to the flap grip to allow for rotation
- Added protection walls for the RJ-11 remote connector
Although this version was a decided improvement over the last one, I still wasn’t happy with it, for a number of reasons:
- First and foremost – the way that I had implemented the rotation feature meant that John could no longer remove just the caddy portion from the flap grip when entering/exiting; now he had to remove the entire system, flap grip and all, from the flap control bar. I didn’t think this would work as a long-term solution.
- The transition piece from the flap grip ellipse to the remote caddy rounded rectangle was clunky and ugly, to say the least
So, even as the previous version was on its way down to John, I was already working on ideas for the next version to address the above issues.
Rotatable and Detachable:
I wanted a way to have my cake and eat it too – a way to make the remote caddy easily (and repeatedly) detachable from the flap grip and easily rotatable about the axis of the flap grip and fixable at the desired rotation angle. Whatever solution I came up with had to also be implementable as a plastic 3D-printable shape – no cheating allowed!
Option 1 – Snap Ring: Maybe I could design a snap ring setup, where the post on the bottom of the caddy piece would snap into some sort of groove in the flap grip so it would rotate freely but not just fall out – some force would be required to detach it? I decided to experiment with this a bit and see if I could come up with something workable. Another of the many cool aspects of 3D printing is that I can rapidly design and print small parts to test just the current idea, without wasting time with non-relevant structures. In this case, I designed and printed several pairs of ‘buttons’ just to test the snap ring idea.
What I learned from this series of experiments is that a) I’m not that good of a Mechanical Engineer, and b) The snap ring idea is great for a semi-permanent rotational coupling, but not so much for a system that must be connected and disconnected many times. The plastic is just too hard – it’s just as likely that the part will fail before the snap ring disconnects! The good news is that I was able to learn this lesson quickly and cheaply! ;-).
Option 2 – Separate the rotation feature from the attach/detach feature: The snap ring exercise convinced me that I needed to separate the rotation feature from the attach/detach feature. Conceptually, this meant that I had to partition the system into three parts rather than two; the flap grip, a ‘converter’ piece that would attach/detach from the flap grip on one side, and would form a rotational surface with the remote caddy piece on the other, and the caddy piece itself. Separating the design into three pieces vs two wasn’t really much of a conceptual leap anyway, as I had already done most of this in the previous incarnation when I used the 123D Design’s ‘Loft’ feature to transition from the flap grip ellipse to the caddy rectangle. All I had to do was to make that transition into it’s own separate piece, with some sort of attach/detach mechanism on the bottom, and a rotation feature on the top. Of course I still had to figure out what those mechanisms were, but details, details, details! ;-).
Quarter-Turn Latch For Attach-Detach: While I was doodling around trying to figure out a good mechanism for latching/unlatching the center ‘converter’ section to the flap grip, my wife happened to look over my shoulder and casually say “what about a quarter-turn fastener?”. My first thought was “nah – WAY too hard”, but the more I though about it, the more is seemed like that might not be such a crazy idea after all. One of the many cool things about 3D printing is its ability to form internal structures that aren’t possible via normal milling/machining techniques, another is its ability to convert a solid shape to a cavity and vice-versa, and another is the way it facilitates rapid experimentation. The combination of these three things allowed me to design complementary plug/socket designs, and then rapidly iterate through several versions to improve the design.
I started with a circular base for both the ‘plug’ and ‘socket’ version of the quarter-turn latching mechanism, but rapidly changed to an elliptical base that exactly matched the cross-section of the flap grip. I knew I would eventually need to transfer the mechanism to the top of the flap grip and the bottom of the identically-shaped bottom of the center transition section, so using the same shape for the experimental parts would make the transfer a LOT easier. The first set of trials were pretty clumsy, as I had no real idea what a good mechanism looked like, how to determine the amount of rotation from locked to unlocked, and which direction I wanted the locking rotation to go. Version 1 used a rectangular tongue for the latch, but I discovered this didn’t work very well, so this evolved to a pie-section tongue shape, and the complementary internal socket channel evolved to match.
By version 3, I had also started adding ‘engraved’ version number and orientation reference marks to the experimental pieces as an aid for getting the lock/unlock orientations right (after having screwed this up a couple of times without the reference marks). I had also gotten smart enough (after some more screwups) to extract the design of the quarter-turn mechanism into its own file, so it could be added to whatever structure required it (and making it available for completely different future projects!).
Doing this made it MUCH easier, for instance, to reverse the lock/unlock rotation direction when I discovered that the original orientation made the mechanism too easy to unlock inadvertently during normal use (50/50 chance and I blew it – again!). The finished (as much as anything gets finished in this project) product is shown below
Rotational Feature: Based on earlier feedback from John, I wanted the remote caddy to be able to rotate with respect to the flap grip. In an earlier incantation, the piece that transitioned from the flap grip ellipse to the semi-rectangular remote caddy was integrated into the remote caddy, and the entire piece rotated about the top of the flap grip. This was OK, but the transition/caddy section could not be easily removed from the flap grip, making glider entry/exit potentially awkward. In the new setup the idea was to separate the transition section from the remote caddy so it could rotate around the top of the transition section, while the combined caddy/transition sections would attach/detach from the flap grip via the quarter-turn fastener. So, I needed a rotation mechanism, preferably with some sort of detent arrangement so John could try different rotation angles in flight. The detent requirement led to another series of experiments with snap-ring buttons, with a small protruding tip one button that engaged a set of radially distributed grooves on the other. The result, unfortunately, was that if the tip was sufficiently large to properly engage the grooves, it was also large enough to make it nearly impossible to ‘click’ from one groove to another. In other words, it turned out to be pretty much an ‘all or nothing’ kind of thing. Fortunately I still had a couple of the McMaster-Carr ball-spring plungers left over from the last go-around, and I replacing the protruding tip with a spring-loaded ball did the trick very nicely!
OK, so now we had the desired quick-release feature so John can easily remove the remote caddy (with its attached cable to the ClearNav) from the flap grip for glider entry/exit, AND the desired ability to rotate the caddy with respect to the flap grip axis! All it took was a little persistence, a genius wife, and about a million design/implement/test cycles ;-). The following photos show the various experimental parts generated, and the ‘final product’ (but of course, ‘final product is what I said the last time!)