PicoTreed wrote: ↑Mon Apr 27, 2020 11:46 am
It's ok to say that G-code is not an universal file, but in the real life we use it more or less in that way
that is simply not true, if one is trying to look at g-code as "universal file" one lack basic understanding of the technology where g-code is used. neither in FFF nor in milling g-code is considered universal, not even between identical manufacturers and identical models of a machine, let alone between machines.
PicoTreed wrote: ↑Mon Apr 27, 2020 11:46 am
Provokingly I say that firmware and slicers should be ideally the same things.
You have that on a number of printers. On the cheap side, TT printers are like this. It is not a very bad solution but it is a solution huge amount of ppl are paying money to leave (replace existing electronics to be able to use a slicer of their choice, like for e.g. S3D). Look at the SLA market, again it's more/less this situation, slicer+firmware are a single unit. They are spread between printer and computer but just 'cause printer don't have proper UI nor cpu capability to do preprocessing but in reality they are the same unit split into two machines. What's the most common complaint from SLA users - that's BS, they want to be able to control the process the way it is controlled now on most FFF with slicer and gcode interpreter being separate. Prusa is entering that field wide with PrusaSlicer support for his SLA machine, open-sourcing his SLA machine.
So IMO there's nothing "ideal" about joining them, it's actually easier to vendor-lock user so one can use only your filament and only your resin and only buy stuff from you but brings nothing to the table for the user. And again, even in that case, the preprocessor and the executor talk language, wether this language is g-code, spreadsheet or something else it's completely irrelevant
PicoTreed wrote: ↑Mon Apr 27, 2020 11:46 am
arhi wrote: ↑Sun Apr 26, 2020 12:23 am
what is a problem is that apart from KISS none of the slicers, including fusion360 slicer that handles solids like STEP/IGES will generate optimized paths with curves (G2 and G3 codes). From all available "hobby" slicers KISS, and only in beta, support G2/G3 path generation and that is a proper way to handle curves.
Status quo is not synonymous for the right thing, often it hide technological stagnation and Autodesk is running very fast on this matter.
how are you reading me saying that's a problem with satus quo ?!
that's a problem, ppl are working on it, too bad not many ppl are working on it but it's not an unknown problem with no possible solutions
1. there is already a slicer that does it
2. there's already a patch for multiple slicers (slic3r and cura) that kinda does it (not really, but good start)
3. there's a postprocessor in the way that's being heavily developped that's showing a lot of promise
so things are of course moving forward
PicoTreed wrote: ↑Mon Apr 27, 2020 11:46 am
I'm well aware of it, but… what a stupid way to do things!
did you ever try to write a FFF slicer your self? from STL or from Solid model? Ever?
dod you ever try to write a multiaxis cam for milling, from any format, ever?
PicoTreed wrote: ↑Mon Apr 27, 2020 11:46 am
First we destroy CAD information by exporting in the STL format, then we degrade them more by slicing, and finally we try to reconstruct those information by a sort of reverse engineering.
until very recently huge (5-6 years ago netfabb did a research and it was 80+% in the all 3d printing world, so commercial + hobby) % of the objects shared in the 3D community was designed using MESH editing tools so there's ZERO information loss there, further more, out of 100% parts created using SOLID modeling tools over 80 was "touched" in MESH editing tools before being printed due to mesh editing giving easier tools to perform some operations, so again, no information loss.
now, even if everything is done solid, and you have all your info, you again have to match the curves, and matching them on solid or on mesh is not very different (except where you actually have circles, then matching solids are super fast and easy but that's an insignificant amount of cases)
so I come back to the same question - have you ever tried to make a slicer?