Having a part library with GMD.... possible?

[JST]

Normally, GMD is incapable of working with a part library, as it has no facility for library maintenance, etc. All parts are normally always editable.

BUT, if you notice, you cannot do any editing of a part downloaded from this site and opened directly in GMD. You have to save it locally first. Until you do, the part of assembly is shown, but all the editing commands are grayed out.

That being the case, presumably the file is marked "read-only". If so, then a library part could be so marked and it could not be edited.

But if there IS a way to edit it, then there is a problem, because it would be marked to be saved, and either the save would happen, or it would stall due to being un-savable.

Likewise, if it is ever saved locally, which as I understand it should not happen, then the part would be both cut of from the library, and also completely editable.

OK, so far, by test, a read-only file is NOT editable from within the assembly, you get a notice that it is "locked by some other process". In a part window, all selections are grayed out. You ARE allowed to change its color in an assembly, but not in a part window. Saving the assembly results in "no action" to the part regardless of the change in color in an assembly.

That being the case, it SHOULD be possible to maintain a part library in GMD, with the parts unchangeable in the normal way. All the pieces seem to be in place. I assume that the (defunct?) "vault" system used this normal DOS facility to do the work.

Of course, there is still the pesky issue of "part name = OS filename = descriptor = Keyshot material". That's a bit harder to get around.

And, to really do it right, the program and the library database should work together to positively prevent changes. Just using the OS file marker is not sufficient, the parts should be further protected, since it is easy enough to modify the "read only" marker.

That gives no real protection except against casual mistakes. But at least it DOES give that much protection, and might be usable.

A PCB program, as I understand them, keeps the files in a "library" format, and serves them to the program through a conversion routine that only goes one way. Only the library creation tool can make a file of that format, so "saves" have no effect. The "fornat" may be nothing more than an added header, and a change to the file type suffix, of course.

 

[bigseb]

Am I missing something? Dumb solids?

 

[JST]

Am I missing something? Dumb solids?

Absolutely NO idea what you mean....

GMD parts...... Just ones you are DONE WITH and do not need nor want to change..... just to USE in further assemblies, with the assurance they HAVE NOT changed.

Unless of course, you ECO them.

 

[bigseb]

Am I missing something? Dumb solids?

Absolutely NO idea what you mean....

GMD parts...... Just ones you are DONE WITH and do not need nor want to change..... just to USE in further assemblies, with the assurance they HAVE NOT changed.

Unless of course, you ECO them.

Again... dumb solids?

 

[JST]

As in store them that way?

I suppose, but its a nuisance. A SILLY nuisance that needs a management facility that does not exist.

And even then, no possibility of making flexible, etc.....

 

[Ralf]

As in store them that way?

I suppose, but its a nuisance. A SILLY nuisance that needs a management facility that does not exist.

And even then, no possibility of making flexible, etc.....

"A fool with a tool is still a fool" ...words of wisdom ect...

 

[RocketNut]

"A fool with a tool is still a fool" ...words of wisdom ect...

+1 :lol:

 

[JST]

I am now a fool?

Whatever.

If there is some way that libraries work within GMD, some way that descriptors etc are NOT the file name after all, I would like to know it. i understand the old Vault was similar to a library in certain ways. But we have at least one other of us "fools" saying that his company would not take GMD seriously for just that reason, that the library was not "lockable".

Perhaps the pair of you worthy gentlemen can provide useful input concerning how to do that, instead of insults?

It looks like the lack of the function is holding back GMD, and I presume we all agree that we want it to succeed. So it would be valuable information to find out how to do a workable and "foolproof" parts library with GMD. Many of us seem not to know how, and presumably you do.

 

[bigseb]

Is not the one huge problem that marks GMD as "for home hobby use only", the lack of library features?

I thought you worked in Aerospace.... Hmmmmmmmmmm. Didn't you have ECOs? You could just "decide" that a part ought to be changed, and do it? Must have been Airbus, 'cause Boeing and Bombardier aren't like that....

One way works, and the other way "kinda works" until one fine day, it doesn't, the stuff hits the air-mover, and then you find out why serious companies DO use standard libraries and have ECOs, etc.....

JST, you can't keep criticizing others work methods. I have never seen a requirement for what you describe in my line of of work and for you to suggest that my work and that of others is borderline mickey mouse because of this 'lacking' feature is a step too far.

If you have a suggestion, cool. Suggestion are good and move the product forward.

 

[Lew_Merrick]

JST, you can't keep criticizing others work methods. I have never seen a requirement for what you describe in my line of of work and for you to suggest that my work and that of others is borderline mickey mouse because of this 'lacking' feature is a step too far.

As much as it pains me to say so, JST is making a valid point here. In a working group larger than (say) 3-4, the Standard Parts library needs to be controlled by some means to assure that (say) pneumatic valves represent those that will be stocked for general usage. They should only be revised when the supplier makes a change. Otherwise, they are modified before use components and are no longer Standard Parts. A "mechanism" needs to be in place to prevent an unauthorized user from overwriting a the Standard Part in the Library with a Modified Before Use version.

Only an authorized Librarian should be allowed to revise the files in the Library. You should be required to perform a Save As command before you can modify a Standard Part (and Rename it as part of the Save As operation. Other approaches quickly lead to chaos (with, as I said, larger working groups). Been there, done that, got the scars to prove it.

 

[bigseb]

That may be the case for some. Again, I have worked in these high-end industries and this issue was either not a problem or was dealt with through other channels.

Some companies may require a locked library. Not any that I encountered. And that doesn't diminish the work or make it 'hobbyist'.

That said, I think its a great suggestion.

 

[JST]

I really do NOT CARE what others do in their workplaces.... I DO have some opinions, ad I think they are correct ones. I want OPTIONS, I don't want to FORCE anyone to USE them. (I might think they are foolish if they do not)

My various employers wanted their parts and PWBs, etc to change only by ECO, and not otherwise, by accident or design. Giving everyone total access and relying on them to never make a mistake, is definitely not the way to do that. There were people who had as their JOB the maintaining of a correct and protected parts database so that everyone else could use parts in new designs and KNOW they had good information, with no "surprises" coming later.

WHY is it wanted? (skip if your mind is made up)

EVERY PCB program I am aware of with any pretensions to professional use has a locked library. Only the part librarian has "write access" to the parts, everyone else USES them, but cannot change them. EVERY STINKING ONE. And for a very good reason. with application to CAD.

If you have a standard part, you want it to be just that. Standard, unchanging, to be counted on. When you use the part in a PWB, you need it to fit, and solder correctly. And when you use a part model for an existing part with other new parts in a new assembly, you do not want to find out that someone decided the mount holes should be different, and changed the part, forgetting to put in an ECR for it. That wastes a lot of time when the proto gets assembled, at which time things do not fit, and there is trouble.

You cannot have people changing it, on purpose, or inadvertently. If you make a product, the drawings and manufacturing data for the parts in the product should likewise be unchanging and so forth. There are entire software systems for keeping track of these things, and prior employers have used them.

This is NOT limited to larger workgroups. Even with just one or two people working, problems can occur relatively easily. Nobody is perfect, which is why these systems exist. A LARGE company can easily afford a stand alone system protecting the database.

A small company usually does not want to afford it. But yet a small company often is the one which needs it the most, because there are often no redundant systems to prevent mistakes. It's up to everyone to do it right every time, no matter how rush the job, etc. That's not generally realistic.

Do many companies avoid that? Sure. And mostly they do "get away with it". It's those other times that tend to cost big money, In my experience, often more than enough to have paid for a program having a good library system available.

SOME basic way of marking a part as usable in any way, but not editable, would be a very good selling point, IMO, to companies using CAD extensively and with any concern for efficient work and data integrity. We have already had two votes for that besides me, so it is obviously not a stupid idea.

WHAT is needed?

It's not that hard.... I think the following would be a good start, and might be nearly all that is needed within the program. If you want more, you are probably a candidate for a dedicated external program. None of it exists in GMD now (that I know of), but all credible PWB programs have most, if not all of this.

1) A means for entering a part in a library. For making it a "library part", and for creating a library. You might have a central library, or you might use a local library, or you might do both, moving parts to the central one when they are vetted as "official". It could be as simple as saving it as "AD_LIB" ( or "AD_LAS", "AD_LPT", or whatever system is thought best for storing library parts and assemblies), but needs to be an authorized save.

2) a means for having parts in a library location but yet easily accessible from inside the program, while maintaining the new parts in the project area. You select source of part, local or library. You could select the specific library for any project, there might be more than one available. BOTH local and library should be available directly without changing source directories etc, it should be a plain button to change from one to the other

3) A means to enforce no editing of parts from the library. You have to "save as" first, locally, THEN you can edit all you want, it's no longer pretending to be the library part.

4) A means for disallowing saves TO the library without special access key. At least for the central library. Local libraries could be locked or open. For any library, only a library extension is allowed to be saved.

5) fixing the crazy default save and source location that exists in GMD now. It is CRAZY EASY to save a part in the wrong place, and the type of save it is seems to affect that. You can have parts default to local, but saving a package or export or JPG may result in it going somewhere different. That cannot be tolerated, the saves should go by default in the working directory. Even save-as. It is a s simple as a "define working directory" command, that sets the default or everything at once.

6) VERY MUCH preferably separating the visible part description and visible part number from the filename as viewed from within the program when selecting parts (most PWB programs do this, so it's not that hard). This is not truly required, but would be extremely good. So you would see "<description> , <part number>, <filename> in the selection window, and could therefore select parts by any of those. Being able to re-order the list by whichever of the three you want would be VERY helpful. Separating parts and assembly lists would be VERY helpful. But neither is essential.

7) Preferably having the program refuse to save a library part anywhere else, requiring a "save as" to a new name. This is not truly required but would be very good to prevent confusion. It's just short of really essential. (Obviously a "package" would need all the parts, so that might be an exception, but it could save the library parts to a different location and keep them as library)

Edited to add point #1, which is obviously a requirement (so obvious I forgot it)

 

[jfleming]

I agree entirely. We are a small outfit here, with only two users who access our "Standard Parts Library". We both know not to change stuff in there, but you never know.

 

[bigseb]

Two and a half years later and I have done a total 180 on this. My apologies, JST. This would be a handy (and pro-level) feature.

 

[JST]

Thanks....

As I have mentioned elsewhere, there IS a workaround that solves some other problems with Alibre at the same time.

IF Alibre had the ability to SET a "working directory", so that ALL saves and opens came from that directory, of course that would solve the issue of files that go "into the blue", or end up coming from the wrong source...

AND, if the setup were that one could over-ride the working directory on a "one-time" basis, so that it defaulted immediately back to the working directory, then one could open a part from a library, and know that it WOULD NOT be saved back there. You would HAVE to save it locally unless you did yet another deliberate over-ride to save it to the library.

That would not be perfect, but it would be lots better, and since it would solve more than one problem, it might be able to get farther up the "priority list".