A lot of pro designers don't prototype.
Quote:
Originally Posted by
skimask
Agree with mister_e 99%. Simulators might be a good 1st step, but that's it, an initial 1st step to see if an idea might even be remotely feasible. Relying on a simulator in my mind is false economy. 2nd step straight to the prototyping stage, not straight to a production PCB.
I have about 10 years of expertise with electronics and computers. There's a heck of a lot that I know and an equal amount that I don't. Over the years I have had a dozen projects published in the Silicon Chip magazine, and I've also been employed as an electronics technician in some previous job roles.
Often the people that I’ve worked around have reminded me that a lot of professional design engineers take their initial schematic and go straight to PCB. In my first technical role with a company called BEAR Solutions, I once threw my hands in the air offering to prototype some of their designs. In my spare time even. I figured I'd learn a thing or two. The response was very clear. We go straight to PCB; if the design needs corrections we simply modify the layout and request another 1 off board from our suppliers.
Economically this can work well, but only if you plan on ordering a specific quantity after the design has been perfected. At worst you'll be up for the tooling fee. Some manufactures may write this amount off or bury it somewhere into the actual total cost. Of course though, if your production runs small, or you have extreme doubts with the integrity / workability of your design, then this may not be a feasible approach. There’s a big difference between R&D and setting out to produce a product that uses known to be good and working technology.
All told, if you know exactly what you're doing then there's no reason why you shouldn't be able to go straight to PCB. (*Sure wish I did)
Best Regards,
Trent Jackson
Straight to PCB isn’t for you
If you anticipated on this then going straight to PCB isn’t for you. In fact, the anticipation of ending up with half a dozen unsuccessful attempts clearly spells out that there must be a lot of uncertainty in the design. Possibly due to the fact that it might be a large-scale project, or just a whole heap of research and development that’s required.
Consider this scenario:
You design say 5 new projects every month. On average, 20 discrete logic IC’s, Z80 microcontroller, 50 passive components to boot…
Now, in the real-World implementation phase you have 1 of 2 choices.
A) Employ someone to prototype it. Skilled person required. Might take possibly a week to Vero-board it.
B) Double check, TRIPPLE check your work and go straight to PCB.
Board comes back from the manufacture, fill it, solder it, test it and you’re done. Few hours work. Possibility you might get it the first time? For someone who really knows their stuff, yes I believe so.
Tooling fee is about $100. Of course though, this arrangement would only work if your design used existing technology. Otherwise there would be too much guess work involved and I would agree with your argument entirely.
Best Regards,
Trent Jackson
Migrating from breadboard to PCB doesn’t always work!
Another worthwhile mention is that, if a circuit works on vero or breadboard, it doesn’t necessarily guarantee that it will work as planed on a PCB. Conductors have both capacitance and resistance attributes which can effect the proper operation of many circuits. In particular with RF and audio designs. Even some digital too.
Poorly designed audio is very distinctly noticeable to the human ear - noise introduced perhaps because of an earth loop - while RF based designs may often just refuse to work. Another consideration is track width on a PCB, you may have used heavy-duty hookup wire for these parts on some vero-board, works fine perhaps, but on the PCB the width may be insufficient to handle the amount of required current.
Plus…
On breadboard or vero the design may work well, perhaps because of the exact layout of the components? When you take it to PCB it might produce an adverse result because you changed things. If this is the case then you have effectively taken a step backwards.
All told, if what you’re doing now seems to work well for you then don’t change it. Better the devil you know. I am a firm believer in this entirely.
Best Regards,
Trent Jackson
I have never test driven Proteus
While I have never actually test-driven Proteus, but like with pretty much anything else that's new in this World, willing to bet that there's a steep new learning curve involved. I can even picture it being quite daunting too.
Could it be anymore complex than manually routing a double sided through hole plated PCB with silkscreen masks? If it is, then it’s really not in line with my suggestion. If you Require a science degree to drive it then it would be very seldom that it would appeal to anyone without this degree. Makes matters even worse if there are actually genuine flaws with it too.
Can MELabs come up with a better solution that is low in cost, reliable, easy-to-use and pretty much entirely specific to the range of PICs that their brilliant compiler supports? At least my wish is clear.
Best Regards,
Trent Jackson
I personally know how much effort is involved
December of last year I wrote an emulator to simulate a real-World project that was published in the Silicon Chip magazine back in 1999. A 32 LED microcontroller-based Christmas tree. The tree uses bi-colour LEDs and has a seemingly endless array of patterns, which are stored in an onboard EEPROM.
So taken by this tree, I decided to write an emulator for it. It's not identical to the original and it's far from perfect. There is about 100K of unavoidable source code in it. An absolutely ridiculous amount of time was spent on this project in attempts to simulate the behavior of something that is ultimately quite simple in real life.
http://www.planet-source-code.com/vb...67268&lngWId=1
Best Regards,
Trent Jackson
VB doesn’t have true OOP traits...
Hi Luciano.
Far as I'm aware, VB doesn't cater for true OOP - Object Orientated Programming. There's no Polymorphism, inheritance, yada, yada, yada. It is object-based though. Not so long ago I used to confuse myself with the two. There's a lot of debate about what VB can and can't do.
Anyhow, like it or love it, but the main reason I coded the Tree how it is was to please a very fussy audience. I did it how everyone wanted it, so I won a competition for it. Anything that's posted on PSC has to be either API or DirectX-based to even get a moments consideration.
It can be a real tough game on PSC. Just when you think you're starting to get real good in VB someone comes along and posts something that's just absolutely way out of this World and you sit there scratching your head telling yourself "gee, I've still really got a long way to go".
By the way, thanks for all those links :)
Best Regards,
Trent Jackson
Done a lot of object-based programming.
Hi Luciano,
Yes, over the years I have done a lot of object-based programming in VB.
I agree, Object-Orientated-Programming would be an essential ingredient to be used with any complex simulator such as Proteus.
No plans on anything like that for a while. I'm currently a full time student with nothing but a lot of discrete maths and technical jargon on my mind.
Best Regards,
Trent Jackson