Marlin: M851 behaves strange (nozzle crashes into bed)

[christianh17]

Hello!

I use a prusa I3 clone with inductive z-probe. In the past (till RC6) I used a start script like:
G28 ; home all axes
G92 Z1.05
and the distance nozzle - bed was perfect.
Yesterday I decided to upgrade to the newest version (there was no issue with RC6 but I wanted to use the new one and perhpas give some feedback) and used the newest bugfix release from August 6th, in the morning.

Now I have a problem with the distance nozzle-bed.
The script from above does not work any more, after G29 the nozzle raises (i think it is Z_PROBE_TRAVEL_HEIGHT which is 5 in my configuration) and when I use the G92 command this actual height is used as the starting point.
So I decided to do it the "right" way and want to use the M851 command to adjust the height. So I started with different tests and numbers.

But I could not get it to work.
with M851 Z -2.6 the nozzle crashes in the bed doing the first printing move and with M851 Z -2.5 there are around 2 mm space between nozzle and bed.

My settings (I stripped all comments)

#define FIX_MOUNTED_PROBE
#define X_PROBE_OFFSET_FROM_EXTRUDER 25  
#define Y_PROBE_OFFSET_FROM_EXTRUDER 20 
#define Z_PROBE_OFFSET_FROM_EXTRUDER 1   
#define XY_PROBE_SPEED 8000
#define Z_PROBE_SPEED_FAST HOMING_FEEDRATE_Z
#define Z_PROBE_SPEED_SLOW (Z_PROBE_SPEED_FAST / 2)
#define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
#define Z_PROBE_DEPLOY_HEIGHT 0 
#define Z_PROBE_TRAVEL_HEIGHT 5  
#define Z_PROBE_OFFSET_RANGE_MIN -20
#define Z_PROBE_OFFSET_RANGE_MAX 20

I am not sure if it is a bug or if I did a big mistake in configuration.

Shall I send any more information?

Kind regards
Christian

[thinkyhead]

G92 can't be used for this kind of trickery anymore because it's been fixed. The software endstops now remain in the same relative positions. Thus if Z is at zero (Z_MIN_POS) when you issue G92 Z1.05 the new Z min-endstop is now at 1.05, so the nozzle cannot be moved below 1.05mm with software endstops active. The proper solution is to add 1.05 onto your M851 value instead.

[thinkyhead]

Your Z_PROBE_OFFSET_FROM_EXTRUDER is +1, so I assume your probe is the nozzle itself? Or, if you mean to use M851 Z-2.6 as the value, then your probe extends 2.6mm below the nozzle. In other words, your nozzle is 2.6mm from the bed when the probe triggers.

Do an M502 and M500 to make sure you have the defaults in EEPROM while testing.

[christianh17]

Perhaps the Z_PROBE_OFFSET_FROM_EXTRUDER setting is wrong. But I thought I can override this setting easily with M851. My inductive probe triggers when the nozzle is around 1 mm above the bed. But: with M851 Z-1 there is much too much distance between nozzle and bed. So I decreased the number and there was a very big step between M851 Z-2.5 and M851 Z-2.6. The first option had to much distance, the second crashed.

I will try this evening the M502 and M500 as suggested and will give a feedback!.
Thanks
Christian

BTW: My workaround for now is the following:
configuration.h: #define Z_PROBE_OFFSET_FROM_EXTRUDER -.8
start-script:

G28 ; home all axes
G92 Z-3

I have no idea why it works, but it does.

[brainscan]

Did you try without G92 or has it always been in the start script?

[christianh17]

When I used M581 I had only G28 and M851 in the start script, the G92 was deleted.

[rubimart]

I have the same problem. If the M851 is Z-2.2 the nozzle touches the bed. with M851 Z-2.1 the distance is over 2mm between the bed and nozzle.

Thanks You!
Marton

[Blue-Marlin]

@christianh17 , @rubimart
Please confirm you are at a new RC7 or RCBugFix. We have made changes in that area since RC7 was published.

[christianh17]

@Blue-Marlin: Unfortunately I did not use git and a local repository, I just downloaded the source code. The zip file ist from August, 6th 9:48 MEST. As far as I remember there were three commits on this day, so it could be after commit 5347f39fcebd8776a551a5a279130238a6a870c0 .
Did you do the changes in this area after August, 6th? Regards Christian
Edit: I forgot: Of course I am on RC7 bugfix.

[rubimart]

In Version.h it shows RCBugFix. I downloaded and unzipped the files August, 04. 13:59

[christianh17]

I just updated to 58c8e6cef2cbda97e39ba0979edc82df85d26975 and now it works as I think it should work. I use

G28 ; home all axes
M851 Z-1.1

in my start script, for me it means: the inductive probe senses the bed when there is 1.1 mm distance to the board. That is reasonable.
Thanks!
Regards Christian

[bgort]

I'm having a similar problem:

Using RCBugFix (58c8e6c), it seems that the M851 Z offset is ignored after G29. After G28, Z0 is where it's expected to be (nozzle just touching the bed); however, after G28 followed by G29, Z0 is above the bed by an amount that appears to be the same as my Z offset value (-0.8mm, or 0.8mm above), suggesting that the Z offset has been disregarded.

This is a new problem - everything was fine as of a few days ago, though after updating to the latest today I'm seeing this new 'behavior'.

I'll take a look at the most recent commits and see if I can figure out what might be going on, but in the meantime, any thoughts?

EDIT: I'm using ABL, grid mode.

[bgort]

Really strange.

I just reverted to RC7 and I'm seeing the same thing. After G28, Z0 is where it should be (nozzle touching the glass); after G29, Z0 is above the bed by what seems to be the M851 Z offset. I've done a M502, M851, then M500, but there's no difference.

I was having no trouble up until today. Scratching my head.

[bgort]

Back to the latest RCBugFix. I've sorted out that I can 'trick' it into 'working' by increasing the M851 Z offset from -0.8mm (nozzle on glass after G28, G1 Z0) to -1.5mm (nozzle on glass after G28, G29, G1 Z0).

I'm quite sure the -1.5mm offset would cause a nozzle crash after G28 if I were to send it to Z0 without first doing a G29, though I don't intend to try it.

[thinkyhead]

the M851 Z offset is ignored after G29

Changing the offset _after_ G29 is pointless. It must be set ahead of G29 (and also G28 if you home Z with a probe).

[thinkyhead]

@bgort What kind of probe are you using? A Z offset of -0.8 implies that your nozzle is 0.8mm above the bed when the probe triggers. Please ensure you are not using G92 or M206 anywhere.

I've sorted out that I can 'trick' it into 'working' by increasing the M851 Z offset from -0.8mm (nozzle on glass after G28, G1 Z0) to -1.5mm (nozzle on glass after G28, G29, G1 Z0).

That certainly is curious. What is your Z_PROBE_DEPLOY_HEIGHT setting?

[bgort]

Changing the offset after G29 is pointless. It must be set ahead of G29 (and also G28 if you home Z with a probe).

Understood. I am setting it prior to G28/G29,

What kind of probe are you using?

It's an IR sensor/probe, and though it's not as repeatable as I'd like, it's decent. There seems to be a +/- 0.05-0.15mm variance based on time of day (light entering from the adjacent window, I think), so will be replacing it with a BLTouch shortly.

[thinkyhead]

@bgort If you enable DEBUG_LEVELING_FEATURE and issue M111 S32 prior to G28, G29 then you'll get a lot of logging output in the console. By examining that we can perhaps figure out where the screwy Z position is occurring.

[bgort]

That's my next step. Was just finishing up a print and will try it directly.

[bgort]

Logged M851->G28->G29->G1 with both offsets, attached here. Some annotations surrounded w/*s.

serial.txt

[bgort]

Formatted with both CR+LF, in case the previous version is a mess.

serial-crlf.txt

[bgort]

Just saw your edited comment.

A Z offset of -0.8 implies that your nozzle is 0.8mm above the bed when the probe triggers. Please ensure you are not using G92 or M206 anywhere.

Yes, that's right - the IR probe triggers with the nozzle ~0.8mm above the bed. Replacing it with a BLTouch today, which should result in a more reliable trigger height (though I don't think that's a factor here).

I'm not using G92 or M206 anywhere.

That certainly is curious. What is your Z_PROBE_DEPLOY_HEIGHT setting?

#define Z_PROBE_DEPLOY_HEIGHT 15 // Z position for the probe to deploy/stow

[bgort]

@bgort: This is a new problem - everything was fine as of a few days ago, though after updating to the latest today I'm seeing this new 'behavior'.

Disregard this. Thinking back, I did experience some weirdness, generally, after moving to RC7 and then RCBugFix. At the time, I chalked it up to the new IR sensor being flaky (new printer, new sensor - a lot of moving parts at the moment), but I just worked around it by setting the offset to what was necessary after G29, and then moved on without realizing what was actually going on.

[bgort]

I've replaced my flaky IR sensor with a BLTouch, and continue to see the same issue. The Z offset necessary to put nozzle on glass at Z0 after G28 is now -2.40, while the offset necessary to put nozzle on glass at Z0 after G29 is -2.85. Happy to do another debug if that would help.

I don't believe this is just a configuration issue but is instead a bug, though I am, of course, open to configuration-related suggestions if you feel otherwise, @thinkyhead.

[thinkyhead]

@Roxy-3D Does this bed level matrix look healthy to you, or is this the sort that could throw off the Z position?

Bed Level Correction Matrix:
+0.999990 +0.000000 +0.004379
+0.000002 +1.000000 -0.000566
-0.004379 +0.000566 +0.999990

[Roxy-3D]

Yes, that looks fine. In fact... Unless they are printing something really big, this is saying they have their bed pretty level.

Check out the +0.000002 in the first column. That almost for sure should be +0.000000 but I think we are getting some floating point round off error. It is so far down into the 'noise' level it won't affect the calculations or positioning of the nozzle.

[thinkyhead]

@bgort After the above PR is merged give RCBugFix another test. It makes some adjustments to leveling that could possibly have some effect on this issue.

[bgort]

@thinkyhead Will do. Should have time today.

[bgort]

Just tried the latest. G28 was fine, as expected, but G29 directed the machine to forcibly remove the bed from the Y axis rail, and the X carriage from its rail. It tried to reposition in the wrong direction (+Y instead of the usual -Y, +X instead of -X), ignored the software endstops, and just kept going. Had to power the printer down to stop it. Other than doing a pull, no other changes were made to config.

I tried this twice and got the same thing both times.

Happy to dig in tomorrow; unfortunately I'm out of daylight today.

EDIT: I'd reversed the directions of travel; what's shown here now is correct. Add'l comment.

[bgort]

Saw this again this morning, then decided to 'start over' -- started with a fresh copy of current RCBugFix, copied over and verified my config, compiled, and uploaded, and now instead of what I previously described (traveling the wrong direction, ignoring soft endstops, etc.), it's doing all 9 ABL grid probes in the same place (close to the 0,0 corner).

I suppose it's possible something got out of sync after the last pull, though it doesn't look like it (my configuration, etc., is intact). I don't know.

[Roxy-3D]

it's doing all 9 ABL grid probes in the same place (close to the 0,0 corner).
I suppose it's possible something got out of sync after the last pull, though it doesn't look like it (my configuration, etc., is intact). I don't know.

This is going to be much easier to find and fix! Get the DEBUG stuff turned on and compiled in. Then do a M111 S32767 and do the G28 and G29 and post the log here.

[bgort]

Thanks Roxy. Sorry for the delay with this - busy weekend.

More weirdness.. I've attached a relatively heavily annotated log and my config here:
serial-08.21.16-crlf.txt
Configuration.txt

In short, it's doing strange things inconsistently, and I have no idea what's going on...

Happy to do whatever I can to help, however. Let me know.

[Roxy-3D]

That is a very nicely annotated log! I will try to squeeze this onto my list of 'To Do' items for today. Otherwise @thinkyhead will probably see this tonight. (He is a night owl!)

Here is a problem. I don't know the root cause yet. But you have:

#define X_MIN_POS 0
#define Y_MIN_POS 0

but at line 83 of the annotated log you have it trying to go to (X,Y) = (0,-1) :

*** ONLY A Z MOVE OCCURS ***
2016-08-21 07:34:27,558 - SERIAL - DEBUG - Recv: > do_probe_raise
2016-08-21 07:34:27,560 - SERIAL - DEBUG - Recv: do_probe_raise(8.00)
2016-08-21 07:34:27,562 - SERIAL - DEBUG - Recv: >>> do_blocking_move_to(20.00, -30.00, 8.00)
2016-08-21 07:34:27,900 - SERIAL - DEBUG - Recv: echo:busy: processing
2016-08-21 07:34:29,146 - SERIAL - DEBUG - Recv: Bed X: 0.000 Y: -1.000 Z: 1.769
2016-08-21 07:34:29,148 - SERIAL - DEBUG - Recv: <<< probe_pt
2016-08-21 07:34:29,151 - SERIAL - DEBUG - Recv: >>> probe_pt(0.00, -1.00, no stow)

it has to be associated with these first 2 lines of code. There isn't anything else between the creation and usage of yProbe:

        float yBase = front_probe_bed_position + yGridSpacing * yCount,
              yProbe = floor(yBase + (yBase < 0 ? 0 : 0.5));
...
        for (int xCount = xStart; xCount != xStop; xCount += xInc) {
          float xBase = left_probe_bed_position + xGridSpacing * xCount,
                xProbe = floor(xBase + (xBase < 0 ? 0 : 0.5));
...
          float measured_z = probe_pt(xProbe, yProbe, stow_probe_after_each, verbose_level);

[Roxy-3D]

I think we could figure it out with what we have already. But it will be a lot easier to just have it give us the answer. Can you change those 2 lines to be this:

SERIAL_ECHOPAIR("\nfront_probe_bed_position: ", front_probe_bed_position);
SERIAL_ECHOPAIR("\nyGridSpacing: ", yGridSpacing);
SERIAL_ECHOPAIR("\nyCount: ", yCount);
        float yBase = front_probe_bed_position + yGridSpacing * yCount,
              yProbe = floor(yBase + (yBase < 0 ? 0 : 0.5));
SERIAL_ECHOPAIR("\nyBase: ", yBase);
SERIAL_ECHOPAIR("\nyProbe: ", yProbe);
SERIAL_ECHO("\n");

And maybe... If you are so inclined, can you run a 'sanity check' on those numbers in your Configuration.h file? If you don't notice anything too crazy, when you run it with this extra debug stuff, we should be able to figure things out quickly.

[Roxy-3D]

Actually... The problem must be earlier. You have it trying to go to Y=-30.0 with #define Y_MIN_POS 0

2016-08-21 07:34:21,938 - SERIAL - DEBUG - Recv: deploy: 1
2016-08-21 07:34:21,941 - SERIAL - DEBUG - Recv: do_probe_raise(15.00)
2016-08-21 07:34:22,225 - SERIAL - DEBUG - Recv: >>> do_blocking_move_to(145.00, 131.00, 15.00)
2016-08-21 07:34:22,229 - SERIAL - DEBUG - Recv: >>> probe_pt(0.00, -1.00, no stow)
2016-08-21 07:34:22,233 - SERIAL - DEBUG - Recv: current_position=(145.00, 131.00, 15.00) :
2016-08-21 07:34:22,235 - SERIAL - DEBUG - Recv: do_probe_raise(8.00)
2016-08-21 07:34:22,238 - SERIAL - DEBUG - Recv: > do_blocking_move_to_xy(20.00, -30.00)
2016-08-21 07:34:22,242 - SERIAL - DEBUG - Recv: >>> do_blocking_move_to(20.00, -30.00, 15.00)
2016-08-21 07:34:23,531 - SERIAL - DEBUG - Recv: > current_position=(20.00, -30.00, 15.00) : set_probe_deployed

[bgort]

Odd, in my version -- a few commits behind, it looks like -- I have

        float yBase = front_probe_bed_position + yGridSpacing * yCount,
              yProbe = floor(yProbe + (yProbe < 0 ? 0 : 0.5));

Where yProbe is perhaps incorrectly referenced prior to being initialized, and perhaps incorrectly referenced period? The xProbe float also has the same problem in what I'm using.

xProbe and yProbe have been fixed as of 28d1e5a. I suspect that will take care of the axes flying off into never-never land, and explains the inconsistent behavior (the uninitialized, effectively random, variable).

I'll do a pull to get to current and then test again.

Also, I'll gladly add the code to produce additional debug info, and send the log, if you think that's still relevant?

[Roxy-3D]

Let's see what the latest version of RCBugFix does for you. But I'm still concerned about this: https://github.com/MarlinFirmware/Marlin/issues/4577#issuecomment-241277830

Oh wait! That thing I'm concerned about is the first deploy of the grid probe. That is consistent with what you pointed out. The latest RCBugFix probably will clean that up. Let's load that and see what happens!

[bgort]

I'll do a pull to get to current and then test again. Also, I'll gladly add the code to produce additional debug info, and send the log, if you think that's still relevant?

The latest RCBugFix resolved the probing-in-the-same-place issue, and there's been no attempt, as of yet (6-8 trials with G29), to set a beyond-endstop position on either X or Y.

Now I'm just seeing the original problem - that Z0 is higher after G29 than after G28. Higher by 0.8mm, currently, with a M851 Z offset of -2.4. That is, Z0 is on the glass after G28 with an offset of -2.4, and 0.8mm above the glass after G29.

Setting a M851 Z offset of -3.2, and then doing G28 -> G29, I get nozzle on glass at Z0 after the G29.

I'll log everything again momentarily, now that things are seemingly back to 'normal'(-ish) ...

[bgort]

Let's see what the latest version of RCBugFix does for you. But I'm still concerned about this: #4577 (comment)

Yeah, that's definitely concerning. I'd think it should never try to set a position beyond a min or max.

I need to spend some time getting up to speed on how everything works so I can meaningfully contribute. Mostly just flopping around right now.

[Roxy-3D]

Well... Another annotated log will give us good information about the Z-Offset issue you are seeing. If you annotate another one for us with it probing in the right places... That will be a very valuable contribution!

[bgort]

This log from a bit ago shows the problem, albeit with an IR sensor instead of the BLTouch:
https://github.com/MarlinFirmware/Marlin/issues/4577#issuecomment-239051052

I'll do another with the BLTouch momentarily.

[bgort]

Here's a just-now annotated debug log using the BLTouch:
serial-08.21.16-b-crlf.txt

[Roxy-3D]

I haven't looked at the log in great detail. But at the very end of it, it says:

2016-08-21 17:10:43,772 - SERIAL - DEBUG - Recv: <<< gcode_G29
2016-08-21 17:10:43,777 - SERIAL - DEBUG - Recv: X:240.07 Y:241.00 Z:13.73 E:0.00 Count X: 24000 Y:24100 Z:11914
2016-08-21 17:10:43,779 - SERIAL - DEBUG - Recv: ok

*** FINE; ALL PROBING AS EXPECTED ***

2016-08-21 17:10:43,782 - SERIAL - DEBUG - Send: G1 X145 Y131
2016-08-21 17:10:43,789 - SERIAL - DEBUG - Recv: echo:G1 X145 Y131
2016-08-21 17:10:43,792 - SERIAL - DEBUG - Recv: ok

*** RECENTER ***

2016-08-21 17:10:43,794 - SERIAL - DEBUG - Send: G1 Z0
2016-08-21 17:10:43,801 - SERIAL - DEBUG - Recv: echo:G1 Z0
2016-08-21 17:10:43,802 - SERIAL - DEBUG - Recv: ok

*** NOZZLE ON GLASS @ Z0 ***

At the very end, when you did the G1 Z0.000 did the nozzle end up just barely touching the glass? If so, isn't this what we want?

[bgort]

Yes, it is, but the problem is that it's necessary to use different M851 Z offsets to get nozzle-on-glass after G28 and G29.

To get nozzle-on-glass after G28, I have to use an offset of -2.4, whereas to get nozzle-on-glass after G29, the Z offset must be -3.2.

The log reflects that in that there's two sections - one series of G28->G29 using an offset of -2.4 (nozzle floating 0.8mm above glass after G29), and one using -3.2 (nozzle on glass after G29).

[Roxy-3D]

OK... I'll review the logs with that information in mind. Do you know of anything that is .8 mm big in your system? (I'm just looking for a clue why the difference is .8mm)

[bgort]

No, I don't believe anything in particular is 0.8mm - at least not that I know of.

Also, I can add that the difference - prior to pulling the latest - was -0.45, not -0.8. I was using -2.4 and -2.85 instead of -2.4 and -3.2. After pulling the latest I had to re-figure the post-G29 offset.

Since the -2.4 has remained constant, I'd think it has to be in software somewhere. If anything had changed on the printer, the -2.4 would have had to change, also, I believe.

[Roxy-3D]

OK... I'll see what I can find. (It will probably be later today before I can get my head clear enough to dive into this.)

[bgort]

Thank you. No rush. The post-G29 offset works fine once it's found; it's just that there's a need for it is suggestive of a bug/problem somewhere.

[Roxy-3D]

Thank you. No rush. The post-G29 offset works fine once it's found; it's just that there's a need for it is suggestive of a bug/problem somewhere.

Yes. Agreed.

However, it is interesting to note that ever since the G29 command arrived on the scene, we have been seeing these issues. Part of the problem was G29 used Run_Z_Probe to measure things and G28 used Probe_Pt(). (I could have this backwards or not quite correct). Anyway, they used different methods to find the bed. That is no longer the case. So that isn't what is happening here.

[thinkyhead]

Here's the thing. After G29 has completed a matrix is generated to use for bed-leveling correction. Then the matrix is used to correct the current XYZ position. However, there is a flaw in this section of the code. I know the precise location of the flaw, but we haven't quite figured out how to fix it.

In the interest of gathering more information and trying alternative approaches, I created a branch a few days ago. The fix I propose will work for any probe that doesn't change its XY position after the probing procedure. So, for example, it won't work with an Allen Key or Docking Sled probe because their last action is to move off to the side. But if your probe is one of the ordinary kinds then it should prove more accurate.

Download this branch and give it a try:

https://github.com/thinkyhead/Marlin/tree/rc_final_z_correction

[Blue-Marlin]

@thinkyhead

Allen Key or Docking Sled probe because their last action is to move off to the side.

No. With the new probe code all kinds of probes do return to the place where the deploy/stow begun.

[Roxy-3D]

Here's the thing. After G29 has completed a matrix is generated to use for bed-leveling correction. Then the matrix is used to correct the current XYZ position. However, there is a flaw in this section of the code. I know the precise location of the flaw, but we haven't quite figured out how to fix it.

@thinkyhead
Can you tell us what you are thinking and show a snippet of code to illustrate where the precise location of the flaw is? I'm not entirely convinced qr_solve() is generating a 'unique' solution. It kind of looks to me like it is picking a very good solution, but not the best one.

[bgort]

In the interest of gathering more information and trying alternative approaches, I created a branch a few days ago. The fix I propose will work for any probe that doesn't change its XY position after the probing procedure. So, for example, it won't work with an Allen Key or Docking Sled probe because their last action is to move off to the side. But if your probe is one of the ordinary kinds then it should prove more accurate. Download this branch and give it a try: https://github.com/thinkyhead/Marlin/tree/rc_final_z_correction

Will give it a shot at some point today, hopefully. Thanks.

[bgort]

Will give it a shot at some point today, hopefully. Thanks.

@thinkyhead Yes, whatever you changed in rc_final_z_correction fixed it.

[Roxy-3D]

Yes, whatever you changed in rc_final_z_correction fixed it.

What changed? I'm guessing I should cross the change over to the devel_ubl branch.

[bgort]

Looks like just this?:
https://github.com/thinkyhead/Marlin/commit/b24fb2834d044266bb15f95a8c7d79be9fa1bc27

[thinkyhead]

whatever you changed in rc_final_z_correction fixed it

@bgort I'm gratified to hear that the rc_final_z_correction branch worked. Unfortunately we're most likely _not_ going to be able to use it, because it is highly idealized for a certain kind of setup. I looked more deeply into bed leveling issues for rc_fix_leveling_maths and that is probably going to end up being merged if it passes muster. So you should try it and let us know whether it also produces better results.

[bgort]

@thinkyhead Will give the other branch a try sometime midweek, and will let you know. Thanks.

[bgort]

@thinkyhead Finally able to test rc_fix_leveling_maths. Sorry for the delay.

It seems to work perfectly - perhaps even a little bit better than rc_final_z_correction (there was a tiny bit of deviation [20-30um or something] that I had written off to a probe or axis repeatability issue, which I'm not seeing with rc_fix_leveling_maths).

[thinkyhead]

Thanks for the feedback. I've been looking a lot at the leveling code lately and there are some definite improvements still to be made. But I think the approach in rc_fix_leveling_maths is a definite step in the right direction. If I can get a few more testers to confirm it, then I will merge it early this week. With that we'll finally be at a point where RC8 can be released.

[bgort]

Great. Let me know if you need anything else tested. Happy to help.