1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

I would like an explanation of this mess........ which SHOULD NEVER HAPPEN

Discussion in 'General Discussion' started by JST, Jun 17, 2020.

  1. JST

    JST Alibre Super User

    So, I opened a personal project file to work on a re-design. This file has been stable and easily worked-with for months now. It is a design evolution and is currently on version 3.

    So I opened it today, to see if I could solve some design issues that I have with the model, things that I do not like in the device being modeled. This file has been opened and worked on innumerable times, it has been fine. It's a background project which I work on when I have time. This time it did not look right, and when I took another look, it sure was NOT right.

    I found TWO huge and unacceptable issues which have a relation between them. I can see NO way in which "I" could be responsible for either of them.

    These are imported McMaster parts, which I have used for quite some time, and which have given no problems in the past. Now, they have, in simple terms, gone to hell in a handbasket.

    Issue #1: Two different bearings have somehow become connected, partially. The balls out of one of them have, at a totally different scale from what they were, become part of a roller thrust bearing.

    Roller bearing with unrelated balls.png

    Issue #2 The other is the part from which the balls CAME (the one missing above is present in it still. It is at a MUCH bigger scale all of a sudden, it should have a 3/8" bore, but now measures out at 1". NO this has never been the wrong size before.

    Since ALL the parts that have so far been found to have errors now, were imported into Alibre and stored as ALibre parts, there should be no issues with "outside" parts. All imported files came in as STEP files.

    Correction: The two parts inside the ball bearing are "seals" from the original imported model of the bearing. But those parts remained the original size, at least they did not scale up with the other parts. No idea why.

    Roller bearing 2 with unrelated parts.png

    This sort of failure really needs an explanation of just HOW IT COULD HAPPEN AT ALL.

    The sub-assembly where the problem was discovered is part of a larger one, which is part of a still larger assembly. The top level has several subs, totaling up to quite a few parts and many constraints, etc when you consider all of them. It is a "big" assembly in the sense of being reasonably complex. It is not as big as many I have worked with.

    There MAY be OTHER problems that I have not yet found, which may not be limited to just this sub-assembly.

    The only conclusion I can come up with is that this mess is the result of the program allowing the available memory to "leak away", PLUS then NOT DETECTING the lack of memory, and so allowing the program to blunder ahead opening the file. There then presumably was a certain amount of over-writing of parts of the file.

    That may not be correct.

    At this point, the entire file is totally unreliable, and will have to be re-done in its entirety from scratch.


    Here is the (sectioned) sub-assembly where I spotted the problem. You can see that the ball bearings have become clearly outsized for the assembly.

    Roller bearing problem 3.png
     
    Last edited: Jun 17, 2020
  2. Hunter

    Hunter Senior Member

    Should you not be submitting these issues as tickets? Not sure us normal forum members can help.
     
  3. JST

    JST Alibre Super User

    Has been done, bro.

    Some of the things are SO weird that I just do that right away.

    Others are possibly amenable to other explanations, and I post to see what comes up from the collective mind. If nothing comes out, then in as a ticket.

    Some I just NEVER turn in, because I have tickets in that nothing ever happened with. No sense even submitting.

    This one is already in as a ticket, complete with package file and pics, mostly because I am actually quite annoyed about this, given the amount of work required to correct it in terms of re-creating the top level and probably a number of parts.

    That, and the fact that it is going to "break" some assemblies above it, plus that there seems no reason why this should happen with a file that has been stable for quite a while. I really do not see how I can have "done it" or caused it to happen.

    Any way I can think of to make this screwup happen is either a lot of work that I could not possibly have inadvertently done, or is something that would have resulted in a file messed up, sure, but in some OTHER way. I don't even know how this particular crazy set of things can happen by "operator error".

    I have no idea how to make this level of screwup happen without manually editing quite a number of parts. And that is something which I just plain did not do.
     
    Last edited: Jun 17, 2020
  4. Hunter

    Hunter Senior Member

    I recently had an assembly that also went haywire, but I think it was me. I silenced my constraint error pop-ups, which I think was a mistake, so I built a bunch of conflicting constraints which I think was my problem - but not entirely sure.
     
  5. JST

    JST Alibre Super User

    Normally, that will result in either the commanded operation not even happening, OR in red constraints. At least that is what occurs when I make constraints which conflict.

    I do not think you could very easily ignore either situation. If you do not have red constraints, then it may well NOT be "your fault".

    There ARE some situations in which the constraint errors are actually "bogus", meaning that they are "real", but the condition is part of an operation which is "legal", and the result of which will NOT have conflicts.

    An example of this is if you try to perform an "orient" constraint if a part is already constrained. In the prior versions of Alibre, the "orient" was a "thing", and it would simply get done. Now, with the new setup, "orient" is a modifier on another constraint. The "orient" first is a "coincident", which may create an error, then the coincident must be designated as an "offset", then that modified to a "free", at which time the error message comes up again, before the operation is finished. The errors at the intermediate stages are thus sorta "legitimate", but the final result will actually not have any errors, so no reason for them.

    The program should allow bad constraints, with an error and red designation. Often those will go away if "anchor part" is taken off, for instance, so they are not "structural" errors. In other cases, like the "orient", you have to dismiss them to get further on what you are trying to do, so they have to be allowed to be ignored..

    It preferably should NOT take you through intermediate steps which create errors that the end result will not have That just wastes time in useless mouse clicks and "monkey motion".

    AND, it should just not even be capable of combining selected parts from different assemblies, nor selectively changing the scale of "most of" an assembly.
     
    Last edited: Jun 17, 2020
  6. JST

    JST Alibre Super User

    This problem has been officially blamed on a bad hard disk. Of course, I have a NEW computer, which passes every test that the maker can throw at it.

    And, the suggestions made do not seem to be in line with the facts.

    I seem to have been officially "blown off" on this, so whatever. I got the "good luck, have a nice day" response.

    Been good talking to you all, I expect to be banned.

    I seem to bring up issues that are not welcome. So be it.
     
  7. bigseb

    bigseb Alibre Super User

    I have spoken a lot about the 'dangers' of working with imported files. AD, for whatever reason, just doesn't always play nice with imported files. Sometimes it does but not always. This is why I say always remodel it from scratch. Yes, its a time-suck but once its modelled then it's there for you to use over and over. I do this for my injection mould standard parts. Over the years I have amassed a huge library of parts that I can pick from. A portion of this library I have added to resources (pretty much once a 'sub-library' is complete). Go native, it'll make things much easier for you.
     
    Lew_Merrick likes this.
  8. JST

    JST Alibre Super User

    In this case, some of the imported models were made badly so that they nominally shared parts which were not the same. They were ball and roller bearings that had been made with generic parts named things like "revolve 1".

    Oddly, this did not cause problems until the last time I opened the model. You'd think it would have before that.

    However, regardless of that, the way that the parts became mixed up does not seem to have been caused by that.

    One of the parts turned into a different larger bearing, the other one acquired a bunch of bearing balls in the same larger scale.

    If "A" and "B" are assemblies that share part names, I can easily see them getting crossed up. But those should be a straight substitution, one of the assemblies would get parts from the other. That is not what happened.

    What actually happened is more complex. There does not seem to BE another assembly which shares the part names that got substituted-in. The two that shared parts got parts in them that neither had, and that do not seem to have existed elsewhere.

    The only source for the parts in the scale that showed up was another assembly which did NOT have the problem of generic names, and actually did not share some of the dimensions that showed up. In that, and the other imported parts, the names were of the form <94235K122>, and <94235K122_1>, <94235K122_2>, etc. Subparts all contained the assembly part number so they were unique.

    It looks more like an over-write due to some memory allocation messup.

    The suggestion was also made that the HDD may be failing.... Problem is that it is in a new computer, is a solid state drive, and I have tested the hell out of it and the rest of the system already to see if I can find any screwups. So far, no faults show up.

    "Corrupted" file names were pointed at as proof. Problem is those names were victims of me fat-fingering when typing, hitting ";;" instead of "ll", because the keys are adjacent, etc, and not noticing that I did it until the parts were in assemblies and were too much work to fix.

    So I come back to the memory leak issue, and that "things" may happen when Alibre loads a model and does not have the memory left to do it.

    That is not going over very well.... I am told that I "do not seem interested in solving my problem", and was cut loose with a "good luck". (meaning "we are done with you, deal with these issues on your own")

    Well, I already solved the problem, I rebuilt the assemblies. The issue is that what I am told caused the problem is does not seem to be the case. It may have "contributed", but it never was a "cause".

    I do not expect to ever submit another ticket. Frankly, if there is a problem with the program, that's Alibre's problem to solve, if they can find it. I'm not gonna help in any way, I'm not gonna mention it, and I'm not gonna provide any examples.

    So, needless to say I am not exactly pleased. I am re-evaluating the issue of renewing maintenance next time it comes up.
     
    Last edited: Jun 20, 2020
  9. DavidJ

    DavidJ Alibre Super User Staff Member

    JST - potential causes were put forward, with the hope that you would engage constructively in checking out to what extent they fitted. A repair of your assembly by simply replacing 2 imported sub assemblies was also checked and proven.

    Your response came across as dismissive in the extreme of the not inconsiderable effort that had been put in analysing your files, and frankly annoyed the hell out of me. I apologise for my less than professional response to that.
     
  10. JST

    JST Alibre Super User

    It appears that we each totally mis-understood each other. My apologies to David and all others.

    I have communicated the below to David in considerably more detail, with the wish to have a re-start on this, as it is certainly my desire to get to the bottom of it. It is a kinda big deal if it really can happen.

    I have spent now 7+ hours trying to duplicate this problem, and trying to find parts which could have "donated" the parts to mess up the model in question.

    I have not found any direct donors.

    When I tried to duplicate the issues, picking assemblies which had overlaps of the component part names, I found that I had to "OK" over-writes, that the parts then were replaced by the same named parts of the last assembly loaded (all as packages to a clean directory, then unpackaged to it). After that, when opening any of the assemblies, I got errors due to missing parts. I had NEVER seen that with the original file shown above.

    So, 7+ hours in, I can find no evidence showing that simple overlaps of sub-part in assemblies in one directory can do what was seen. Alibre rightly pops up errors and warnings, none of which I saw in the original.

    And NO even "hazy but supported" explanations have panned out in my testing and attempts to isolate the problem with a clear uncomplicated trial.

    I agree that the NEW parts structure used by McMaster -Carr is totally fouled up. All bearings in a series of similar type that are of recent creation seem to share sub-part descriptions like "revolve1" or the like. Apparently someone is either clue-less, had a "bright idea" to save work, or most probably both. This causes Alibre to error all over the place, but does not mix up parts.

    Just do not even try to use McMaster CAD parts. They used to be great, with never a problem, but newer ones, at least among bearings, are totally bogus and unusable. (older ones used the assembly part number as part of the name of assembly components, making them unique to that assembly

    I messaged McMaster about it, and we will see what they do.
     
  11. Drutort

    Drutort Senior Member

    I have not ran into the issues you have, but I do agree that imported models can have issues, for me for example getting lots of files from McMaster-Carr I will use the step files, though solidworks and iges and others seem to work most time, I have stuck with step. I also found that I will do a asm boolean feature to just get it into one part, as I normally do not mess with stock parts like bearings and other parts, so having it be 1 sold model is far better then having it be an imported asm that has 0 constraints and will blow up in your face when you put it into your asm.

    And yes a lot of times I will re do the model, but pull the sketch from the stock part, the reason being is that for some reason many import files will break parts into quarter arc's instead of a single arc, and this does make the model more ugly and issues with constraints IMO, so with simple parts I pull the sketch and just recreate it really fast, often times I have to get rid of the projected multi arcs with single one... but that is pretty easy.

    The part is also smaller less data and looks better :) any part that comes in as an ASM just do a boolean and make it into one, save that part delete the imported asm and used that new boolean part as your single (ASM) part
     
  12. JST

    JST Alibre Super User

    The Assembly boolean is a good approach. It may allow salvaging the McMaster models.

    I have no clue why anyone needs to have the internals shown on a "one-piece" part that is never disassembled. A simple outside surface model would actually be far better. Doing the boolean looks to be the simplest and quickest way to handle the issue.

    Mostly, the drawings of parts that have models do not have the detail to make a suitable model to handle detail issues like fitting it into a larger assembly, unless you have the part and a dial caliper in your hand.

    We don't have a good answer yet as to whether the goofy model was really the "cause" or just showed the effects better. I have already found additional issues, that seem to call the matter into more question.
     
  13. Drutort

    Drutort Senior Member

    only time detailed stock parts are useful is in cross sectionals, when you see a ball, in the ball bearing it is clear what it is, otherwise yes, most parts the high details are useless and hog up your systems resources when doing cross sectional views, this is also why I redo threads in alibre, and control my own lengths and what not, same goes for springs I do them in alibre with different configs, its really easy to do a compressed state and expanded state, comes in handy

    Also before the asm boolean, if you do not care about the balls in a bearing then you can take them out in that state and then do the boolean
     
  14. JST

    JST Alibre Super User

    I generally DO take them out. Just extra junk. Not always.

    I replace the threaded parts of the model also. Normally all I care about is to get a count, and to have the recesses for the heads correct where used.

    The "drawings" they give do not give all the dimensions that you may need if you want to re-do the drawing yourself, and so you are on your own at that point to find the part like it at a manufacturer's site to get dims from mfgr drawings. And THEY may have things missing also.

    Renaming and fixing everything that McMaster messed up is a lot of work. I usually do not do it for trial designs. When I get to a final, then I have to. The stuff that happened above was on trial iteration 5 of the design, (two got tossed early).
     
  15. Drutort

    Drutort Senior Member

    Ya I hear ya.

    My question is do you get the 3d models? If you do, and even if they do not have all the dimensions I usually just go project the faces to sketch and do my own 3D model.

    But I have ran into parts with no 3d models and/or some models being very simplified compared to the actual part.

    And yes some parts barley have any dimensions and that sucks, no model not enough to recreate the part. I usually go and try and find it on some other part library or another mfg, while trying not to waste too much time, in which case I could have probably done the whole part, esp when I just guess at the other dimensions based off some of the key ones give?
     

Share This Page