1 hour ago, WolliBer said:I do not agree with the statement and, above all, with the justification.
Care to narrow that down? I made a few.
1 hour ago, WolliBer said:Whether a computer starts counting its arrays or anything else with zero is completely irrelevant to me.
Funny, I'm sure I read something about that recently...
5 hours ago, WolliBer said:In IT and mathematics, it is possible to start counting at 0. In reality, however, you start counting at 1 and the 1st layer is the first to be printed!
1 hour ago, WolliBer said:But if a situation is discussed in nature, it should be self-evident for every programmer who leaves his workplace and touches a tree that he should start counting the picked apple at 1.
Okay, ignoring the sexism (us girls can program too), that's actually a great example of 0-based counting.
Human: You enter the orchard. You have zero apples. You pick an apple. When you have finished picking the apple, you have one apple. You pick another apple. When you've finished picking the apple, you have two apples.
Computer: You start the loop dealing with an array. You have processed zero entries. You process an entry. When you've finished processing an entry, you have processed one entry. You process the next entry. When you've finished processing that, you have processed two entries.
1 hour ago, WolliBer said:The comparison with the commands in G-code is flawed. In particular, if the numbering in the code is not absolutely necessary, it should be a matter of course to start with 1.
It's not necessary, but it has become convention. There are plenty of programs and plugins for programs that look for these lines because almost all software that produces g-code puts them in there. "Part of the specification" and "de facto part of the specification" are very often treated equally.
1 hour ago, WolliBer said:I know from my own training that you start loops and arrays with 0, but then it is the programmer's job to adapt his work to reality. I have less and less understanding for these sloppy ways of working.
Ignoring the sexism, you can start your arrays at 143 if you want to. It's easy! Here's some Python:
for item_index, item in enumerate(sample_array, start=143): do_something(item)
But when you're working with lower level languages, you have to start at 0 because the processor starts at 0. Why does the processor start at 0? Because if you clear 8 bits to store a short integer, it picks a location in memory and writes 0 eight times.
Why do processors work like this? It's more efficient, for one. It means you can store 256 values in a byte instead of 255. And overwriting memory with the same value for each bit is a lot faster than counting seven bits then putting 1. Plus there's the whole "legacy" thing: the instruction set in a normal PC's x86_64 (plus god knows how many extensions these days) dates back to 1978 (actually sort of interesting how Intel and AMD have mutually assured destruction these days, but that's a story for another day). You didn't have a lot of memory to play around with then. And even fewer CPU cycles to spend playing with that memory.
1 hour ago, WolliBer said:WHY should humans adapt to the work of computers just because "a" programmer is too lazy to start his loop at 1? - Unfortunately, this problem is very pronounced and your comment shows that you also understand it and try to justify it with comparisons that don't fit. - Very incomprehensible!
"A" programmer? You forgot the "lmost all" that follows that. And ignoring the sexism, it's also for consistency. I'd $%@(ing hate it if I had to try and remember "Okay, is this language 0 based or 1 based?" whenever I got into a programming session. Since they had very damn good reasons to start at 0 when they started this whole thing, it's just made sense to carry that forward.
And if you're wondering for how much I'd have to remember if it's 0 or 1 based? C++, C# (uses a C-style syntax but isn't a direct descendent, unlike C++), Java, Python, Kotlin (it's like Java and Python had a baby), BASIC, Pascal, ECMAScript (the proper name for JavaScript, since that isn't actually related to Java), Lua. I've played around a bit with Rust. And then let's not get into markup languages.
1 hour ago, WolliBer said:People should not adapt to computers! Computers, machines and programs should / must adapt to humans. The number of different programs is too large to have to ask yourself every time how they are counted and whether the programs and displayed values are "compatible" or whether I have to convert them.
I would baselessly (no pun intended) say at least 98% of computer users never have to concern themselves with counting being zero or one based. Fun fact: zero wasn't really even a concept until about 525 CE. I'd love to use that fact to compare you to a flat earther, but this a proper discussion.
What justification is there for all programmers, everywhere, to have to adapt to one particular way of doing things (which isn't the one they're familiar with) for the vast minority of people who deal with stuff like g-code but not a programming language, when we're quite happy with the one we have, which makes sense to us?
Reductio ad absurdum: Other countries should adapt to us English speakers. The number of different languages is too large to have to ask yourself every time whether nouns have genders and where adverbs are placed relative to their verbs and whether a sentence is "compatible" enough to have an easy, direct translation or whether I have to work out roughly what it means? What justification is there for people all around the world who speak French as a native language to speak English just so life is easier for the vast minority of people who have to fluently use and switch between both in their day to day lives when they're happy doing it their way?
1 hour ago, WolliBer said:If the value in the G-code is not relevant, the probability that Klipper will make the error is low. In addition, the change of a layer from 1 to 2 from the line to the object can hardly be explained by an error in Klipper.
I didn't say it wasn't relevant. I said it's not technically part of the specification. Marlin has a convention that at the start of a file, you have comments stating the language, the estimated time to completion, filament used and layer height. It looks something like this:
;FLAVOR:Marlin ;TIME:1713 ;Filament used: 1.46019m ;Layer height: 0.2
In the Cura 5.5 beta, they made a seemingly harmless change: they put what machine the slice was intended for in there:
;FLAVOR:Marlin ;TARGET_MACHINE.NAME:Creality Ender-3 V3 SE ;TIME:1713 ;Filament used: 1.46019m ;Layer height: 0.2
These lines, while not part of the specification, just convention, can be read differently by different printers. That seemingly harmless change made printers made by Creality unable to read the estimated time, filament and layer height. Other printers were fine. Technically, it shouldn't matter in the slightest. In practice, it mattered, because they expected things to be the way they were, just like printers and software expect to start at layer 0.
For the release version of Cura 5.5 they moved that line down to below the line for layer height. Creality printers no longer had a problem. Other printers never had a problem. So specific firmware can and does @$%# itself sometimes for things which are perfectly by the book. And without seeing the g-code which gives you that potentially erroneous reading for layer number, it's basically impossible to rule out any of the possible causes.
Edited by Slashee_the_Cowadded another sexism shoutout
.thumb.jpeg.0b7a05eafc09add17b8338efde5852e9.jpeg)
Recommended Posts
Slashee_the_Cow 299
The preview in Cura shows the layers counting as 1-based, because it is more friendly to the average user. However the convention in g-code, being machine instructions, is 0-based. Technically a g-code file doesn't even need to include the layer numbers, it's just common practice (like using G0 for travel moves and G1 for extrusion moves) and convenient for things like post-processors, although they can always count by themselves, but there's nothing stopping you from just increasing your Z value without putting a label on it.
It is possible for a model in Cura to start at a (1-based) layer higher than 1, since there's nothing stopping you placing models in midair (once you've turned off "drop down model", anyway) - I've actually done it to get something to print with a bit of support under it (so that it wasn't pressed against the bed) but without the hassle of using a full raft.
As for the descriptions and tooltips in the post-processing scripts: yes, they can be a bit confusing sometimes. I've found that most (but not all) of the time when you need to input a layer number, it is 1 based. As for how you do it before or after a layer - simple! When you see a marker for a new layer (or a script runs out of data for an existing layer) - after that layer is before the marker for the next layer (or the end of the data set for the layer you are on. Before the layer is immediately after the layer marker, or lines starting at 1 in the data set for a script (0 based, the first line is the layer marker).
As for the scenario described in your first situation, it could also be Klipper at fault. Without so much as the g-code to go by, there are far too many points in the chain where an error could be made to blame any specific one of them with certainty.
Link to post
Share on other sites
WolliBer 0
I do not agree with the statement and, above all, with the justification. Whether a computer starts counting its arrays or anything else with zero is completely irrelevant to me. But if a situation is discussed in nature, it should be self-evident for every programmer who leaves his workplace and touches a tree that he should start counting the picked apple at 1.
The comparison with the commands in G-code is flawed. In particular, if the numbering in the code is not absolutely necessary, it should be a matter of course to start with 1.
I know from my own training that you start loops and arrays with 0, but then it is the programmer's job to adapt his work to reality. I have less and less understanding for these sloppy ways of working.
WHY should humans adapt to the work of computers just because "a" programmer is too lazy to start his loop at 1? - Unfortunately, this problem is very pronounced and your comment shows that you also understand it and try to justify it with comparisons that don't fit. - Very incomprehensible!
People should not adapt to computers! Computers, machines and programs should / must adapt to humans. The number of different programs is too large to have to ask yourself every time how they are counted and whether the programs and displayed values are "compatible" or whether I have to convert them.
If the value in the G-code is not relevant, the probability that Klipper will make the error is low. In addition, the change of a layer from 1 to 2 from the line to the object can hardly be explained by an error in Klipper.
Link to post
Share on other sites