Does MULTIPLE_PROBING not apply to G28? It probably should if it doesn't.

Nope, it doesn't. I have it configured for 4 probes per point, and it does exactly that during G29, but homing is just a simple double-touch.

For homing the general recommendation is to use a larger HOMING_BUMP_DIVISOR for Z. Slow probing is known to greatly increase accuracy.

I have the divisor at 8, but there seems to be no difference in accuracy compared to having it at 4.

(EDITED, I originally thought I'd changed it to 4. Nope)

What kind of repeatability do you get with your probe?
How out is it typically?
What kind of probe design is it?

I suppose it makes sense to have the probe follow probe settings instead of Z homing settings. I'll look into implementing this in my copious free time.

Sorry for the delayed response, can't exactly run M48 while there's a print going. 😄

For repeatability, that's what I meant by the 0.0015/0.006 values, but here's some representative best and worst output, done with the nozzle at 215°, bed at 65° (idled there for a minute or so before starting):

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.004000 Min: -0.006 Max: -0.002 Range: 0.004
Standard Deviation: 0.001611

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.056437 Min: -0.074 Max: -0.033 Range: 0.041
Standard Deviation: 0.013308

That higher reading is actually worse than before, which I guess is a good thing in this case.

I'm not sure what you mean by how "out" it is... how wrong, you mean? That's what I meant by the 0.2 mm guess; either it's dead on where I wanted it, and I get a perfect first layer, or it's off by a few tenths of a millimeter (I'm not sure how to measure it), there seems to be no in-between.

As for the probe design, it's one of these: https://www.ebay.com/itm/292154003394

there seems to be no in-between.

Do you get good probes after a reboot, but worse ones if the machine has been on a while?

Do you notice differences with a heated versus cold bed?

I have not tried to print on a cold bed. Haven't had occasion to do so, and being Printbite-covered,[*] I'm not sure that I could, except with flexible filament, which I don't have.

It does seem like the home position is wrong most often right after a reboot or when the machine has been idle for a while, but not as a factor of bed heat - I tried to control for that by letting the machine sit, heated and ready, for a good 15 or 20 minutes, and still got a bad home.

It also seems like if I get a bad home, it's virtually guaranteed to be good on the next print, and the next several after that, so long as I don't let the printer sit for too long between good prints.

It's almost as if the loss of precision that comes with the steppers shutting off during M84 or idle hold timeout, is not being corrected-for initially. That's the only thing I can see that's common between bad homes.

FWIW, here's the best and worst M48's with the entire printer cold (room temp ~19°C when I sat down, guess I shoulda turned the heat on today 😄 )

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.050062 Min: -0.051 Max: -0.048 Range: 0.004
Standard Deviation: 0.000946

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.075625 Min: -0.107 Max: -0.057 Range: 0.050
Standard Deviation: 0.017930

So, similar to when heated.

Oh, I should mention, the sensor that's on my bot is fairly new, having been purchased to replace one that went bad. It's been a problem for quite some time, with both sensors, and even back when I was just using a Z end stop switch, but I always dismissed occasional bad homing as normal behavior.

[*] I've experienced this "bad homing" on plain, unadorned glass, too.

so long as I don't let the printer sit for too long between good prints.

So obviously, static buildup. 😉

Hmm… Well multiple probing can definitely help then.

Static? Heh. You know, it wouldn't surprise me if it were exactly that. 😄

@thinkyhead Can we include an outlier filter into the mix when a higher number of probes is configured?
Just keep track of the min and max results and exclude them when averaging for the final value. Especially the piezo sensors can be sensitive to false triggers where just bumping the table will cause the probe to trigger.

It gets tricky. Homing sets the current position to Z_HOME_POS at the end, wherever the nozzle happens to be. This is requesting some tweaking of the final position (and a move back to 0 possibly), so it's a bit of extra work. It should be ok in the meantime to set the HOMING_BUMP_DIVISOR for Z to a larger value, and perhaps increase the HOME_BUMP_MM.

@thinkyhead add feature request label ?

missing label

This exists and now there is a hysteresis to throw out results that differ too much. This can be closed.

I can see the outlier filter has been added, but at what point was more-than-double-touch homing added?

Its been awhile, but the extra_probing bit is only a few days old.

/**

• Multiple Probing
• You may get improved results by probing 2 or more times.
• With EXTRA_PROBING the more atypical reading(s) will be disregarded.
• A total of 2 does fast/slow probes with a weighted average.
• A total of 3 or more adds more slow probes, taking the average.
  */
  //#define MULTIPLE_PROBING 2
  //#define EXTRA_PROBING 1

Right, but MULTIPLE_PROBING is only for sensing the bed during G29 leveling, is it not?

No, it applies during G28 as well.

Just out of academic curiosity, can you point me to the commit that made that particular change?

At a quick read of the code, it seems to have G28 trigger bump for a second hit not actually looping using the number since it sets just as a true/false. Also the extra_probes isnt applied in G28, just G29 so it does appear there is room for a bit more improvement at least to bring the two into parity completely.

May I add something here?

You are looking at repeatbilty, I copied it from above:

>>> M48
SENDING:M48
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.050062 Min: -0.051 Max: -0.048 Range: 0.004
Standard Deviation: 0.000946

>>> M48 S E
SENDING:M48 S E
M48 Z-Probe Repeatability Test
Finished!
Mean: -0.075625 Min: -0.107 Max: -0.057 Range: 0.050
Standard Deviation: 0.017930

Now I don't want to comment on how good or bad these Range values are, compared to other probe types, ok? But a range of 0.050mm is definitely not the cause of your probe being off by .1mm or more.
What these numbers DO NOT tell you, is that the probe will measure a different absolute value on different occasions over the period of hours or days. You would need to run this M48 thing over a couple of days spaced at one every hour (which it cannot do) to see long time drift. So when the probe has a "bad hair" day, it will report a different value 10 times in a row with good repeatabilty but off by 0.2mm (perhaps) from yesterdays tries.

Inductive sensors and their siblings, capacitative sensors are slightly temperature dependant. And even if you have prepared the bed well with the aluminum foils and are able to supress stray magnetic fields, I don't trust them so much anymore.

And yes, @InsanityAutomation is right after looking at that code. G28 does not repeat like G29. But I really feel that even if it did, it wouldn't make things better - just 5 nice measurements all of them off by a millimeter or so since yesterday.

If you are interested in how much and why z-home could shift, watch
Advanced heated bed tests
Averaging some probes does not help at all.

(22 minute video.... tl;dw)

Wouldn't that only apply to setups that do not sense the position of the print surface, i.e. if a sensor reads the bed under the glass, or if you're just using an end stop switch mounted on the frame?

No, it'll move the top surface as well depending on temp probed at, soak time and potentially other variables.

... or if you're just using an end stop switch mounted on the frame?

That's a good solution to have the beds mounting points always at the same height. But usually with that you don't have problems with the repeatability of homing. So averaging will not help.

However. That will not help to get the first layer stick better. The beds surface moves in relation to the mounting points.

My recipe for our machines is:

• Prelevel the bed mechanically as good as possible to keep the z ways short while probing.
• A constant workflow
  ** home on cold bed (room temperature)
  ** bring the bed to temperature
  ** wait
  ** wait longer
  ** wait another bit
  ** be really patient here until the beds temperature stabilized
  ** probe the bed fast to give the (inductive) probe no chance to change temperature much (9 points in 15 seconds)
  ** print a good first layer (if the probes z offset is right. It's constant for me)

You may have missed earlier: I already controlled for bed temperature early-on in this thread, to the tune of testing first-thing in the morning, after sitting turned-off overnight (and waking-up to 19°C room temp) as a "cold" test, and also testing only after allowing 15-20 minutes just sitting at the target temperature, for a "hot" test.

Plus, being TR8 screws, Z-homing after most prints is quick since I don'y routinely print big stuff. I don't run G29 per-print anymore, either.

I'm 100% certain that whatever issue my bot has with homing, it is not temperature-related (or the majority of the difference, anyways).

Temperature is not the only thing that throws off inductive probes.

It's enough to place a metal tool or something close to the printer.

Here's a small test for you:

Lower the nozzle using the LCD by .1 mm steps until the probe's red light goes on (it triggers). Then back off .1mm and the probe light will just go off.

Now they have a very slight hysteresis, but now move your hands, or a metal screwdriver close to the probe slowly and note how the probe suddenly triggers. Try moving other stuff, and try to get a feel for what else might be influencing the trigger point of the probe by 0.1mm, which is the amount we are more or less looking at right now.

Once you get a feel for how flaky this inductive sensor really is, you will see the problem.

You could also position the sensor as I described above, .1mm above the trigger point, and then check a day later if going down .1mm will trigger the probe same as the day before.

If occasionally triggering to early/high - it could be a false positive caused by electrical noise.
Sometimes inducted by a surprising source like a near by desk lamp being on or off.

How are your noise filtering settings? Did you try to increase them? Is there any hardware denoising?
Is the processors internal pullup resistor on or off?
What voltage gets the probe? How is that made? What else gets this voltage from this power supply? For example cold-end-fan. Are that users always in the same (on/off) state?
How do you get the signals 5/3.3V level? If by a voltage divider - are the resistors values very high?

@bigironguru I have controlled for stray bits of metal and magnetic fields, too.

@AnHardt

• Noise filtering/Denoising: I have none in place that aren't already part of the hardware, and no firmware-based filtering that I'm aware of.
• Internal pullups: no idea on that. Probably enabled, though.
• Supply voltage: probe is fed 12v from the main 30A power supply, which handles motors, heaters, etc.
• Usage: everything that draws power is in a consistent state i.e. when homing, X/Y/Z motors are on, extruder motor is usually off, cold-end and controller fans always on, hotend and bed at their needed temperatures, and so on.
• Probe signals: it's a NPN-NO probe, so there are no voltage divider resistors -- this type of probe uses an open-collector output, and pulls the signal line to ground when triggered, or tri-stated/high-Z when idle.

Ok, here is the next version of the modified homing code for discussion:

G28 Z
                                                          
echo:Home bumps for Z
                                                          
echo:EXTRA PROBING = 2
echo:MULTIPLE PROBING = 5
echo:TOTAL PROBING = 7
echo:BUMP = 3.00
                                                               
echo:bump loop begins
                                                          
echo:measured pos = 3.01
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 3.00
echo:measured pos = 2.99
echo:measured pos = 3.01
                                                       
echo:bump loop finished 
                                                       
echo:min pos = 2.99
echo:delta pos = 0.01
                                                          
X:64.00 Y:102.00 Z:5.00 E:0.00 Count X:12800 Y:20400 Z:4000
                    
ok P15 B31

The debug SERIAL_ stuff is just for info for the following questions and discussion:

Oh, and currently we are assuming to talk about the Z-AXIS and using a probe. Much of the following is also true for the other axes, but there you have less impact if the home is slightly off.

1. The TO stipulated using the minimum value - to ensure that a EEPROM stored distance to the bed would not be to high. Of course using the minimum value negates any advantage of statistics (median, average, standard deviation) in determining the most probable position that a homing operation produces. But it would be no problem at all to use the average as is done in probing.

2. What is now to be done? Well, I suppose, correct the current position by delta_pos without actually moving the axis. Shall I put the stage I have reached out as a PR so that others can help and chime in?

Everyone should be aware that this will not help you if your probe values drift over time even if it has good repeatability.

If you have 7 homing bumps, see above, with a range of 0.02mm this morning but absolute values are 1mm different this evening, you have a real problem - the bed is actually further away or closer than the stored value, or the probe thinks so - and that can only be fixed by a bed probe (perhaps of a single point in comparison to the stored value).

@FanDjango Do you think that your modifications are PR ready, or just a concept?

@qwewer0 80%. Here's what is missing at this stage:

Discussion and decision as to how to proceed.

Apart from outliers, the average of all (sufficiently numerous) homing probe operations should always report having moved in by the amount that we had bumped outwards. If the standard deviation here is high, then the probe is no good, but the average should be correct. If the average is wrong, then you have defined incorrect steps/mm in configuration.h.

Let me give an example -

5 slow homing approaches into the endstop, say 2.95, 2.99, 3.00, 3.00, 3.01.

Remove the 2.95 outlier, then the average of the rest is then 3.00, as expected, taking note of the range, which is 3.01-2.99 = 0.02.

The last approach was 3.01 and then a 3.00 move outwards will have been done. Depending on the endstop accuracy, nobody knows where we are now physically, we only know where we most probably are (i.e. 3.00mm out on average).

Now I need to decide:

Do I correct my position (to be real safe) to the farthest away (from the bed i.e. to 2.99), as @VanessaE requested? That would make sure that I would not be too close to the bed. But note: In that case I am assuming the most improbable position, which would possibly be different on each home, and therefore make the stored mesh unusable.

The real point of the excercise is to choose the most probable position, which is given by the average (i.e. 3.00 in our example, which needs no correction (by definition).

My opinion: The cat is byteing its tail here. There is no way to be absolutely sure of where the axis is, physically, as the last one of the multiple homing operations is subject to the full inadequacies of the limit switch or probe. I can see the range, the average and the std_deviation after multiple homes but the last home of that sequence will take me somewhere, dunno where.

@AnHardt wrote:

My recipe for our machines is:

Prelevel the bed mechanically as good as possible to keep the z ways short while probing.
A constant workflow
** home on cold bed (room temperature)
** bring the bed to temperature
** wait
** wait longer
** wait another bit
** be really patient here until the beds temperature stabilized
** probe the bed fast to give the (inductive) probe no chance to change temperature much (9 points in 15 seconds)
** print a good first layer (if the probes z offset is right. It's constant for me)

It's what we do too: We do a fast bed probe before every print. That's why I was so keen on speeding up the bltouch operations some time ago together with @InsanityAutomation.

So my current code currently actually tells me the range, the average and the std_deviation of multiple homing operations on each individual axis. But there seems to be no sensible corrective move that would occur to me. A search on homing operations of other machine types, robots and so on, yields no solution. Perhaps someone else would like to propose some ideas?

A maxim of computing is that you cannot use garbage input to do anything useful until you are able to separate what is garbage from what is meaningful … but if you can do that, you actually do have meaningful input. What you want to do is get your standard deviation down as close to zero as possible and then proceed from there.

A maxim of computing is that you cannot use garbage input to do anything useful until you are able to separate what is garbage from what is meaningful … but if you can do that, you actually do have meaningful input. What you want to do is get your standard deviation down as close to zero as possible and then proceed from there.

With my respect, but I think you miss the point.
Repeatability is near perfect with my probe. The problem however is that G28 that happens before any print is not accurate (compared to your last G29) and I cannot reproduce the same reliability that I can with the M repeatability command. I believe that is the Gist of this issue as also described by @FanDjango here - #9802 (comment)

@FanDjango Would you mind sharing your homing code with us?
Are there any other news on the multiple probing for homing stuff?

Humm
My 2 cents about the root cause here... I hade exactly the same problem: after the machine was idle for a while, the first few z moves would be inaccurate...

I ended up having the machine zero then verifying the 0.1 distance to the bed with a sheet of paper... (yes I never calibrate with a hot bed). After 2 to 5 tries it would be better...

So I pointed to the software until it occured to me that the problem was more accute when it was cold...

As an experiment, I cleaned the machine removing the old oil and bingo, it was better, lot better: on the first try it was good... So I think I was facing stiction.

So I guess the solution would be to use mechanical dithering as was proposed once by @AlessandroAU under #15354 ...

I started to develop something around that but stopped when I could not use my printer anymore...

The trick would have been to vibrate the z axis by moving back 12 ticks, then position, then back 9, then position, then back 3... you get the idea.... I was hoping to break the oil stiction...

Didn't see this ticket before I made #22139 (closed now) - I never realized that double-probing Z wasn't a feature until it mysteriously disappeared. I tracked it down to being dependent on the HOMING_BUMP_MM for Z in the end, which I had disabled as instructed by the comment for SENSORLESS_HOMING.

@FanDjango did you continue work on this?

If there is to be a MULTI_HOMING and a EXTRA_HOMING behaviour, why not just restrict this to Z-AXIS homing and use the values chosen for MULTI_PROBING and EXTRA_PROBING? No new configuration options, no changes there?

This is basically what I outlined in #22139 and I think it would be a good solution and make sense, because when I see "mutli probing" I would assume it applies to ALL uses of the probe, not just ABL.

If no other solutions have been pulled in/suggested I am going to work on decoupling Z from HOMING_BUMP_MM for probe-based homing, and instead just respect MULTIPLE_PROBING and EXTRA_PROBES.

No, I am sorry. I have abandoned this topic.

After a fast home approach, stop, bump out and a subsequent slow precise approach and stop, what is the precision advantage of doing more slow approaches, say another 5?

Your precision as to what position you are in depends solely on the last of these approaches and can be quantified as range/variance/std-dev/min/max, but it will be the same error(=lack of precision) as the first slow approach.

Unless your endstop becomes more and more accurate from each approach to the next (like the switch getting "happier" somehow?). In that case, just home 10 times.

Bed leveling algorithm allows for multiple probes for a reason. There is incentive to take an average of probes to be more consistent in the end result and prevent an outlier from determining the end result. Why shouldn't homing have the same option to give more consistent results for z=0?

Multiple probing to adapt to an unknown relative to the (believed) known is not the same as homing, where you establish your position relative to nothing other then the endstop.

If you are so sure, then you tell me, after (say) 5 home/bump moves, how far would you bump out on the last of the sequence? Regardless, even if you don't bump, to what value do you set the axis, if not 0 = zero?

You can home 10 times and if the last one is an outlier, how do you know? Unless you check it against a second value that you trust more.

When probing, this is what you are doing. You are comparing the probe values to the home result.

If the bed leveling matrix is positioned relative to the z=0 homing endstop then having a more reliable location value for the homing endstop is desirable.

Generating a location average for the homing endstop via multiple homing probes will give a more accurate location for the homing endstop on average; hence the reason why muliple homing probes are desirable.

While I wouldn't bother with something as crazy as 10 probes to home, finding the outliers is trivial: just pick the highest and lowest readings and toss them out, wherever they are in the list of results, and regardless of their differences from the next highest/lowest values in the list. Then average the rest.

Or you could get fancy and calculate standard deviation and toss out any readings that are 1 SD off from the median, then take the average of the remaining readings, or something along those lines.

Doesn't bed level probing do one of these anyway?

VanessaE you make my point. Unfortunately, homing position z=0 does not allow for multiple probes and the bed leveling matrix is positioned relative to the homing position z=0. Allowing multiple homing probes (obviously for purposes of creating an average) for homing position z=0 will give a more accurate position for z=0 with which the bed leveling matrix can be more accurately positioned against.

The difference between any one probe and the average of a number of probes obviously depends on the accuracy of the probe.

What you are saying, is to home once (1 fast/1 slow), and then to probe a couple of times to that same endstop and reposition slightly, depending on your readings of probing the endstop that you homed on.

Mathematically unsafe. You still only end up at a position that is as precise as the home, only different.

I'm out of this after having played with it for a while. Somebody precisely specify the steps, then someone can code it, maybe

FanDjango, you don't even know how accurate home is from the initial 1 fast/1 slow homing until you make additional probes to get a better average result. The number of probes for homing should be determined by the user and how accurate the probe is.

Better result relative to what initial position? When you probe, you get results relative to where you firmly believe to be. When homing, you try to set where you are.

Here is an example:
You home to the endpoint. Motion stops.
You set axis to 0.
Now you go out 5mm. You are now at+5, ok?
Now you probe to the endstop and you needed steps for 4.9mm and reached the endstop.
Hmpf, go out again 5mm, probe again, repeat this a couple of times, : 4.8mm 5.3mm 6mm (outlier),
We are in at the endstop, and is this zero or -0.1 or what?

I would actually suggest multiple approaches to the endstop, and then adding a value to the position depending on the observed range, to avoid a movement to ZERO ever triggering or exceeding the endstop position. Your precision in knowing where you really are (physically) won't get better, but you can be sure to not exceed the machine limits.

Personally, I just want to have some assurance that my probe actually went off at the proper endstop point. For my purposes, 1fast/1slow is enough: fast to get the rough position of "0", and then another slow to actually home with higher accuracy (due to slower speed). Currently this is not how it works - you just get 1 fast UNLESS you happen to have HOMING_BUMP_MM > 0 for Z.

I think the bickering over semantics in this thread is disatracting from the issue at hand. The issue is that this:

Have Z go down at normal home speed, trigger the sensor, bump up by the configured distance, then down again at low speed until the sensor triggers again (so exactly as it is now)

Is not "as it is now" and was in fact an outlier/relatively unintentional and completely disconnected from MULTIPLE_PROBES. If we drop the need for having EXTRA_PROBES this just simplifies the config & makes MULTIPLE_PROBING do what it says on the tin.

In regard to EXTRA_PROBES, yes - if you're setting the axis 0, it can be hard to average that, sure. But if your fast/slow SETS 0, then you come back with n number of EXTRA_PROBES to verify that, it would at least allow for a homing/endstop error if things were WAY off.

Adding my +1 to this request. My end stop deviates up to 0.1 mm even after increasing my bump divisor.

Wow ok I can confirm this in marlin-bugfix-2.1.x that's strange... by HOMING_BUMP_MM was 2, and I set it to 0. Double Z probes stopped suddenly. While leveling dual Z with G34 it did check twice though, just not when homing. That really confused me. I think that the number of Z probe checks should be consistent and respect the MULTIPLE_PROBING value during G28, or be defined separately. My old bugfix-2.0.x config just says SENSORLESS_BACKOFF_MM { 2, 2 } and HOMING_BUMP_MM { 0, 0, 0 }, yet always double probed Z so I assumed that was normal. Either this needs to be documented in the comments or the behavior changed.

+1 vote for this. I have a lot of issues with inconsistent z-homing results. 95% of the time, it's good enough. But 5% of the time, its way off (usually, nozzle way too low). I have swapped main boards multiple times, swapped endstops multiple times, and have experimented with firmware noise filtering, none of which have helped.

I am certain that taking the mean (or better yet IMO, the median) of multiple z-home measurements would solve my problems.

Note that I am not using UBL or any other form of mesh compensation.

Added PR #27523 to add this feature. I implemented it as a new flag ('P') to G28. With this flag it will use the same algorithm as bed leveling probing meaning that MULTIPLE_PROBING and other options such as turning off bed the heater and stepper motors can all be configured and used (i.e. it uses the same settings as bed leveling probing).

See the PR for more details and in particular, take a look at the section I wrote undet the 'benefits' section that relates to how the existing MULTIPLE_PROBING and EXTRA_PROBING options actually work as it is actually a very good solution/algorithm IMO. I saw a number of conversations in this thread that lead me to believe that some people may not be aware of what the algothm is doing so i documented it. If the PR is approved I will add this documentation somewhere in the Marlin docs and link to it in the appropriate places such as G28 and G29 gcode documentation.

Motivation

I got sick and tired of my nozzle randomly scraping on the print bed and having to clean out my direct drive every time this happens (especially with TPU) and so i finally got motivated enough to make this PR.
I hope this gets approved/merged and it will help all of you as much as it has helped me :)

Just reporting back now that I have had this change “in production” for 2 weeks. My machine is now “fire and forget” and putting down phenomenally good and reproducible first layers!
One thought on my mind is whether to:

1. Keep this as a flag (‘P’) to G28
2. Remove the flag and make it a configuration option for all G28 gcodes.
3. Keep the flag but also make it a configuration option, in which case the ‘P’ flag becomes redundant when configured to be enabled all the time for G28

I have found that having a flag is useful as I can also do ‘quick homing’ when all I want to do is load filament or some other maintenance related activity that does not require high precision.
The downside is that while I can easily configure the flag via Cura’s configurable print start gcode sequence, I still find I sometimes need to modify gcode files such as when running a linear advance calibration generated from the Marlin website.
As an aside, the P flag works really well with the ‘O’ flag which skips homing if it has already been performed. Only downside is that you have to be careful not to do a G28 without the ‘P’ option and then print as the ‘O’ flag doesn’t distinguish between a regular G28 and a G28 P (maybe it should?)

Amazing work! I really hope the maintainers consider merging this functionality, more precise homing is STILL a pain point even now, years later.

As for exposing a runtime parameter vs a compile time configuration, it seems to me that ideally we can do both? Set a default value in the configuration file. But allow runtime override via a G28 parameter? The strengths of both approaches with minimal additional user facing complexity