Jump to content

cnd

Member
  • Posts

    8
  • Joined

  • Last visited

Personal Information

  • 3D printer
    Other 3D printer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

cnd's Achievements

  1. This might be what you're looking for? https://github.com/FabMo/G-Code-Thumbnail
  2. The grey area appears to be related to print options, like skirts and brims and so forth - and somewhere in that mess of code there's an "out by 1" error, or someone accidentally put ">0" when they mean ">=0" or whatever, causing the full build volume to be unavailable. Changing the size of the build area in the printer profile to make it larger than it really is, ended up working OK. Lucky for me, the firmware seems happy to let me print past the maximum extents allowed - so I guess as long as the print head doesn't hit an end-stop, that's your *real* printable size... on the chiron.
  3. Thanks Greg (I mentioned the build plate size to remind everyone that the 400mm size "limit" is the actual real printable output size that gcode is guaranteed to work for) Any chance someone on the dev team could be asked to find and fix this bug? " Since your model is line-to-line to the limit of the Printable Area in the Cura Machine Settings - Cura won't slice." - that's logically wrong, of course - the only time Cura should refuse to slice is when it is *over* the limit... (I'd go as far as to say that allowing even more than the actual "limit" when any extra amount is not going to result in gcode exceeding the limit should also be allowed - e.g. 400.00005 should still be just fine (and is plausible, since floating-point-rounding...) - in fact - the build area should really be logically extended by the nozzle width as well, since we get an additional half-a-nozzle-width worth of plastic coming out on all of the sides at all times of course) I'll try the 405 idea - but I'm not convinced that Cura is going to slice correctly still - it already refuses to do 400mm, so my guess is that it's going to output gcode that goes from 1mm to 401mm if I let it use 405mm, and I'm not sure what the Chiron firmware is going to do with that past-the-limit 401mm when it gets there... Those grey lines around the border of my build plate suggest to me some kind of logical region that something in Cura has been told not to print in - which means Cura is *never* going to be able to print at (0,0) until we work out what those are and how to get rid of them? Through a pile of trial-and-error, I worked out that the unprintable amount is somewhere between 1.3mm (cannot print) and 1.3001mm (slices fine) so a model that is 398.6999mm wide outputs this GCODE (which has 398.31mm extents using a 0.4mm nozzle, which looks correct): ;MINX:0.845 ;MINY:199.805 ;MINZ:0.2 ;MAXX:399.155 ;MAXY:200.195 ... G1 X399.155 Y199.805 E12.94194 G1 X0.845 Y199.805 E25.85859 ... But it proves my point - 0.845 is the smallest it can go - so something is wasting that much all around the edges. I checked all the settings - there's no "(Home Offsets, software end stops, etc.) " (where "etc" is everything mentioning any of those things or parts of them or synonyms) - Chiron settings don't have those (not in cura, and not in firmware), and it's irrelevant since I'm looking at the gcode first.
  4. P.S. No - I cannot go diagonal, and yes, I absolutely do need that very last millimeter (it's for a laptop HEPA filter holder, and I need to put a silicone sock on this to make an air-tight seal below my laptop, which is (grr) precisely 400mm...)
  5. My Anycubic Chiron can print XY 400mm x 400mm on its glass 410mm x 430mm build plate - however - CURA won't let me slice anything that's the same size as what my printer can do, and it can't even work out how to place it on the build plate... What am I doing wrong? Can we ask the developers to fix the placement bug? Adhesion and supports are off. I can see an infuriating grey line around the outside of my build plate which smells like the problem - if I turn on adhesion or mess with it, the grey line grows wider, however, I've got no idea why it will never go away entirely. What's this unwanted boundary I can't get rid of? Model is precisely 400.00000 mm:- perl -e 'print 6.63669e+01+3.336331e+02' (see STL) Body10.stl
  6. Interesting! - and 317,000+ downloads, from a guy who actually worked on Cura for Utilmaker... which begs the question: why was he forced to release this as a plugin, and what politics prevented this setting finding its way into the product? I wonder if it's some kind of marketing decision, to deliberately give non-Utilmaker users more difficulty with their first layers...
  7. And before some smartypants says "edit the gcode" - keep in mind there's tens of millions of 3D printers in the world, and the overwhelming majority of them are run by "normal people" (not supercoders who know how to edit code)
  8. GCode carries these commands.. G28 Z0 G92 Z0.2 which let the user define the distance between the build plate and the nozzle (in my example above, it's 0.2mm) That's a REALLY important number, because Cura will never output Z0 (if you set a layer height of 0.2mm, Cura's first layer will be Z0.2 - which, combined with the fact that my nozzle (and *Everyone else's*) does not touch the build platform at Z0, means that Cura is printing a 0.4mm high first layer, and wrongly thinking that it's 0.2mm high. There are some ghastly kludges to try and overcome this mistake (like setting a first layer extra flow rate) - but this all seems really puzzling and bizarre to me. The math to calculate exactly how much filament to extrude is going to get the answer 100% correct for EVERY layer (first included, no random kludges necessary) if Cura simply had some way for us to tell it what our Z Offset actually is. Is there some sensible reason for this support being missing, or did the devs just never think about this properly in the first place? It seems really bizarre to me - it's so incredibly obvious, and Cura is not the only slicer that skips right over this critical bit of information. Maybe this is one of the contributing reasons for so many people having first-layer problems - software that has no way to properly compute a first-layer flow rate, because the programmers never gave anyone an input box to tell it what the Z offset is...
×
×
  • Create New...