> -----Original Message-----
> From: Ian Wilson [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, March 11, 2004 1:17 AM
> To: Protel EDA Forum
> Subject: Re: [PEDA] The road to DXP, one mans story, warning 
> long post, (was)2004 DXP Looks Great,
> also long reply - generally in agreement with John.
> On 12:21 AM 11/03/2004, John A. Ross [Design] said:
> ><..snip..>
> >In a single user or workstation environment where the whole 
> design is 
> >driven/managed by one person, it is workable and very flexible, an 
> >improvement, but start expanding it to other users, then the project 
> >system without CVS is 'over flexible' and in some cases to risky.
> When the DDB came out is was almost universally denigrated.  
> Then lots of people went quiet about it and now we have 
> admissions that people liked it. 
> (I am not saying you were one of the people that changed view 
> over time;  I was though).
> DXP, and P2004, uses normal disk files rather than the DDB.  
> The project file is a simple series of links to files along 
> with configuration info - all very much like a software 
> development environment as you say.
> So what in DXP/P2004 makes it *worse* than traditional (disk 
> file-based) systems for configuration control?


A lot of other tools I use have a fixed folder system, although usually
the folder locations can be user defined by config menu or file. 

When I get to the question, on my checklists for documentation & risk
assessment, of how I can be sure the correct files in the correct place
and keep project integrity for archives and portability I have to answer
that as the project system is 100% link based, and can be corrupted
during normal use by simply forgetting some workaround or a click of the

You mentioned one point below but when you have 1st user + x more, or
multiple projects running at same time, you need to have your wits about
you, its scary. The additional overhead of managing this is nuts.

> I find that, with DXP/P2004, I am more likely to muck up a 
> project when using the Save-As command as it causes the 
> project link to change - which is often *not* what I want.  I 
> know tend to use the Save Copy As command and manually deal 
> with the project updates.  This is irritating and a possible 
> source of problems.

Correct, corruption to the project structure should not occur, it is the
foundation of all we do, in this case it is definitely an area that the
software should be working for us to ensure integrity, not the other way

> It is possible to include one Sch file in multiple projects.  
> I am doing that on a design right now.  One Sch sheet exists 
> in three PCB projects.  This does take some management and 
> care, but does have advantages. It is possible to design an 
> aspect into the sheet that is inconsistent with one of the 
> other projects.  But design re-use always has this issue.  
> All these projects reside in the same folder but I am 
> considering splitting it into separate folders.

As you know I managed to do some design reuse in 99SE that worked fine,
some manual tweaking yes, some rigid procedures on Cref/net name
management & sheet numbering needed but it is do-able.

But what I always did, is keep the sheets in another project and treated
them as a 'sheet library' if you will. All sheets and PCB blocks were
kept in that one container for picking like parts.
> Would you prefer to see me forced to copy that Sch sheet 
> three times and so now risk a design branch or would your 
> rigid folder/project relationship have some means of dealing 
> with this?  I can see advantages both ways.

Yes, but not manually, the software should do it for you when it is
imported to the new project, when used the files should be copied to the
project container that was to include them, and worked from there.

I think you already seen the risks, if one sheet is changed, it will
affect all projects it is included in, even if the change is not needed
in say 1 of 3 projects it is re-used in.

In another posts, as well as the folder structure, I also requested a
property be added to the SCH page itself to enable\disable referential
updates. This would be a benign change to the SCH file structure really.
When the re-used sheet is imported into the current project container, a
prompt to enable\disable these updates on import, would be all that is
required initially as a user check. No 'silent' changes. Should be
default, disabled.

This additional sheet property would both allow sheets to be updated
under user control, or disable updates because of intentional, project
specific sheet changes like component values or fit/not fit options. 

> I have a project library that is building as I design the 
> three related systems.  This SchLib is part of each of the 
> three PCB projects (project library, not just a PCBLib 
> installed in the Libraries panel). What do you see as the 
> config control risks here?  If different users are each 
> dealing with a separate one of the related PCB projects there 
> could easily be ugly contention.  Does DXP/P2004 do anything 
> that makes it worse than traditional systems or is it just 
> worse than a DDB with user permissions?  Of course user 
> permissions can be set up at the OS/file level
> - does this require a different and possibly more difficult 
> management layer than the DDB solution?  Does it not work as 
> well as the DDB solution? 

My library management procedures might be different here as we have in
house production low-mid volume, so I need to manage a part number and
library name system to match placement machines, vision libraries etc.

Manually locking files and managing permissions on an OS level would do
it, but it is another manual process and procedure that needs to be
handled and I found no easy way to do this.

Libraries can exist as a separate entity, integrated libs go some way to
this. All I suggested for libraries that when a project is closed, a
snap shot of any shared libraries used, be copied to the project
container for archives, in case any parts are modified.

> As you have pointed out the situation is different for a 
> single user environment.

It's a mater of handling the risk when giving up control of your hard
work to other people who may not care quite so much about it.
> There were *lots* of complaints and some reports of data 
> corruption when using P99SE in multi-user environments.  I 
> can't recall too many good comments for P99SE as a multi-user 
> system - where there any?  I think this has been suggested as 
> a weakness in all the Protel series.  Still we should 
> encourage things to be done to get it betterer (how is my grammar Abd
> ulRahman?)

I seen these, but generally I did it differently to avoid them, I did
not force the use of shared libraries on a server. 
I maintained one library which was locked for changes. 
Users were updated every 7 days by either a scheduled task on the server
which copied the latest issue to their default lib location (same for
all users). In any event the latest libraries, were uploaded to our
intranet, and all users get email notification of new updates

DDB was not perfect, but it enforced all objects to be in the same

> > >From a GUI view I found the excessive use of panels in DXP for the 
> > >same
> >or similar tasks a risk, some things could be done & not 
> applied, some 
> >could be undone. The panel organisation was not always 
> logical causing 
> >additional (unnecessary work & thought) I think some issues 
> were logged 
> >for this and it also appears on the DXP/99SE comparison list on your 
> >home page.
> Dual monitors, more common these days fortunately, is a real 
> help with the panel based system.  I like having as much 
> screen space for work as possible.  Being able to have the 
> panels on the right screen works OK for me, but it certainly 
> does take some getting used to remembering which panel is 
> used for what.

I always used 2 x 19" beasts at 1600x1200 anyway, but the panels could
easily be rationalised a lot better by making better use of tabs within
them, instead of more panels.
> >This is a very common fault in most software as these 
> feature types & 
> >GUI are usually decided by Developers, rather than users, developers 
> >are normally too close to realise they are over-engineering or 
> >misinterpreted the users suggestions (Cannot see the wood for the 
> >trees).
> >
> >Hence DXP has the feel of a software IDE, rather than a SCH=>PCB 
> >platform, which will not sit well with anyone not used to software 
> >IDE's or trying it for the first time,
> I agree that it does look like a software IDE (why the 
> developers used the word "compile" for processing the Sch 
> project I don't know, not a good choice IMO).  For those of 
> us used to it that is fine.  Without being unsympathetic to 
> those that happen not to have the same background, I am not 
> able to comment on whether it is difficult to learn but it is 
> certainly different from previous Protel versions.  I will 
> have to watch some other people who are not big software IDE 
> users and see how they cope.

I struggle, not with what to do, but to get it to be a natural flow

It is frustrating more than dangerous, but in the sub-conscious it makes
for a bad bias towards what the software can offer and increase the
energy expended by the user to keep the frustrations from boiling over.

At least after adding the word compile they left the Update PCB command
intact :)

> Yes first impressions are very important.  My first 
> impression of DXP was "lots of eye candy", and I am not a big 
> eye candy type of person.  The eye candy has some subtle 
> implications, the main ones being more mouse travel to get 
> things done (at least until us users started making 
> suggestions for improved dialog control tab ordering), and it 
> being harder (than P99SE) to find editable things in many 
> dialogs - this last one still irritates me.

First thing I tried was the 'non-manual' test, can I drive it
productively without picking up the manual?, no I couldn't, not well

As you mentioned above, the 'compile' command I did not immediately
associate with SCH/PCB drafting, I initially thought it was part of the
FPGA/PLD tools as the GUI is 'shared'.

Markus went on a DXP training course and said it helped him a lot to
make the change and it was well worth it.

Andy, our resident Pads Guru found it easier than me to look around, he
did not like 99SE, but liked the feel of DXP and how it worked, he was
able to drive the beast better than me and in less time, or he was just
impressed with the eye candy as the Pads GUI has not had a facelift for
a long time :-)
> >I do use multiple tools, my tool of choice for design entry 
> is Protel, 
> >I measure their respective worth\benefits to me in a few 
> ways, some of 
> >which may only be a benefit to me, as they are keyed to the 
> way I work, 
> >how many clicks to get everyday tasks done, process time to 
> avoid error 
> >for common tasks, how much time I need to spend learning new 
> tricks to 
> >get it to work, investment in retraining vs. frequency of use of new 
> >features and so on.
> So why Protel for design entry and do you prefer DXP over 
> P99SE?  Do you prefer P2004 over P99SE?
> >I gave up with the router in 98/99/DXP almost from the start and 
> >decided to waste no more time on it, I use another layout/router 
> >package for boards that need it.
> I have not re-tested my standard router test PCB.  I am 
> beginning to think that the board is not a good auto-router 
> candidate as I am not seeing the great strides forward in my 
> testing.  I will have to re-run the test.  I have never had 
> any great success with the Protel routers.  The German 
> spectra-clone looks very interesting but my trial ran out 
> while I was on holidays (silly me for installing it before 
> going away!).  Maybe I will send my standard test board out 
> to a few people and we can compare the results from P2004, 
> Blaze, Spectra and the clone.  Maybe we should, as a group, 
> put real designs through this sort of test and post the 
> results for all to see - I am happy to donate web space.

Good idea, perhaps some levels of common user prepared PCBS for router

I am sure most companies spend a lot of time on their own demo PCBS to
get the best from their own routers.

I have Blaze here, but my copy of Specctra is not up to date (V9) and
the HW key is off-site just now, but its available. I can always upgrade
it if needed, its only $$$ after all.

> >The above is just some thoughts of mine, Ill skip the temptation to 
> >rant about the query system, as my issues with this system is mostly 
> >due to my own failings in understanding\attaining the disciplines 
> >needed to drive the beast efficiently.
> As users, should we have to change the way we work?  Whose 
> "fault" is it when users have trouble with technology?  Is it 
> reasonable to ask users to learn a new skill?  What are the 
> paybacks for the user in learning the new skill?  These are 
> difficult issues that HCI and human factors/ergonomist 
> practitioners continue to struggle with daily.

:-) Guess that would need to be a vote or survey based on true cross
section of users as well as some who have cross graded from other tools.

For me, the query system is an additional skill I will only use with
DXP, so I need to bend to the way the tools work as well as the overhead
of using the new skill.

I do not mind new skills, but they need to be used, practised on a
regular basis, required for all my daily tasks, or most of them, and be
natural to be productive.

For me its is hard is all I can say really.
> Is driving a car more complex and difficult (higher 
> processing load) than riding a horse?  Why do most of us not 
> use horses to get about?  Why did we (the community 
> collectively) decide to skill-up and learn to drive a car? 
> So we can get places faster, basically. (Come on Ivan I am 
> sure you can come up with a better analogy to shoot me down.) 
>  I am quite interested in this sort of thing and I think it 
> bears not an insignificant weight in the success and failure 
> of us technologist's products.

Do not quite now what to say.

> Anyone still here?

Always, still patiently waiting for P2004, perhaps I will upgrade one of
the other seats here, might be quicker than waiting for the upgrade :(

Well, lot of stuff above, I think the router benchmarking idea and the
project structure discussion are better split off by themselves to keep
I will try to rationalise my ideas on what I see the project management
should be like, in a condensed format, a bit later. 

Need to release a couple of PCBS for manufacture now, so need to work
some more....


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
* Contact the list manager:
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
* Browse or Search previous postings:
* http://www.mail-archive.com/[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to