Near disaster with PCB design

Today the PCB design component of my old CAD program CircuitMaker

2000 crashed as it occasionally does in Window 7 (it never did in '98, Me & XP). I terminated the program with Task Manager but when I started the program again and tried to load the PCB I was working on, it was blank. The file size was 0. The auto backup file showed the normal size but it too loaded as a blank. This is the first time this has happened.

The design is almost finished and is made up of about 150 components, a mix of TH and SMD parts tightly packed together. I thought I'd have to start again from a rough layout that I's discarded but not deleted yet.

Then I renamed the auto-backup (.BAK) to current (.PCB) and everything was still there. Whew!!

Reply to
Pimpom
Loading thread data ...

I got an old XP box, no NIC, no sound, but it does what it does. Any file c an be put on a USB and then I can, well many things including printing it. All that image shit seems to work better in XP. I use that sometimes in my advertising and sometimes in my correspondence(s). The Win 7 one is sitting on top of ... where is that thing ? Hmmmm.

Reply to
jurb6006

Pimpom wrote in news:Z8NyG.19183$WT.11177 @fx39.ams1:

My movie collection is on two drives. Any CAD files I generate also get archived onto that seoond physical drive. It is just a good practice to get into, but also an easy one to be lazy about.

Reply to
DecadentLinuxUserNumeroUno

Next time, copy it instead of renaming it.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

I'm paranoid about things like that. I *hate* to do tedious things twice. I do explicit saves a lot, and dump a copy to Dropbox at least once a day, usually more often.

How much total time did it take to do your layout?

In PADS, we edit a developmental schematic from, say, xxxxA4 to xxxxA5, and do an ECO that brings the PCB file from A4 to A5. So at any point, we have all the old rev steps, as sch and pcb files A1, A2, etc. One little delay generator board that I'm about done with now is A22. All the old ones are saved (on at least three computers!) until we release the official rev A. The later edits are usually very small tweaks.

We email the files around, too, for reviews and shared edits.

I did lose some work last week, from personal confusion over how PADS handles library parts. But that took 20 minutes to fix.

Open schematic A16

Delete everything on one page, including bad parts

save sch as A17

undo delete, one click

save sch as A18

Eco the PCB from A16 to A17 then A17 to A18

which forced PADS to refresh the tangled parts from the correct library.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

We version-control essentially everything with git--about 70 repos so far. I do several commits a day to prevent breakage.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

I live on the edge. One hard drive from at least 2003. No back up. No printed copies. :)

Just kidding. Everything automatically backs up to the QNAP TVS-673e server, and select d irectories then get backed-up to Google Drive. That at least ensures we do n't lose any files, but it also perfectly ensures that any corrupted files get copied as well. At least the latter has never been a problem for us. ......so far.

Reply to
mpm

For less sensitive stuff, we use a lot of private repos on Github and Gitlab as well on a couple of local NAS boxes. Scripts keep them in sync.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Our ultimate backup is to a write-once terabyte USB hard drive, everything that matters, every three months. The drives are stashed in various locations in California.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

Sure. I renamed the backup after it had been backed up elsewhere.

Reply to
Pimpom

I do backups too, but not as meticulously as I should. I save every few minutes or as soon as I've made a significant change.

A long time. I probably could have finished it in a couple of days, a day perhaps if it's a real rush job. Otherwise I like to tweak things long after it's functional - no long meandering tracks, as few vias or jumpers as possible, no large blank spaces, etc.

Reply to
Pimpom

Likewise, for my personal schematic/PCB projects (done with KiCAD). A commit after every set of changes helps maintain both project integrity and a sense of history. If I find that I've done something Bad, I can always rescue individual files from an older commit, or check out the whole older commit and start again from that point.

It's great to be able to have multiple branches to try out different modifications and ideas, then merge the one I prefer into the master branch.

Having an off-site repo mirror is also very worthwhile... a simple "git push --all offsite" copies all changes and new branches/commits to my offsite mirror via Secure Shell. If my laptop SSD decides to commit seppuku, I won't lose very much at all.

Reply to
Dave Platt

We use Github and Gitlab for a lot of stuff, as well as several computers and a couple of NASes. Git is good for that--you don't have to connect your backup server to your file system, which is a no-no in the age of ransomware.

I'm not super worried about most of my design info--the number of people who would know what they were looking at is not very large these days, so private cloud repos are mostly OK.

For stuff covered under NDA or court protective orders (such as expert reports on noninfringement, which contain both parties' confidential info), I sometimes use gpg with a 4096-bit key to store an encrypted tarball someplace inconspicuous in the cloud.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

How do you keep track of who did what when, and especially why? Multiple branches sounds hazardous to me.

--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

There are commit messages, tags, and several wonderful functions:

git diff git whatchanged git blame (who changed what when) git cherrypick

And so on.

You keep one master branch, owned by one person a la Linus Torvalds. (Git was written by and for the Linux kernel developers.)

Cheers

Phil Hobbs

Reply to
pcdhobbs

As I said at the start of my posting, "personal" projects, meaning that it's just me working on them.

Each commit stores a commit description (entered by the committor, me in this case) as well as the specific set of changes made by the commit. The "git log" and "git show" commands can summarize the changes that have occurred, the email address of whomever made the commit, the date and time of the commit, and (in the case of the latter) the specific lines changed.

For projects with more than one developer, the usual approach is for there to be a "master" branch, which is the officialy-approved version. When working on a new feature, or a bug fix, or etc., the working model is:

- The developer working on it will check out (create) a new workbranch. This is an exact copy of the master branch.

- Do one or more commits to do the work. Test locally.

- Push the new branch up to the shared central repository. This doesn't affect any other branch.

- Propose a branch-merge, and have it reviewed by others. The methods for doing this vary by project and company and server.

- Reviewers look at what's being proposed, and authorize a merge of the workbranch's changes into the master branch.

- If conflicts are identified during review or merging, the developer makes revisions in the workbranch and pushes the change up for review again.

- Once the workbranch change is merged into the master branch, the workbranch itself is typically deleted, as it is no longer needed. All of the commit records and comments and documentation will have become part of the master branch.

- I also "tag" (label) individual commits, when they correspond to an outside event (changing the project version number, sending Gerbers off to the fab, etc.). Once that's done, I can always go back and retrieve a complete, consistent copy of the project at that point in time via a simple "git checkout" command. Very useful for (e.g.) comparing simulations of older and newer versions.

Under git (and Mercurial, a somewhat similar revision control system) creating and deleting branches is a lightweight operation, with little space or time cost.

In my experience it's less hazardous than "make a copy of the working directory and edit it" approach to trialing things. You get the same flexibility, and much better control and accounting.

Used in the way I've described above, it works out very well. It's the standard development methodology used for some seriously huge dozens-to-hundreds of-developers projects, including the Linux kernel, numerous of the GNU tools, and most of the software developed at certain large Silicon Valley companies whose name you'd recognize.

On the small scale I work at personally, it works very nicely for the text-based schematic and layout files that KiCAD reads and writes.

Reply to
Dave Platt

How do you know *why* something changed?

How does diff or whatchanged apply to a schematic or a PCB?

Right. To manage text files.

What is a "master branch"? Sounds contradictory to me. In the software biz, quality is achieved mostly by test, and it's OK to finally get something right on the 12th try. PCBs are different.

We iterate PCBs carefully a step at a time, and ownership is transferred formally. Same with manuals and such.

--
John Larkin         Highland Technology, Inc 
picosecond timing   precision measurement  
 Click to see the full signature
Reply to
John Larkin

You're not missing out on anything if you have a process that works. git can be complete clusterfuck when it goes south or you have merge conflicts or something goes wonky between two branches people are working on.

It's a product so sophisticated it lacks something as simple a undo on a step by step basis.

Reply to
Cydrome Leader

No, it doesn't. You can go back to any commit in the history with one command.

Like any version control system, including JL's fully-manual one, it's not a substitute for thought or self-discipline, and it doesn't know anything about application-specific or binary file formats.

I doubt that PADS or Altium can take two board files and do a diff on them automatically either. They certainly can't tell you what the designer was thinking at the time.

So either way you need a document with that information in it. Ours are called notes.txt for simple things, and for more complicated ones (such as actual products) we have a designDoc directory with Markdown files containing all that stuff. (Markdown is a simple formatting language for text files--many editors render it nicely with headings, bold/italic, section numbering, etc.)

We also keep scans of the marked-up schematics board files when going from version to version, as well as a text file of change notes and rationales for each one. (Today I was doing the last markups of the schematics for our new SiPM product--we needed to add the ability to work with the On Semi MicroFC parts as well as the Hamamatsu ones.)

I have git repos that stretch back several years before git was even written. (My previous version control system was snapshot zipfiles--I wrote a script to convert each one of those to a git commit.)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

In developing pcb xxxx rev B, the files are xxxxB1.sch and xxxxB1.pcb, and so on in sequence, with the final released files just xxxxB.

On the schematic of, say, B3, on the title page, with the block diagram and table of contents, there is a giant "B3" and some text below saying who did it when and what they did. Those sch and pcb files are archived forever. There is also a design notes doc with the more serious math, in a design notes folder for that board.

PITA, but you need that stuff.

Right. I generally do redlines on paper and hand them to the layout person. They get scanned and saved.

How many sheets is that? One that I'm doing now is 31, and the pcb is

10 layers. A few of those schematics, printed out, really weighs down my backpack when I hike up the hill to my car.
--
John Larkin         Highland Technology, Inc 

Science teaches us to doubt. 
 Click to see the full signature
Reply to
jlarkin

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.