heightmap.csv not compatible with "0" values, "0.0" works fine

gnydick

If your heightmap has a "0" in it, like from when I manually edit it, to tweak the values, up or down wholesale and excel exports "0" rather than "0.0"

you get a black hole in the mesh when you visualize it. I'm not sure if that also means the firmware is going to have a problem using it.

fcwilt

I would think if the visual display is wrong the firmware would have the same problem.

And how exactly do you determine what to edit and by how much?

Frederick

dc42

The firmware uses 0.0 to mean zero height error and 0 to mean that the point was not probed so the height error needs to be extrapolated.

gnydick

interesting. just curious, why not use NaN or something similar? Is it low level code with strict types and you have to use a number?

gnydick

@fcwilt if you find everything seems to be tracking the contour of the bed, but it's too high or scraping, you can just download the heightmap, open it in Excel, increase all of the numbers by a little bit if it's scraping, decrease them if it's too far away.

The first two rows are not point data, do not edit them. After you save it, open it in notepad you have to clean it up in 2 ways.

if there are any "0", you have to change them to "0.0"
if there are any commas at the end of any lines, delete them

Then you're ready. right click the heightmap.csv file and choose 'Edit', then paste in the contents of notepad.

Viola, your heightmap is slid up or down, depending on what you did.

T3P3Tony

@gnydick you can do that but it's better to tune your Z offset so that when the bed is proved and the heightmap is created the map is at the correct height.

gnydick

@t3p3tony
of course, but sometimes the probing isn't just right. for example, my current glass bed is so warped and ripply, it needed some tweaking because you can only probe so many points

fcwilt

@gnydick said in heightmap.csv not compatible with "0" values, "0.0" works fine:

@t3p3tony
of course, but sometimes the probing isn't just right. for example, my current glass bed is so warped and ripply, it needed some tweaking because you can only probe so many points

You can probe some 400 points on the Duet WiFi/Ethernet - that seems like it ought to be plenty.

So how do you determine what needs tweaking and by how much?

Thanks.

Frederick

gnydick

@fcwilt

I don't have a probe currently installed, so I'm doing it manually. I don't really want to do that many points As it is, I'm doing 56. That also means there's no offset to change since I'm probing with the nozzle itself.

You can tell what needs tweaking by watching the first layer. My glass is so bad that within an 8mm circle, the bed can be so high that it's block extrusion from happening and across the diameter, the bed is so low that the filament doesn't make contact with the glass. So you can see if you need to do something about it. Like change how many points, where the points start.

Also, if your consistently always low or high, you can bump it up or down rather than manually probing again.

fcwilt

Hi,

So this is a delta printer?

Frederick

dc42

@gnydick said in heightmap.csv not compatible with "0" values, "0.0" works fine:

interesting. just curious, why not use NaN or something similar? Is it low level code with strict types and you have to use a number?

Are there many programs that accept .CSV files and allow NaN as an input value? One of the goals of the format was to use a file format that common programs can read.

gnydick

Well... CSV doesn't support data types. So, the general convention is with CSV that you usually control the producer and the consumer, so do whatever you want. If you're using CSV as an interchange format you just have to define and publish a data dictionary for any 3rd party that wants to consume it.

I wouldn't actually be concerned about interoperability, meaning, CSV is a pain to share data with, but if you're going to use it, people generally know that there are going to be little niggles like possible corner cases and out-of-spec values.

So, my advice, continue to use CSV and don't worry, use whatever values you want, people will have to adjust, as there are no standards to CSV other than termination, delimitation, and escaping and we're all used to having to deal with the pitfalls of CSV.

If you want to use something more robust that is typed and self defined, there are a plethora of data formats. XML is EXTREMELY robust because of the gigantic ecosystem of tooling around it: validation, formatting, transformation, etc. If you publish data in XML and do it correctly, there's no reason for anyone to ever have to contact you. But.... today's young developers have a hard-on for json and yaml, which both are on the extreme opposite end of the spectrum. They're no better than CSV, in fact, potentially worse because with CSV, you at least can assume certain structure. With those, I've seen all sorts of crazy incarnations.

So, to come full circle, I still say just use CSV. It's the happiest medium and least of all evils.