Steve, when you say you have to grind the boards, do you mean you grind the long sides down to cut the 28 large through holes in half?
That right there is a great example of what I mean by letting the community/users help improve the design. If the cad file were up in a git repo, or just publicized anywhere any how, it doesn't have to be github, I could have told you since more than a year ago, that you can get those manufactured with the holes already cut in half. That's one of those whole pain in the neck steps 90% erased already, just from someone else telling you something they discovered and now you can incorporate it. You can specify the outside dimension to go right through the holes, and the router will do it, and leave just the right final outside dimension, with all those holes cut in half for you. That's how the figtronix boards come. When I build a figtronix board, all I have to do is barely sand it a little just to knock down the "rat bites" (breakaway tabs), and sometimes clean off these tiny little copper flags that hang off the side of some holes, left behind by the way the router cuts through the through hole plating. But that only takes a takes a few seconds one minute and the tools are just a sheet of sand paper on a flat surface. I use a cheap wood cutting board. Couple swipes and it's good to go. pics https://goo.gl/photos/i4DX5LEywTTSevQs6 That's what I mean by you're working too hard and worrying about things you don't have to worry about. I don't know how to help with 50 different things abouyt the design, but I know that one thing. Somone else knows one other thing, etc, etc. And, even though this is already better than having to grind all that board down, I bet it can still get even better. I *think* (I don't know), but I think you can also specify where the rat-bites go, within limits. So I think it's also possible with a board this small to make it only have 2 rat bites on the ends and have perfectly clean contacts all down the long edges. Or you might be able to make it put 4 total rat bites, but with 2 on each end and none on the sides. And then you can reduce the long dimension *slightly* to allow the board to fit in the socket without even cleaning up the board to sand down the rat bites flat. Could just break 'em off and go. No sanding at all. That's the kind of thing I would research and figure out just for my own satisfaction, and then when I have figured out how one does that, I'd tell you, or I'd do a submit request to submit changes to the cad files. Just like if I do figure that out, I'd tell FigTroniX and then the figtronix board gets that much better to use. That's a lot of labor and manual steps totally eliminated from the final design just from having users be able to contribute. You don't have to have it all perfect, you just get it up there and let everyone who has an interest in it help make it better over time. -- bkw On Mon, Jan 9, 2017 at 10:06 PM, Doug Jackson <[email protected]> wrote: > Hi Steve, > > I agree that transferring would be work. I feel that separating the > hardware and software may be the path forward, especially if the hardware > design is proven. > > My clocks use a 240mm square PCB that I source from Pcbcart. Experience > has shown that they are cheaper than OSH part for volume. I normally order > boards as 60 to 100 units at a time to take advantage of volume discounts. > Same for parts, I have oearnt that volume discounts make sense in small > scale manufacturing. > > After surface reflow, all of my boards go through a test and firmware > loading jig. I published the design for one of the jigs on > Instructables.com > http://www.instructables.com/id/A-Programming-Jig-for-our- > DougsWordClockcom-DeskC/ this radicaly simplifies the firmware load. I am > confident that I could devel op something to do the CPLD load as well. > > From the perspective of manufacturing capacity, my workshop has > microscopes and logic analysers and grinders etc etc.. but it woud be > worthwhile figuring out how to modify the design so that there was no need > to rip spacers from wood, or grind boards and remove as many manual > handling steps as possible. > > Doug > > > On 10 January 2017 12:52:26 pm AEDT, Stephen Adolph <[email protected]> > wrote: >> >> Doug, thanks for your note - read on...let's discuss. >> >> I'd be happy to put the board files on Oshpark, and place the >> software, firmware, test applications in a git, but that isn't enough. >> One needs to install the firmware and test the hardware afterwards.. >> and that assumes you can assemble a REX in the first place. Plus you >> need test jigs to do all that. Feasible, but a significant investment >> in time and learning. >> >> The biggest issues I see- >> >> * fine pitch soldering >> * grinding the PCBs down so that they can be plugged >> * sourcing spacers - I slab cedar strips using my table saw.... 0.050 inches >> * firmware - it is stable now, but in general you must understand >> RTL,VHDL and CPLD programming >> * REX software is quite complicated. it gets right in to the OS via 4 >> separate hooks and significantly affects boot up. it can be a real >> challenge to debug. >> * Keeping ahead of changes and how they work in all 5 supported models >> is a bit of work also. One needs to have hardware examples of all 5 >> models to do the testing. >> >> >> The equipment I rely on in general includes >> >> 1) a bench grinder/sander >> 2) a 15x binocular microscope >> 3) a Tek scope >> 4) a logic analyzer >> 5) my hardware jig(s) for installing firmware and testing the hardware >> (M100, PC8201 variant) >> 6) xilinx CPLD toolset (easy to get but you have to learn to compile >> and install CPLD code >> 7) a basic weller temp controlled iron + solder paste in a syringe >> >> If there were zero design changes, here are the steps to assemble a working >> REX. >> >> 1) assemble REX - grind PCB, hand solder CPLD, Flash, power supply, clean. >> 2) install firmware - using Xilinx tools and known good firmware >> binary, install binary image into CPLD. REX mounted in test jig. >> There are 3 firmware versions. M100, T200, NEC. >> 3) test REX - run stand alone test software on appropriate Model T / >> rework failed units. >> 4) install application >> 5) final test >> >> Further development of REX is more involved obviously. Maybe at this >> point future development is limited to software only, and it may be >> safe to assume the hardware and firmware are fixed. >> >> Anyhow, as I said, it is feasible to transfer this to someone, but I >> feel like it is a fair bit of work to transfer as well! >> >> Steve >> >> On Mon, Jan 9, 2017 at 8:26 PM, John R. Hogerhuis <[email protected]> wrote: >> >>> I think the only fundamental problem right now is availability, since Steve >>> has been busy with real life. Rex is not something you can just git clone >>> and make. Part of it could be, of course. >>> >>> Component ordering, fabrication, assembly, test, order taking, shipping is >>> the current issue. >>> >>> -- John. >>> >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
