> -----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?
Ian 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 mouse. 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 about. > 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 automatically. DDB was not perfect, but it enforced all objects to be in the same container. > > >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 (productive). 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 anyway. 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 benchmarks. 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 focussed. 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.... John * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
