While trying to slice this http://www.thingiverse.com/download:1470188 (after correcting the scale etc.), S3D resp. NVidia brought the attempt to a grinding halt. See screenshot. I contacted the S3D support already. Did others here see the same error already? I also tried to reduce the triangle count (using that wonderful netfabb software), no avail. Of course, my drivers and the whole system (i7, 12 GB RAM etc.) are on the latest update state. Time to fire up slic3r again.
Ulli I had no problem loading this into S3D, so I suspect it's a driver problem. My system is i5, Intel HD graphics (hardware open GL) and 8G ram. Mike
Mike, Thanks for the test. I did not mention that I had a) turned the object by 90° to let it rest on the flat top, b) enabled support generation for the fixation ring - the screw holes would not hover automagically in normal air, I guess. Slic3r, needless to mention, took a bit longer, but genereated a 241 MB large gcode file. Looks like a prolonged build. No vase. Ah, Mike, you said you had no problem to load it. Me neither. The problem arose when generating the gcode. I assume you tested that as well . Would you like to do that with some deliberately chosen support parameters (full support, 45° threshold)? I'll ask the author to provide a version without its own support fin array. These cyclone filters are very useful when you operate a CNC mill / router. Ulli
I did run the file with the default settings for my printer, positioned as you indicated and auto-support generation which yielded a gcode file of 47.8MB using about 0.5kg of filament. That's a big part! As it's 1:00am I'm heading for bed! Mike
Good morning, Mike, thank you so much for your time and effort. I tried to find out a bit more about that error code 8 that NVidia reports. It relates to a timeout of the calling program and Windows, so pretty clearly a design flaw. As this has never happenend in any other software environment for me, and I do quite a lot there, it helps me to argue, if necessary, with the S3D folks. The result looks pretty similar to what slic3r came up with after some deep thoughts. Thanks again, hope I can return something in time, cheers, Ulli
Loaded and sliced no without errors, 51.8mb gcode file 57.1mb x3d file. I don't see why you'd post about this in the Bigbox printer forum. A quick google shows its a very common issue with OpenGL on nvidia drivers.
S3D was sold to us by E3D for use on our BigBox printers and we are having issues with it, so we discus it here!
As a person that does have a bundled product. If you need tech support for a product. Go to the manufacture. The people at E3D can't fix your problem, they didn't make the software, they only allowed it to be bundled with their printer for ease of use. What ED3 is responsible for is the profiles that go with Simply3D. Bugs or major tech support you need to go to the maker.
@Ulrich: out of curiosity I tried the model, rotated & supported, and S3D generated a 54.8 mb gcode file with no problem, though it took longer than any other model I've played with. For what it's worth, my system is an i7 running Windows7 and ATI graphics hardware. Seems to me that if S3D has a problem with NVidia hardware and/or drivers, the developers ought to be aware of it & fix it. Cheers, Hans C. p.s. I wondered what all those fins were. I figured they were for cooling, not support, until I realized that plastic fins wouldn't cool worth a damn. ;-)
Hans, thanks for the comment and message. The transition between the input tube and the body seems to be shaped very smoothly, phantastillions of triangles. The fins were supposed to serve as a support - but were not extended to the top frame with the screw holes. The author, however, reacted very quickly to my question if he could provide a finless version - it is there now. Still very vouminous, but it is there. Your remarks on the responsibility of the software manufacturer are completely right. I managed to reduce the triangle count so far that S3D came up with a printable result - (I included support with 15% filling, and a pretty sparsely internal filling of the object itself too.) Nvidia states quite clearly that the software makers have to provide measures to not let the combination of Windows flaws (strict timeout rules) and graphics drivers time demand run into a dead end. It is feasible. BTW, of course I contacted the S3D producers but did not receive any reaction so far from them. As far as I can see I am not the only one who makes this experience and frankly, I don't expect that they will do something. And since, as Mike explained already, E3D sold me the product, they are responsible and at least should know about this and other problems with the product, and that's why I discuss that here. Besides that, this forum serves as a place for the exchange of experience, know how, and advice for users and customers who are looking forward to use the BigBox one hopefully near day. So, I will continue to wait (for my two boxes) and won't feed the trolls in the meantime. And finally, looking at a projected build time of 38 hours for my present printer (did I mention it's an OrdBot? ) which will come out as more like 60 hours in real time, I'll wait for the BB and the Volcano I extra-ordered, hoping for a quicker result. Cheers, Ulli
@theTroll527 and @Kanedias Why are you getting snotty, we are gathered here the support eachother S3D is part of the bigbox and as such the right to ask other people in this community about it is our right. If you don't want to talk about then don't read the thread its that simple, but giving members attidute because they are seeking help is rediculos keep your venom out please.
You're reading more into my reply than is there. The issue doesn't relate to the bigbox _printer_ so I wouldn't have picked this sub-forum. Help and support or general would more relevant. Does checking the "Use legacy graphics mode (best comparability)" option in S3D make a difference?
I don't want to increase the complexity of the meta-discussion-level here, but for me, the S3D issue was and is directly related to the BigBox(es) I committed to in the KS campaign. It was sold in a package and thus is an integral part of the product. And I pointed out previously how badly I miss a real written, readable, foldable, usable manual for this program. If I had had it, and if they would have included a chapter on what can go wrong and how to cure that, I would probably have found your very good proposal there earlier. While checking the legacy graphics option (why does the S3D service not respond with the same solution - I sent them a screen shot of the nvidia error message, and it's useless to write anything in their forum, they don't read it, my experience), I also increased the vertex buffer size by a factor of 10 - and was amazed how fast this time this object was calculated. Let's close that here for the time being, thanks for the pointer to the legacy flag. Maybe this helped somebody else now for the future. Cheers, Ulli
I I am not getting snotty. I am saying that these problems can not be addressed by E3D because it is not their product. It is like expecting Microsoft to fix a problem with an NVIDIA driver. It is not an attitude, I am just stating that E3D has ZERO control over a third party product. Once you get past the basics there is very little them or the community as a whole can do. It is a Simplfy3D issue. Not sure why you think this was in any way venomous. It is just trying to get people directed to the place that can actually help. j.
He is asking the community for help not telling E3D to fix S3D If I read too much to your posts I apologize.
And that place was exactly here. To close this topic from my side now, I just want to report that the S3D support reacted earlier this week. Their reply, though, had nothing to do with my question and the situation - they pointed at possibly wrong oriented triangles and asked me to check for that. My reply was that a) I had done that already, the data were error-free, b) that others (the guys here) were able to process the data in S3D as long as they did not have nvidia graphics, and that nvidia clearly states that it is the responsibility of the software manufacturer to make their stuff compatible with their driver interface, and c) that the solution was that one that Kanedias suggested here. No more reply from them after that. While writing this, I ask myself how they can implicitly say, hey, if our software stalls and fails, it's an (expectable) error in the data. To be taken serious? Naaaahhh.... Conclusion: You find solutions where they are, not where the directing sign says. Cheers.
