`measure every` command / button

[ipatch]

Downloaded the latest v1.3 release this morning, and the app goes through its motions quite well, but not sure if the measure every command / button is suppose to do. I assume it's suppose to measure / plot a circle every 10mm within the build plate in a grid like fashion?

When I click the button I get ~ two circles filled in, then the operation stops.

Below is a video describing what is going on with my printer with the latest v1.3 release.

https://youtu.be/5hH2RmXTXfQ

[npiegdon]

That is very strange behavior. (Your guess is correct: the "Measure Every" button generates those bed-wide, evenly-spaced sets of points.)

This is curious because the way it does things is almost identical to manually clicking around: whenever a new point comes in from the printer, it finds the next-closest point in the "list of points we need to probe" (or none if the list is empty), then "clicks" the bed in that spot (using the same MeasurePoint function as actually clicking the bed with the mouse).

So it's a very serial process. The only reason it might stop after just a few points is because it's waiting to hear back about the last Z height measurement it requested.

Have you noticed if your clicks are ever spuriously ignored? (What if you click right after a point is reported? I can't imagine some printers need a delay between their last feedback and their next instruction... that would kind of defeat the purpose of nice, buffered serial communication. (The idea behind G-code is that you should be able to dump the whole file to the printer at once and get the same result as feeding it line-by-line.) Hmm.

[ipatch]

okay, had to spend the majority of the free time i did have yesterday doing physical fixes for my printer, ie. clogged heat break 🙄 nozzles, and various other BS.

opened up visual studio today, and noticed a few things related to the MeasureNextPoint method when running / calling the method from clicking the button with the label Measure Every:

i have the distance set to 10mm, but looking at the output it appears the measuring across the x axis is going in increments of 30mm instead of 10mm, and then when the probe reaches the edge of the build plate going across the x axis the routine stops, with a total of 5 points probed.

---

---

Also something that peeks my interest is the output of the measure every routine, and just clicking on a point does the same, I'm seeing the below output in the text area, specifically the text with the output of Count and all that follows it.

X:140.00 Y:150.00 Z:5.00 E:0.00 Count X:11200 Y:12000 Z:2000

did a search through the source and did not find any text string that matched Count: , so that's more likely something my printer is outputting via the serial port, so i'll have to try and figure that one out, and it could why the routine is ending before it "counts" measures every point.

Also there's a lot to unpack in this code block, but I'm going to try and see what is going on with the vector and just looking at things, not sure why there is a : 75.0f in there? 🧐

private void MeasureNextPoint()
        {
            if (port == null) return;
            if (toMeasure.Count == 0) return;

            var (w, h) = BedDimensions;
            Vector2 current = new Vector2(w > 10 ? w / 2.0f : 75.0f, h > 10 ? h / 2.0f : 75.0f);
            if (points.Count > 0) current = (from p in points select new Vector2(p.X, p.Y)).Last();

            var next = (from p in toMeasure let distSq = (current.X - p.X) * (current.X - p.X) + (current.Y - p.Y) * (current.Y - p.Y) orderby distSq select p).First();

            toMeasure.Remove(next);

            // If we've already measured it, don't measure it again
            if ((from p in points where p.X == next.X && p.Y == next.Y select p).Any()) MeasureNextPoint();
            else MeasurePoint(next.X, next.Y);
        }

hope this helps shed some light.

[npiegdon]

The "count" lines are definitely from the printer. I'm not 100% sure what they're for, but if I had to guess they're the "step" counts sent to the stepper motors to get in the current position. That's a kind of unit-less measure based on how many poles are in the motors.

For what it's worth, those lines should be ignored by the app because they don't begin with "Bed X:". In every screenshot I've seen with Marlin 2.x firmware, that count line always comes in just after each "real" position line.

Regarding the "current" vector definition line, here's the breakdown:

• Vector2's constructor takes two parameters: an X and a Y (or width/height, or whatever you happen to be using it for).
• Each parameter is evaluated using the ternary operator (called the conditional expression in C#). w > 10 ? w / 2.0f : 75.0f h > 10 ? h / 2.0f : 75.0f
• On separate lines, they should look pretty symmetrical. The first line translates to "if the width is greater than 10, the current-X is half the width, otherwise just call it 75."
• When there is a "sensible" width and height typed into the boxes in the app, it just starts the "current" probing location in the center of the bed: half the width, half the height.
• When there isn't a "sensible" width and height, the fallback "75.0f" values are just a safety measure to keep things away from the edge of the bed (or in negative values or something like that). My own printer happens to be 150x150mm (and I've never seen a printer smaller than 100x100mm), so guessing the "default" center of an unknown printer with bad/unknown dimensions at 75x75mm seemed safe enough.

Hopefully that clears up what's going on there.

[ipatch]

not the best solution but a workaround until a more permanent fix can be applied, is to click on the far left of the black box ◼️ and when the measure every routine reaches the far right ie. for my case ~ 300 on the x axis, is to click on the far left again, and the print head will move along the x axis again until it reaches ~ the end of the x axis for that particular point clicked on y axis. it's difficult to explain in words, but here's a picture for the time being.

---

---

On another note, my print bed is 300 by 300, and when clicking the measure every button it was calculating the difference between each point along in the x axis in increments of ~ 30mm as opposed to the 10mm listed in the text input field.

[npiegdon]

Wait, is this because your measurement probe is going off the side of your bed so it can't take a reading anymore? That sounds like #8 and something that seems to be happening to several people.

Is your probe inductive? If you put something metal over there where it usually stops, does that get it to resume?

... when clicking the measure every button it was calculating the difference between each point along in the x axis in increments of ~ 30mm as opposed to the 10mm listed in the text input field.

Hmm, looking at the GeneratePattern function around line 300, I can't see any way it might have made that mistake. It steps both loops from 0 to width/height in increments of whatever number is typed in the box. There isn't a numeric division or anything like that to get backwards.

I don't suppose there's some global scaling factor of 3x set someplace in your firmware? That would explain this problem and work as an alternate explanation for why the print head is trying to walk off the edge of the bed, too.

[ipatch]

yeah, i'm using an inductive probe that is mounted to the right side of the print head if looking at the front of the printer.

\/ U

• the \/ symbolizes my nozzle
• the U symbolizes my inductive probe

---

will take a look at #8 and see what i can gather.

---

Wait, is this because your measurement probe is going off the side of your bed so it can't take a reading anymore?

No, not really, the probe gets towards the edge of the print bed and then stops, or it just doesn't continue on to the next point to measure within the vector for whatever reason. I messed with the visual studio debugger, stepping in and out of methods / functions, and using that interactive dialog, and still could not find what was causing the abrupt stop in measuring every point. As stated before when the measure every reaches what it thinks as the end of the x axis the app stops measuring, and for all that i can tell it's idly waiting for input.

If i click on the far left of the black square ◼️ it starts measuring points and gradually moving the nozzle & probe only along the x axis until from what i can tell the probe reaches ~ 300 mm and the routine stops.

All measured points are along the same y axis coordinate but as stated before the probe and nozzle gradually "increase" in the x coordinate space

[npiegdon]

Alright, my guess is that the v2 release can solve this through some combination of the new bed dimension input (specified as left/right and top/bottom instead of just width and height) along with the fully-exposed serial port options (click the "..." next to the COM port box).

Feel free to reopen this if you still aren't able to get it working. Thanks!