标签: prototype

Creators of hobby projects and the creators of professional prototypes alike share a common dilemma -- what to do about the cabinet. In the not-so-distant past, creating a prototype printed circuit board (PCB) was the most time-consuming and expensive problem, but now this is much less of an issue. By comparison, acquiring an affordable, professional-looking cabinet remains an expensive undertaking.   Recently, I've been chatting to someone who thinks he has a solution -- Charles Spence. In a recent telephone conversation, Charles was saying that he is thinking of launching a Kickstarter project, but first he would like to "hoist his idea up the flagpole and see how well it flies," as it were, and that's where you come into the picture. I personally really like Charles's idea, so I asked him to write it up in more detail so I could share it with you. Charles responded as follows:   Dear Max, thank you for giving me the opportunity to share my idea with others. One part of building prototype electronics that continues to plague me is the cabinet. It still seems to be the remaining piece for the hobbyist and professional that forces their work to look amateurish to family and friends or to the customer. While I admire the quick and dirty methods Jim Williams and Bob Pease taught us, only the enlightened few seemed to deeply appreciate the ingenuity of a cookie tin for EMI shielding. However, it takes an understanding wife or boss to accommodate the hoarding of these likely Christmas gifts.   While I am also a fan of the "dead bug" method of circuit prototyping, it tends to hide significant issues with regard to parasitic capacitance or leakage paths that -- if you ever want to replicate your circuit -- will bite you. I also argue that creating a decent cabinet is more time-consuming than creating a prototype PCB. This is because you can go straight to a PCB for little relative cost these days (when I started my first real electronics job, it was $1K for a set of two-layer proto-PCBs; now it's only around $120 on the high end). I create a PCB for all my prototypes -- what seems to remain is the box.   On my last project, I think I came up with a solution I would like to share with your readers. This solution applies principles similar to those that enable low-cost prototype PCBs and even low-cost integrated circuits -- share the panel or wafer.   Current industrial CNC laser cutters can slice up a panel of aluminum quickly and cheaply. What seems to plague the sheet metal business is making a bend cheaply enough for use in prototype cabinets. A simple aluminum extrusion gets past this issue, which inspired the following cabinet design.       This example represents a 3" x 5" x 7" deep cabinet. The panels are intended to be cut from 0.050" thick 5052-H32 sheet aluminum. For the purposes of this example, the extrusions are shown in orange in an effort to make their design more visible. These extrusions are intended to be made from 6061 aluminum hardened to T5 or T6. The extrusions do include a guide channel for a PCB, but the PCB(s) could also be mounted to any panel via standoffs and screws.   In one implementation, the bottom and two side panels could be glued to the extrusions with a cyanoacrylate (Krazy Glue I) like Loctite 380 (Black Max) or an adhesive transfer tape like 3M 465 or 966. The top panel would still be allowed to slide to facilitate easier access to the internal electronics for debugging and testing.   The cheapest way to make this type of cabinet uses raw aluminum. My current estimates show they could be made with custom cutouts for $50 each in quantities of one, assuming several people ordered cabinets at the same time (each cabinet can be different). Furthermore, since the un-assembled cabinet can be shipped flat, it can be sent via USPS Priority Mail bubble pack to most places in the US for less than $6.00.   Observe that this basic design can be extended all the way up to 19" rack-mount cabinets. The front panel can be extended to have rack mounting holes (but it would also need to be made from thicker aluminum, which would drive the price up a bit). A simple bracket could be mounted in the middle to stiffen the center section for cabinets this wide. Below we see two different views of a real-world cabinet created using this concept. Since the die for the extrusion would cost more than I care to spend at the moment, I decided to see what I could do with off-the-shelf 3/4" x 3/4" x 1/8" right-angle aluminum extrusions. The cabinet pictured is 10" x 10" and 3" deep. (The power supply is a little overkill to minimize conductive noise issues for a sensor and the horrid ground loop. This is a prototype. I don't like spending inordinate amounts of time chasing noise issues, ground loops, and my stupidity.)       In the case of this example, everything is screwed together, which involves way too much work drilling and tapping. Of course, you can still do this with my proposed custom extrusions, but I tend to think glue looks like a better alternative. Having said this, I do struggle with things that cannot be easily undone (cyanoacrylate does come off with acetone, but unpredictably).   The way this works The way I envisage this working is that I would have a die created to fabricate my special extrusions. When other people want custom cabinets made, they would send me the CNC files associated with the sub-panels for their cabinets (more about this below). I would take the sub-panel designs from multiple people and combine them into one big panel file to send to the folks with the industrial CNC laser cutter. By combining multiple sub-panels into one big panel in this way, the cost of laser-cutting the sub-panels will be reduced dramatically. Finally, I would ship the sub-panels along with four appropriately sized extrusions to each of the people who had ordered a cabinet.   What needs to be done A die needs to be made for the extrusion. A website needs to be established for taking orders. And, most important, the customers need to be willing and able to supply drawings of the panels with the cutouts they want in DXF format files.   I'm thinking that the website could provide templates in DXF format for front and back panels that show the corner details. In this case, there could be a range of panels for standard-size boxes from smallest to largest. Cutouts for common connectors like DB-9 and DB-25, USB, and Ethernet could also be provided in DXF format. However, the biggest problem for making these cabinets is modeling the printed circuit board where these connectors are placed accurately so that the holes in the cabinet will line up. I do not see an easy solution that is also low-cost to the end user. We have the same issue with PCBs. Until Cadsoft's Eagle came along, there really was no good low-cost PCB tool available.   AutoCAD and SolidWorks have powerful features that make doing this easy, but also have a steep learning curve to get to the point of it being "easy." They are also expensive if you are not going to school. DesignSpark Mechanical looks like a possible alternative, but I have not used it myself. SketchUp ends up have a learning curve to make it useable, as do other open-source alternatives.   In the end, the CNC laser house needs DXF files that have all the sides panelized to enable a service like this to be at the cost level now available for prototype two- and four-layer PCBs.   Cost comparison A 12" x 7" x 4" LMB or Hammond U-shaped 1411 type Al box from DigiKey costs $27.30 plus shipping. Circuit Specialists offers a better-looking enclosure 11.9" x 7.5" x 2.9" for $17.95 plus shipping.   I got a quick quote from Protocase for three 3" x 11" x 11" U-type 20-gauge steel cases with 10 cutouts with black powder coat, no labels. The total was $616.99, which equates to around $200 each.   As I mentioned earlier, using my approach, a 3" x 5" x 7" deep cabinet would cost around $50. I estimate that a 10" x 10" x 3" cabinet would cost no more than $75.   So, here's the question The basic question I have is: Would cabinets made with my custom extrusions be good enough and worth the cost for most prototype electronics builders? Also, would they be willing to wait one, two, or three weeks to take delivery of such a cabinet?   I am currently working on determining the cost of graining and anodizing the aluminum in batches to see how much this will add to the price. I am also trying to find a service that uses inkjet printers for creating text annotations and graphics on the cabinets. I know that this technique is currently being used by some PCB houses for their silkscreen legends, and I think this would enable an incredible flexibility in labeling, perhaps even coloring the entire cabinet.   Max here again, so there you have it. I think Charles has something here. I know that many of my own hobby projects would benefit from having a more professional-looking cabinet. And if you are a company creating a real-world prototype, having a professional-looking cabinet can be really important when it comes to presenting things to potential customers.   So, what do you think? Is this idea worth pursuing further? Should Charles go it alone, or would a Kickstarter project offer a good option? Please tell us what you think by posting comments below.

IAR,CC2530的工程中，自己添加函数报错。 Error: function "~~~" has no prototype 在工程OPtion-C/C++ Compiler-Language中 去掉 Require prototype 选项，重新编译。

Some time ago, hardware people designed all of their circuits. But in the vacuum tube days some wise engineer created modules. An example was a dual triode flip flop that would generally plug into a standard octal socket. Now others could reuse that design by buying the module and including it in their product. Later the integrated circuit formalized this notion, and today there's a veritable ocean of standard parts available. Datasheets carefully characterize their behavior; we buy them and wire them onto a board. That's the holy grail of reuse, and in some cases the software community does the same thing. We recycle an object module and link it into a new application. Alas, for reasons both good and bad we often monkey with the source instead, even though NASA has shown that once one changes more than about 25% of the source lines there's little benefit to reuse. Traditionally, vendors who supply proprietary code that will be included in a production system (like protocol stacks, operating systems and the like) provided libraries compiled on a particular CPU architecture. You link these into your code. But for as long as I can remember engineers grumbled that the provided API was both interface and insulation. Insulation, because who knows what boundary conditions lurk behind the often-inadequately documented API? Insulation, because it can be impossible to track down bugs that live in the nebulous region between your own code and that of the vendor. Who hasn't gotten frustrated by the poor docs that sometimes cause us to prototype an API call, tossing almost random data at a package in an attempt to understand just how one goes about properly interfacing to a package? We see it in the hardware, too, when a peripheral's control registers either don't work as advertised, or there's some bizarre combination of bits that drive the thing into a crazy mode. And yet there's a part of me that doesn't want exposure to the internals of some other company's code. I really don't want the source; I want a clean, clearly-defined interface that works as advertised. Returning to the hardware analogy, it's fun but unnecessary to look at the schematic of a flip flop. The interface at the pins is really all that's important. But in the software world we've all been burned enough that trust is scarce. Then there's the stability issue, especially in these strange economic times. If I have a package's source there's much less risk if the company goes out of business. I may not want to support the code, but that's better than getting set adrift by the seller's bankruptcy. Yes, it's possible to set up a source code escrow, but what are the legal implications of dealing with that escrow? Why add layers of hassle? What do you think? Is not having the source a deal-breaker? Or, conversely, does the source make a vendor's product more compelling to you?

The customer is often wrong.   The agile notion of constantly soliciting customer feedback and incorporating that input into a product is a brilliant way to produce prototypes. Prototypes, of course, are poorly-implemented skeletons that mirror a real product.   Their function is to quickly minimize risk, which arises from vague requirements, unknown science issues, or from other uncertainties. Prototypes are invaluable when needed but are not required for every product. Maybe not for most.   Engineering teams need to be sheltered from customers when developing the real product.   The customer might be an end-user, who, halfway through the engineering effort inexplicably asks for an MP3 add-on to the bottle opener. Or he could be a member of the sales team. My career has been haunted by these guys who invariably say " I can't sell that piece of crap unless you add this feature. "   That statement is often correct, though it really illustrates the salesman's own incompetence and is not a commentary about the viability of the product. Sales always asks for more and more. By tomorrow. So do customers.   Iterative elicitation of requirements, while sometimes necessary, is often a substitute for poor requirements analysis. Change does happen, of course, even on the most well-understood products, which is why companies have change control procedures.   Sam Walton was right when he said "There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else."   When a customer asks for a change, the only proper response is: "Mr. Customer, we love you. We'll do anything you want. But there will be a cost, perhaps in schedule or dollars. Let me get back to you."   Any other response will yield poor customer service as he'll be disappointed by the suddenly-late product. Or angry when he discovers that the added MP3 player now means the bottle opener has to be charged every night.   Open communication is key, and that interaction is best if each party has time to think through the implications and the honesty to be clear about what the effect of the change will be on the product.   Change control adds friction to the process, a needed friction. Wild responsiveness is sometimes indistinguishable from chaos.   I once delivered a sailboat owned by a younger fellow who had grown up surrounded by electronics. He steered by the course painted on the GPS screen, and just could not understand when I complained that the GPS only knows where we were pointed, not where we want to go.   We zigged and zagged all the way down the Chesapeake Bay, getting to Norfolk eventually but much less efficiently than if steered by a steady hand reading the compass.   Set a course, follow it, and change it with forethought only if necessary.    

The customer is often wrong.   The agile notion of constantly soliciting customer feedback and incorporating that input into a product is a brilliant way to produce prototypes. Prototypes, of course, are poorly-implemented skeletons that mirror a real product.   Their function is to quickly minimize risk, which arises from vague requirements, unknown science issues, or from other uncertainties. Prototypes are invaluable when needed but are not required for every product. Maybe not for most.   Engineering teams need to be sheltered from customers when developing the real product.   The customer might be an end-user, who, halfway through the engineering effort inexplicably asks for an MP3 add-on to the bottle opener. Or he could be a member of the sales team. My career has been haunted by these guys who invariably say " I can't sell that piece of crap unless you add this feature. "   That statement is often correct, though it really illustrates the salesman's own incompetence and is not a commentary about the viability of the product. Sales always asks for more and more. By tomorrow. So do customers.   Iterative elicitation of requirements, while sometimes necessary, is often a substitute for poor requirements analysis. Change does happen, of course, even on the most well-understood products, which is why companies have change control procedures.   Sam Walton was right when he said "There is only one boss. The customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else."   When a customer asks for a change, the only proper response is: "Mr. Customer, we love you. We'll do anything you want. But there will be a cost, perhaps in schedule or dollars. Let me get back to you."   Any other response will yield poor customer service as he'll be disappointed by the suddenly-late product. Or angry when he discovers that the added MP3 player now means the bottle opener has to be charged every night.   Open communication is key, and that interaction is best if each party has time to think through the implications and the honesty to be clear about what the effect of the change will be on the product.   Change control adds friction to the process, a needed friction. Wild responsiveness is sometimes indistinguishable from chaos.   I once delivered a sailboat owned by a younger fellow who had grown up surrounded by electronics. He steered by the course painted on the GPS screen, and just could not understand when I complained that the GPS only knows where we were pointed, not where we want to go.   We zigged and zagged all the way down the Chesapeake Bay, getting to Norfolk eventually but much less efficiently than if steered by a steady hand reading the compass.   Set a course, follow it, and change it with forethought only if necessary.