My lesson for the week, (or how to not lose 3 days trying to get Protel99SE to behave itself)

From time to time I run across a problem which is a real stumper, and ultimately fruitless searching online for others who might have encountered the same issue, I will bang my head long enough to solve it myself.

So, I present an example of my own stupidity in the hopes that future users will be able to avoid feeling this retarded...

A few days ago I fire up Protel to finish up a board redesign. The design had seen a couple of bizarre field failures which needed fixed quickly. This meant I needed to get new board files out ASAP. I go into the CAM manager and try to get it to generate new gerbers and the damn thing crashes. No warning, it just closes Protel. This hasn't happened to me in years, and never under WinXP.

Several attempts to generate gerbers gave duplicate results. I had Protel do a "repair" of the .ddb, no difference. So I uninstall and reinstall Protel and SP6. In the process I notice that some .ddb's will generate gerbers and some won't. I'm now wondering if McAfee is messing with my install, or if some WinXP service pack hosed my system. I need to get this file generated and boards out, so I backup everything and reformat and reinstall Windows XP. May seem harsh, but it's faster most other options. I now have a nice clean system which allowed Protel to crash much more efficiently. ;-)

I notice that the crashing is different now. Instead of just closing out, it's giving the following popup "Access violation at address 40004AF0 in module vcl50.bpl"

Nice. Now I have something to work with. A few searches later turns up that this is a Delphi runtime file, circa late 90's. I get my hands on a newer version and replace the old file. No difference.

A little more searching dredges up some instruction on doing a clean reinstall of Protel (such which additional files to delete and where they live) and I follow this procedure. Reinstall for probably the 10th time and get the same results.

So I'm wondering if one of my libraries is corrupted. I make a small board from a fresh .ddb (I did this several time prior to reformatting the HD and it didn't help) and start adding in components one at a time, but now I'm able to generate CAM files without trouble. It's at this point I notice something. I had placed the new test .ddb directly into my "my documents" folder instead of in the nested folders where I keep my working files normally...

A few tests later this is confirmed as the source of the trouble. While Protel does support long file names, the error handling for exceeding the

255 character limit is buggy. In addition to the "my documents" folder being 2 folders deep itself, the filenames within the .ddb are included in reaching this limit.

The solution was to simply move the folders back a little to shorten the filenames. I suspect this to be the source of several problems I'd had with Protel in the past including the "Board in 3D" function crashing.

Just glad it's fixed. Now if I can only figure out why the advpcb.txt does not get updated properly for those pesky text designators...

Chris

Reply to
Christopher Ott
Loading thread data ...

Christopher, I have never ran into that 255 character limit myself but I am not surprised.

I have run into a similar limit of approx. 128 characters for Camtastic

2000 DE usage. In that case you will see a bunch of overlayed white highlighted boxes and Xs or something of the sort throughout your visible Gerbers, no crashes. Note that at that time Camtastic had just been bought by Altium/Protel but the original Camtastic crew were undoubtedly responsible for the directory chain limit.

What is your other problem with advpcb.txt? I am not even familiar with that filename, let alone have I ever found it to be related to Designators.

--
Sincerely,
Brad Velander.
 Click to see the full signature
Reply to
Brad Velander

Sounds like a bit of lazy programming.

Could be a legacy problem from older versions of Windows.

Reply to
Marra

It took me ages to find that out as well!

I think the same thing happens (or at least used to happen) with microchip's MPLAB if the file path is too long.

Reply to
Robbo

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.