alaris2

very nice work Xeno - is it articulated?

2) a finger no less. printed directly to a hot bed which costs £20 to make, oh and dual extrusion too from a hybrid V2 and an all metal hotend. (cos I was twiddling my fingers waiting for UM to make a hot bed, then I thought, let's just do it. so if I can do it, you can do it so much easier!)

I keep getting requests to post these, so here goes. 1) SG's most excellent direct drive upgrade. never tension those stupid short belts, never have a naf print again. nice work SG! of course, all self-respecting UM owners have already made this upgrade, so it's hardly news I realize, I'm a bit late with this..

anyone? I'm assuming the problem lies in temperature.Cpp but haven't found it yet

it's gone really quiet actually - I had so many people write to me saying they were working on slicers that it made no sense for me to reinvent the wheel, so I stopped. I also had loads of messages of support and offers of help- thanks to everybody- and sorry I didn't have time to respond to you individually- there were too many! I was reminded last night again after a terrible print just how dire the need for a decent slicer is-so I hope Daid has made better progess than I. whilst I don't now have the time to write the whole thing I would be happy to share where l got to and the methods I was intending to use to solve each of the requests

ooh! new design? I wonder if they're making those changes I suggested -if so it will make this a no-effort UM upgrade. Robert -there may be other silicone heater manufacturers near you?

that's the one! #include 2 metal plates and 1 PC power supply , and a relay and you're in business one of the easiest and cheapest upgrades ever

Ahh! that sounds useful Daid- thanks!

really good discussion going here - SG - I was being a bit vague-sorry I think the latter -quantify the error by observing its effect on a simple print 0.1mm should be easy to see- perhaps a simple octagon vase would show it on the faces that align with the axes? just thinking aloud here really...

Sorry-I should have mentioned that (about the website) before they usually deal with reprap people who use 1.75mm stuff -but I asked them if they would do some 3mm stuff for us since they have all the tools Robert-about the hotbed-it's a company called Qubd- I can post more info on a separate thread if you like. or pm me for more details

having added my £20 hotbed I admit to being rather pleased with the results-prints are coming out clearer and with nice flat bottoms but I wonder about safety ? several of us have had problems with the arduino crashing due to power spikes or whatever what happens if it crashes while controlling a relay-based hotbed? does a crash automatically open the relay (ie. bed off) or is it not failsafe.in which case the hotbed just keeps getting hotter?! what precautions have other hotbed users taken?

one of the best mods I ever made - I just added a heated bed for £20 too and printing is such a dream (actually it still takes too long to print so sometimes I do end up dreaming) E3D aren't out of stock - the web page is at fault-email them and say nik sent you. remember you will need to mod the top metal piece if you want to attach it to the existing UM print head

can I suggest we make a test calibration piece so we can both see and quantify the effect I don't have any smart ideas what it would look like but perhaps Someone could Suggest?

I know there's been a bunch of posts about the buildmemarlin not working for hotbeds since late last year. so I downloaded and tried to build the marlin from source. however, it appears to also be broken for dual extrusion, in that if i set T0 to 50C (as an example), the ulticontroller shows both hotends are being taken to 50C, not just the one. it reads 53/50 and 54/0 (as an example again) on the display. and yes, both are hot if you touch them. known bug? is there a quick fix?

Mine make the same sound however they also feel 'uneven' even when I detach the belts- I know it's a silly question but have you tried this?

actually I thought Daid was UM, and he runs the forum too doesn't he? are you saying other people also work for UM?! shock! and isn't Daid the guy who writes all the software too? how does he have so many hours in the day? I wish we knew these secrets?

he wasn't shouting, just making it easier for us visually impaired UM users

wow thanks MSU, there's a lot there to digest! I'm going to try some experimental profiles and relevel my bed after fitting the heated bed next.

there's a separate thread in the 'others' section which discusses this, and at least 2 other slicers people are working on. one of which is the legendary Daid himself hence should have maximum compatibility with Cura. right now they're all in various states however - and they'll need heaps of testing and bug fixing before they overtake either Cura or k'slicer. the bad news is that none of us have heaps of time, so progress is slower than we'd like. but come and join the discussion if you like and input your ideas!

Daid> compensating is important I agree. the warped bed thing is interesting too - I see KS has an option to load a bed profile (not quite sure how it's generated) to handle strange shaped beds.. have any tests been done to understand speed? logically we feel slower is better, if nothing else it gives more time to react and stop the print, but is slow necessary to stick? does it actually make any difference to how well PLA sticks to tape or is that just a warm fuzzy feeling inside our heads? Troy> I think I understand - but how are you handling shells in the Z dimension? the XY plane description makes good sense but only if the shell exists purely in the plane?

easy all. no offence was intended to anyone and there were good and valid points raised by all parties. the crucial next step is some alpha code that people can run so we can get feedback. there's also a 'collection of data' task too - it's very apparent reading thru different threads that almost everyone has their slicers configured in different ways (eg. with respect to fans on/off, first layer thickness, heated bed temps, etc etc). is this because it's the *only* way it worked for that person, or because we've all fallen into habits? has anyone tried a comparison between 'with this setting' and 'without this setting' for example? I know i'm guilty of this - over time I've tried almost everything, but not necessarily in a scientific way, there are too many variables, but what I have may not be optimum therefore. to try and explain why this is important - allow me to take the example of the first layer which is tackled differently by nearly everyone. some swear by bed levelling and treat the first layer the same as all others, others will configure the first layer speed and layer thickness. this has implications on the g-code generation as well as the slicing. none of these methods are better or worse or right or wrong. but i'd like to understand if there's a one size fits almost all situation here because it avoids a huge number of UI configuration options if so and makes it easier for new users (we all want a 'just do it' button after all). in the early days I had the first layer about half speed, with no fan and twice as thick as other layers. later I realized this distorted models so tried all layers same thickness. it worked fine, so i stayed with it. later still i got tired of waiting so long for the first layer, so sped it up to 75% of full speed. it worked fine. i stayed with it. then i switched the fan off for everything except bridges. obviously the first layer is key, but without starting another war, can we discuss "just how much like a normal layer can we treat it and still have a 99% success rate?"

it's the second reason I moved to KS originally - the first was because the outer surface quality of parts was just so so much better than SF. if I had to prioritize it would be quality, time, robustness. how do others feel about priorities?

the biggest problem (and I think Daid is going to hit this too) is that you must use a thickness function, not an offset/scale function. consider the case of a figure 8 in 3D. you don't want to scale about the centerpoint of the 8, you want each circle to scale about the center of its circle. this requires deciding multiple centers and which polygon belongs to which.. and this is where it starts to get slow. the correct way to solve the problem came to me at about 3pm after thinking for many hours, only to discover someone else had already thought about it and written a very good paper on the subject. alas no free source code, and the suggestion was that it's still slow. there's a solution in opengl-land, because you can fix the XY-plane part of this problem by using some bresenham - but traversing large texture arrays = slow. which defeats the purpose of the exercise. it seems to suggest speed and robustness are mutually exclusive - you can either take the fast but 'keel over and die when you find the tiniest fault in the model' approach that k'slicer takes.. or the 'works on every model under the sun even the horribly degenerate corner cases, but takes hours to generate the shell' approach which is the corner I seem to have painted myself into.

I would agree that a post-processor is a good idea, tho it obviously avoids 2 rather important issues 1) a lot of people are having problems with getting to any g-code at all - the vast majority of example files I tested for example all had at least one fault - inside-out or non-manifold geometry, flipped normals, self-intersection, infinitely thin planes, etc etc. 2) the ideas are excellent, but creating UI to make it intuitive and easy is.. well, not so easy. there's a matter of designing that which I'd suggest is what this thread tackles first before any code gets written

ahh, you stayed in polygon land, I wondered about that. I got the GPU to do most of the hard work for me, which guarantees that if it looks OK on screen, it will slice OK too (all broken geometry is automatically fixed). the difference in speed is tremendous, but it has one small drawback.. there's no way to do shells in glsl :( the only solution I can think of would be an application which fixed broken geometry meshes first and generated a 'thickness' function (pure offset isn't robust but better than nothing) - this could then be fed to the GPU to maximize speed but the advantage of fixing broken geometry is then lost..