GrabCAD Community User Group

Exactly. You may just as well model a chess board and then upload every possible position of the pieces. It would bring nothing new to the 'board', but it would fill GrabCADs server with repetitive models.

Exactly what is happening here....I tried to understand why...I believe it has something to do with an uncontrolable urge to hit the post button, or how to stay no:01 in "most uploaded"...Both cases are SAD, very SAD...

I did my part and cleared about 75% of my models from this site a couple months ago, so our dear friend could have more server space for his works of art!

If it is to be answered in a straightforward manner, your question must also specify how many instances of each prospective object may be purported to comprise further models: from 1 to 4 chairs; 0 to 2 book cases, etc.. Nonetheless, the possible combinations of singular instances of each prospective item is calculated by simply multiplying the number of variations of each book case, desk, chair, and part by each other. In other words:

100 × 100 × 100 × 100 or 100⁴ = 100,000,000

Similarly, if none of each item were to comprise a further prospective model, the calculation would instead be:

101 × 101 × 101 × 101 or 101⁴ = 104,060,401

At an hour per model, 15 hours per day, and 5 days per week then, your one-hundred-million prospective models would require 1,333,333 weeks or 3,652 years, merely to make one each of the few specific combinations your drawing may intend to represent.

But for example, if your question were further to allow from 1 to 4 chairs as prospectively different models, we would multiply this 100-million total by 4 — making the prospective number of prospective models 400-million. And so forth.

So I don't believe you have to worry about the cited extreme, even as far more practical cases may indeed impose substantially injurious strains upon site resources, if and only if members are downloading the permutations.

In regard to the assumed bandwidth consumption then, note that as storage is static, people have to want the models if they are to impair download resources. It's difficult to assert an offense then, if the models are desirable, for many models have few downloads. So the assumable offense is far more remote than prospective consumption of download resources, if in fact people want the models. Yes, provided access does consume some resources. But it is only the model which is never or rarely downloaded, which is truly wasting no more than the static resources of storage.

Yet I'm afraid your question may raise a possible misunderstanding.

If I may bloviate then, liberal interpretations of your question and its implied complaints might allege that just about any other collection of extremely similar models may transgress upon site intentions.

Especially severe transgressions would be collections of largely unnecessary models, especially if the usual tendency would be to assume the models are readily created. You also assume there is a motive to artificially inflate download scores. There may be, in some quite different cases. But in the case of libraries of similar models rightly belonging together, we may understand instead that posting the models individually would instead be far more untoward to both site and member purposes, especially if end users can readily download only just what they want. Which of course, they can.

First or all then, let us understand that wherever collections of models are posted in a single upload, GrabCAD instead wrongly counts the entire upload as a single "model." Obviously then, it is hardly possible for a member to inflate their download count.

You might also be underestimating the value of collections of extremely like models to engineers, who often rely upon exacting variations of leadscrew diameter and pitch, bearings of specific dimensions, fasteners and washers of every size and type, and so forth. Some of the parts we rely upon are available to us. But other vital parts are instead extremely scarce, or, even where we may find the occasional instance, it may not meet our standards. Though the possible variations of each model of a series of bearings for example may not justify posting entire libraries of the type in your mind; and while it is true that most engineers will only use a few bearings of many prospective series across their entire careers (implying such prospect waste of site resources); the value of the library to every engineer who uses just one bearing of a series is that, 1) they would otherwise waste vast time finding even just that one bearing — which more often instead, is nowhere to be found; and secondly then, 2) if the surprise library they instead locate is of sufficient quality, it further eliminates the regular need for further work, merely to bring separate models of separate styles into the conformities we may likely prefer in our eventual assemblies. Yet the third case, 3) is that after wasting the substantial time of the research which fails to find the intended model, we are forced to produce it ourselves.

A library of the bearing type not only eliminates all of these issues, it serves as a virtual catalog of what is available to their purposes. Work can simply continue without interruption, because we have at our fingertips, everything that we may need to incorporate in our work.

Yes, to the outsider or non-engineer, the nuances between bearing designations may not seem to justify posting the library. But the library solves all of the engineer's problems, as they cannot be solved otherwise. In fact, this is the only reasonable purpose for creating the library. Not even the original author who is compelled to do so may ever use many of the bearings they ultimately create. But (only) if they create sufficiently efficient means to create each distinguished model, the most rational thing to do is to produce the entire library, simply because we cannot say which members of the library our work will ever require.

So, these are the very reasons that libraries, most particularly of scarce components, are vital to those of us who may indeed, ultimately need no more than a few of them.

The tone of your prospective complaint appears to infer there is some unfairness to download rankings in a further presumption that such arrays of components may be easily produced.

Yet the only reasonably efficient means for producing such libraries is such comprehensive parameterization, as is seldom exercised elsewhere. Otherwise, the author will often be forced to do such a vast and intricate volume of work again and again, that they will most likely resort instead, to producing only the much fewer permutations that they immediately require. Each time they return to a model they must revise to a further permutation, they must get up to speed again. The price of the styles of work which are not conducive to producing libraries, is far steeper per model.

As far as I'm aware from the many tutorials and examples I've seen, very few people actually engage in parameterization much at all. If they did however, we would certainly see many deserved complaints regarding the weaknesses of our software. Users don't even know what strings are. Much less do they miss the routine tools other such development environments regularly feature to process strings, or even merely to assign a processed or unprocessed string to the text field of a label feature. These are blatant weaknesses that skilled users of any similar wares will sorely miss. But it is hardly possible even to initiate yourself to parameterization, without encountering what are often fatal weaknesses. We ought even to be able to automate filenaming procedures as reflect the parameters of our models. Thus the lack of complaint against the lack of so many such vital features, itself infers not only that deep parameterization is rarely exercised, but also that the difficulties imposed can easily be vastly underestimated.

So I mention these facts, only that you might understand first that very few people ever truly exercise the exhaustive parameterization which is indispensable to generating the libraries your complaint may mean to target; and secondly that on the contrary, the challenges are hardly easy (as your post appears to complain).

If many people were truly versant in the required extents of parameterization, we would at least have people shouting everywhere, that our equation editor doesn't even succeed in deleting all the equations we select for that purpose. You may roll your eyes, and think... now why after all would anyone ever want to delete their equations? Well, the obvious fact to anyone who has ever tread the required waters is, that the parameterization environment is so bereft of vital functionality, that effective users are forced to use exterior tools to process their equations.

Why?

I'll give you just one example:

In the natural order of merely devising and revising sufficiently meaningful reference names for our equations and constants (which are distinct from "equations," but which our software calls "equations"), the creation order of our equations becomes a nightmare to negotiate if the environment (our software) provides no tool or automation which will list our equations in alphanumeric order. All reasonable development environments provide functions for alphanumerically organizing any such body of constituents. I've written them myself many times; and so indispensable is the functionality, that I believe no reasonably proficient or responsible engineer would ever advocate or dismiss their omission.

Well, you can only wonder what the hassle might be, if you haven't ever engaged in the work. You see, the equation editor is a tool for building equations, which of course incorporate further equations in their operations. So, as you manually create an equation, the editor constantly presents a list of your remaining equations to be selected as the next prospective variable of the present equation. You are therefore regularly selecting your other reference names from this list; and so, if the list cannot even be organized alphanumerically, you can easily end up reading thru a list of 50 to 150 equation reference names several times before you discover your own equation — which your eyes would instead find immediately if our software provided the mere mundane and regular capacity to organize our own reference names.

The same preposterous faults pervade the general organization of the equation manager. Yes, there are column headings which allow you to alphanumerically organize the display at that moment. But as you add further equations, they are not automatically organized as well... and so, you have to keep clicking the tool to re-organize them as you create them. But they're still not organized in the popup list from which we would use them.

You can't even rely upon the environment to restore its previous state when you open the document. You must disable automatic rebuilding if you have any hope of working expeditiously, for particularly in vast assemblies, you can wait several minutes, merely for control to return to you. Each time you modify or create an equation?

But with automatic rebuilding disabled, every further equation or revision can raise dozens of fraudulent errors which you can only resolve for further work, by manually rebuilding the project.

So, what's the point?

But the purported errors don't even exist, when you can clear them by manually rebuilding the document.

Obviously, proper engineering would not attempt to validate an emerging body of equations in whatever respects require rebuilding, without rebuilding at least in the background.

But these are all indicators not only of how much is awry, but also how much further trouble must be negotiated to succeed in exhaustive parameterization.

No good or truly useful environment suffers these amateurish faults. You're screaming "That's right!" if you've ever engaged in no more than the most rudimentary extents of parameterization, because the environment is so primitive and malformed as to infer it might rather be designed instead to prevent comprehensive parameterization. Not even the possibility of processing strings???!

Please.

Those who prevail over these issues are few. But this means the people who are truly aware of these difficulties and irregularities are equally few; and that the rest of us may readily underestimate them.

So, why am I constantly deleting all my equations?

The constant need to reorder no more than the order which your equations are listed in the manager, means it is more conducive to operate on your equations with an editor which is instead intended for software development. The style of work required, means that any work you do on your equations (parameters) in your CAD software must be exported to a concurrent, separate instance of the "equations" parameters. You perform much if not most of your work there. Then you use the available tools to externally reorganize your equations as needed (and as your CAD software has no power to do), so that after you re-import them to your CAD software, you always see your equations in their proper order.

All that for so little, because it so soon becomes atrocious to operate upon our equations otherwise.

So you get your equations back into your CAD software by importing them. But owing to further faults and inconsistencies, it is not "safe" to simply import them without first deleting all of what's there. A further preposterous fault of the manager therefore, is that you can indeed multi-select the entire body of equations as you would expect. (Well, not quite as I would expect, because the selection behaviors are hardly consistent with any other environment.)

But every first time you delete them, the process instead leaves one equation — which you have to select again, if you are eventually to successfully to delete it.

Great stuff.

Here we may indeed part ways, because this blatant fault literally forces you to do hundreds of further times in a day, what you ought to have accomplished in one straightforward process, each time. There's no excuse for any of this. It's all hugely wasteful. But again, if people were truly exercising comprehensive parameterization, there would be a huge uproar about all of these issues.

The problem which precludes successful deletion in the intended single operation, is not only obvious but extremely disturbing to any software engineer worth their salt. But the importance of this, is that it reflects the extents of further faults in the responsible software.

The anomalous behavior and redundant work imposed reflect a fact that the folks writing the software are not even capable of writing a proper iterator. Yet this is one of the first and most basic, virtually automatic skills of software engineering. Because numbered lists in software engineering take the form of zero to number-of-items-minus-one, every proper iterator ever written takes the uniform form of iterating from zero to item-count-minus one. The regular form of every iterator itself eliminates the mistakes responsible for the resultant misbehavior. Whatever the mistake, the underlying code makes the preposterously amateurish mistake of either collecting or iterating one fewer item than it must. A thing like that is fixed in five seconds. But its preposterous and even enduring existence mean that even such fundamental errors likely pervade the remainder of the distribution.

So I mention this preemptively, for those who will attest without qualification that their copy of the same wares is guilty of no such ever-repeatable faults.

Anyone who is even remotely familiar with the equation manager as they would be if they are truly proficient as possible with it, will be aware there is a relatively bizarre trick which somehow forces the responsible iterator to mistakenly count or include the one item it instead regularly excludes.

So, what's that trick?

So, we have vacated our equations literally hundreds if not thousands of times, and mused about defeating the faulty behavior as any engineer worth their salt would, because the behavior is so obstructive.

Thus, anyone who is reasonably proficient eventually discovers the trick.

In any case, not even working within the environment is simply "easy." I stay out the environment as much as possible, because much more work can be accomplished externally.

But we have the further prospective difficulties of comprehensive parameterization itself to consider.

When a model is fully ("comprehensively") parameterized so as its every possible permutation is successfully rendered, drawing strategies and mathematics have not only to be perfect; they have to be perfectly impervious to further underlying faults of the software you may otherwise never discover.

If you truly know geometry for example, you well realize that the many relationships we can assign to a collection of points, lines, and curves may never truly "over-define" the intended system. To make two lines vertical, and to also specify that they are inherently parallel, does not truly impose any irregularity that ought in any way to preclude executing the effective instructions of the sketch. Yet we are warned unnecessarily that we have "over-defined" our drawing, though in fact, we have no more than indicated a further truth which does not conflict with, and instead is consistent with the fewer facts the software prefers to deal with. What this irregularity alone means then, is that the rationale for executing our instructions is faulty, for if the rationale were instead sufficiently comprehensive, it would realize that the instructions it refuses to decide between, are instead perfectly consistent with each other.

I mention just this one obvious fact (there are many more), merely to preemptively address contrary assertions. Attentive end users will concur that the software is faulty, explicitly because every such instance of such faulty logic is faulty. But this faultiness manifests with far greater regularity and to far more perplexing extents, when we attempt to fully parameterize a design which must be so flexible and resilient as to succeed in producing whole libraries.

So, I am merely addressing prospective assumptions that many models may be produced "easily."

That the math of your question was perplexing to yourself and others who did not provide its only solution, is itself trivial compared to the mathematics, geometry, and trigonometry of comprehensive parameterization. Most of us instead rely on our software to perform all the trig, to calculate the length of a tangent, and so forth.

But in comprehensively parameterizing a model that will generate entire libraries of varied parts, you're on your own. You develop the proper equations, and you wield the ultimate calculations in drawing strategies which many, many times must be exhaustively tweaked for no other reason than to defeat fraudulent assumptions of the software, irrational faults of the software, or even many of both. You may revise whole systems of perfectly valid relations, merely to get just one of 30 models to generate as it should.

It is hardly appropriate therefore to presume that after exercising vastly more challenging technical abilities than are required by straightforward sketches, our many models are generated "easily," simply because indeed, only at the very end of overcoming these difficulties, we merely revise a handful of parameters to generate each of them, at the final expense of perhaps 2 or 3 minutes per model.

You should anticipate these issues, rather than prefer to dismiss them. We all encounter these issues in our work.

Say for example, you have designed a machine for much more sophisticated purposes... and at considerable expense, you worked out all the ideal planes of swept elbows for a relatively intricate dust collection manifold comprised of TIG-welded tubing. The geometry alone of this assembly might be remarkable. But an eventual refinement of the machine may require just a minute tweak to a dimension of the manifold. The drawings for the manifold have served their purposes for weeks. And you make this small adjustment... and suddenly a sweep that was clearly and decisively sketched to angle steeply downward, instead angles steeply upward.

Have you made a mistake?

For what good reason does the software suddenly decide to draw the extension of that angle upward, instead of downward?

But the reason we can determine unequivocally that the software is at fault for all the "corrections" it forces you to make, is that we can in fact conceive exactly how the definitions of the elements of our sketches would have to be further defined and accounted for, if the software were never to make such erroneous and destructive decisions. The software hasn't even yet evolved to incorporate those indispensable provisions. So, that is why we are so often, redundantly required to re-perform prior work.

Enough for such merely argumentative people as will merely allege without qualification that their software functions perfectly. The point remains, that these are the further difficulties that parameterized models must prevail over, if we are to "easily" produce many models from such a template.

Comprehensive parameterization is forced to contend with these faults... often, only by such exhaustive experimentation as will merely discover by trial... what just happens to defeat the faults of the software.

Good luck, if you aren't a software engineer, because deciphering these faults is instrumental to conquering them by generally far more extreme measures than would be required to fix them in the software itself. You can readily reproduce the equation manager's failure to delete all your equations, so selected, to see for yourself. Lack of means to order your equations as they will be displayed in the equation selector is obvious.

But as I have already inferred, the math of comprehensive parameterization is regularly far more challenging than the solution to your question. This likewise infers how easily a multitude of permutations may be produced from a parameterized template.

It is easy therefore, to underestimate the bar for such comprehensive parameterization schemes as first calculate the dimensions of inner and outer raceways from standards which fail even to specify the determining factors. Yet we still dismiss these difficulties to assume this class of model easily produces its many possible permutations, even if we are further incapable of properly calculating no more than the size and number of balls which ought to occupy each such raceway. We may not have the slightest idea how to calculate how many needles comprise a full complement about a given diameter, We may not even appreciate to the least degree that these calculations relieve other engineers of these responsibilities. But no, the proper answers are certainly not determined by dividing the diameter of the ball or needle into the circumference upon which their axes are superimposed.

Nonetheless, a reasonably good geometer will immediately cite the only legitimate process for these calculations, while anything less will never get there.

So I don't see that any of this is necessarily easy, especially for the person who hasn't even made their self so proficient; and so, I would be careful in presuming that whole libraries of extremely similar permutations are easily produced, because anywhere that indispensable parameterization truly serves the community, substantial and even extreme difficulties are instead a regularity.

The usual course of the two possible routes of work ought to be a perfect example. You may be familiar only with manually fixing your exploding sketch (the downward angle that inexplicably revised itself to upward). You dove in, and simply re-performed the work over again. But revising that sketch so that it will itself survive the rigors of exhaustive parameterization amidst the faults of the software is a whole further matter.

So, what is the usual, actual prospective payoff of overcoming all this admittedly redundant trouble?

Only someone who has successfully negotiated both courses can faithfully say.

In the typical course of the two terribly different styles of work, Person A might produce the typical unparameterized model for a given part in let's just say 6 hours. (I'm using actual timed cases.) This includes manually repairing their exploding sketches by no more than building them over again, until the cycle of attempted repair and ensuing disintegration succeeds in just one seemingly stable permutation of an eventual library. Perhaps diligently referring to the ISO standards we no more than presume they have at their disposal the whole while, Person A therefore might produce the additional 30 members of the same library at maybe an hour apiece. Thus they produce the 31-model library in 36 hours.

Person B might produce a higher quality, fully parameterized model in just 4 hours, only because they have become so much more adept at developing strategies which survive the faults of the environment. But troubleshooting and solving the operating environment's inability to faithfully execute the full range of parameters may require a full further day of extreme frustration to trouble-shoot and solve, as irregularities immediately emerge in the ensuing attempts to generate the full library. They might thereafter produce the 30 further members of the library at 2 minutes each.

But the job is so much more difficult, that Person A would rarely if ever stay the course to the end. Person B is instead compiling lists of faults and entire strategies for defeating them, while in hundreds if not thousands of iterations of clearing their equations, the mind of a software engineer ultimately discovers many processes which defeat the faults which so conspicuously pervade the work of other software engineers, that they're there for us all to see.

Perhaps Person B spends 15 hours defeating these faults as those faults prevail in subverting the prefect sketches and features they produce in the first 4 hours. So they have nineteen hours in a template which happens to comprise the first model, before they generate the further 30 models at 2 minutes apiece. Altogether, they have 20 hours in producing the library, over often-near-impossible challenges, which will regularly defeat anyone who is at all less dedicated altogether to deciphering, devising, and trying prospective solutions for the mere irregularities we should expect from people who fail even to write but such ignominious iterators as will always fail to iterate the whole intended set.

But there are further difficulties and values of each style of work to consider. We might even question why Person B would generate the full library, when we may suppose that the consumer could instead generate the full library from the provided template at the mere expense of 2 minutes per further model. The answer to this question is also simple. But perhaps, it is not so obvious.

Even with good instructions, the typical end user might require half an hour just to prepare for setting the parameters which will generate just the one model their immediate needs may depend upon. They are not yet capable of generating that model in two minutes, even if they already exercise the many rather technical automations the author exercises to properly name files and so forth in just two minutes.

But they are even less likely however, to possess the prospective table of proper inputs, simply because they haven't paid the $150 to $200+ for each of the ISO standards for the 27 libraries it is a good idea to download then, merely to save themselves the $4,725 they'd spend just on the standards they ultimately must comply with — and may require, just to generate that one model.

So, if we are to understand that the motives for generating truly useful libraries might not reasonably be questioned, we must also address whether a possible prevalence of library members which are typically never used, is somehow justified.

Mere patterns of use answer this question. Prospective engineers aren't going to discover vital arrays of otherwise unavailable components, to immediately lament that we might only use 4 or 5 of 31 models in the rest of our careers. Like the actual bearings these models represent are not waste; neither are the models, for none of us have any truly reasonable idea today, exactly which or how many different members of each such library we may ultimately come to require.

Finally then, if a member uploads 27 libraries comprising 740+ models altogether, they can hardly inflate the credit they get, if GrabCAD wrongly counts every one of those libraries as a single model. Sure, there are models that practically every end user may never use. But the job of acquiring the whole library is reduced to a click; and as I have said, as we never know at any given time whatever other models we may eventually rely upon, what we may know we need immediately hardly warrants instead downloading just parts of each library (as remains an option).

So you have an average of 27.407... bearings per library; and if you're worried people are doing this to fraudulently outcompete you, please realize instead that the 1,700+ "downloads" reported over 9 months instead equates to downloading 46,592 models.

However many of them are truly "waste."

That's the math.

LMAO! A shining example as to why character count limits exist on most sites...This is 13 pages long in size 11 Calibri and 4652 words!

Well, that's who YOU are:

Counting characters, rather than recognizing that nothing less answers for all the incumbent considerations.

Please don’t feed the trolls