PreForm complains model needs repair, but it doesn't actually need repair

Seen this behavior a few times over the last week or so. I’ll load a model in to PreForm and it’ll pop up the dialog about needing to repair the model (even though I’ve run it through NetFabb and I know it’s good). So I click the “REPAIR” button. The dialog closes but nothing happens. The model isn’t loaded and PreForm is not processing (as verified using ProcessMonitor). If I go to the FILE menu and check Open Recent… the file name will be there. If I select it from Open Recent… it loads the model without complaining that it needs to be repaired. This has happened on a few different model files, at least one of which has been brought in to PreForm many times without showing this behavior, so I think it’s a newer feature of PreForm and not some weird, intermittent error in some random selection of my STL files. I haven’t been able to pin down any specific trigger conditions. But it’s starting to annoy me. Was wondering if anyone else has seen this?

Had similar with the form 1 a while back with a particular model. Passing it through the extended repair on netfabb (I have a full license for the software) a few times seemed to sort it out. No idea why unfortunately but it worked.

If you could send in a help ticket and attach a model that exhibits this behavior, then we could probably figure out what’s going on.

I’ve seen this behavior too. Seems to be increasing in regularity as releases go on. Currently about 1/3 of the time I’ll load a model and and it’s fine. Another 1/3 I’ll load a model, hit yes to repair and nothing happens, model doesn’t end up loading. The last 1/3 for me is what @Randy_Cohen describes, I hit repair, the model loads but nothing is repaired, and I know the model is fine.

I’ll open a ticket just to aid in the search for a cure!

@mgarrity Thinking aloud here, the vast majority of the models (STL files) I receive are sent to me via a drop-box. I sometimes save locally then load in Preform, but often times I do not (drag and drop straight from dropbox). I’m wondering if this could have any effect on models loading in Preform.

Not for me. I’m 100% local. Start PreForm, load model, get “REPAIR” dialog, click “REPAIR”, nothing happens, load the exact same file as the very next user action, model loads without a “REPAIR” dialog and then goes on to print perfectly.

I would have opened a ticket and provided a model file if the issue was even slightly repeatable. But it isn’t. At least so far, it appears to be completely random. As I said, in at least one case a file I know I’ve opened repeatedly in PreForm in the past without error has exhibited this behavior once, too. But I have never gotten it to repeat.

Out of the 100 models or so I have printed I found one in which it is fairly repeatable. I drag and drop (local or drop box) and about 10% of the time it asks for a repair, I hit yes and nothing loads. The other times It asks for a repair and then loads (and would print just fine). I submitted the file in a ticket. I’d post it here but it is under NDA.

A support rep just got back to me confirming he was able to replicate the problem with my file. Here’s to hoping it gets fixed!

:beer: Cheers :beer:

Support just sent me a model which I think is from this thread. I don’t know if it is indicative of all of the issues people are seeing, but it may be.

I haven’t caught it failing to load the file yet, but I see one obvious thing in this model. The STL file contains two separate shells, and both of those shells have a bunch of triangles which all lie in one plane where the two shells touch. It looks like one shell was created by mirroring the other through one of its faces. This sort of coplanar geometry is exactly the sort of thing that can cause these types of intermittent issues. The math of trying to identify and eliminate all of the redundant triangles is very sensitive to floating point issues.

I’ll use this example to see if there’s anything I can do to make it more reliable, but in general it’s probably best to either “union” the shells, or move them so that there’s a tiny bit of overlap.

Thanks for sending in the example!

1 Like

You are welcome @mgarrity Most of what you just wrote went over my head (I’m a graphic designer/software dev and this is my first experience using a 3d printer. 99% of the files I’ve printed are created by someone else and sent to me for printing).

That being said I will pass your info on to my CAD guy (with whom there is a language barrier as well, he speaks only Spanish and myself only English :stuck_out_tongue_winking_eye:) Hopefully it will all translate!

I just hope it will help in the grand scheme of things. If not c’est la vie.

Well, I sort of have a problem with the assertion that floating point is responsible for variability in behavior. While floating point algorithms all introduce small errors into a calculated result, the calculation is being computed in sequenced (isochronous) hardware. That kind of HW has to behave deterministically. Otherwise the FP calculations are NFG. Given the same two inputs to a FP operation, the output must always be the same (not necessarily correct, but the same). If that’s not the case, there’s a hardware race condition in the FP processor and that’s a bug, not a feature. :slight_smile:

In my case, I have seen this happen on multiple different models, all of which have passed NetFabb’s checks cleanly (meaning, only one shell, all polys in the same direction, no self intersections, no holes, no degenerate polys, etc.). It has never been repeatable. It seems to happen most often on the first load after starting PreForm. But last night it happened when I loaded a new model in to an instance that had been left running for a few days, which is what prompted me to start this thread. And when I say “most often” I’m probably talking about maybe 10% of my model-loads in to PreForm.

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.