Posts made by fcwilt

@amimafe

Thanks for the feedback.

Frederick

@amimafe said in Layer change detection job.layer:

Yes, that's the other option I had thought of, but I preferred to do it by daemon.g and if a third party manages the machine, everything is integrated with the firmware.

Thank you.

Understood - but the slicer knows what is going on. How would the firmware identify a layer change?

Frederick

@amimafe

All of the slicers I have used have a place to put user code to be called on layer changes.

This is a screen shot from Prusa showing where the code can go:

Frederick

@BDPrinters said in Calibration factors do not equal number of leadscrews:

Yes, that actually seemed to be the problem for the calibration factors not equaling the number of leadscrews. Things seem to be working fine now.

That seems odd since the docs for G30 without a P parameter state the having an S0 parameter is the same as not having the S0 parameter

A few things come to mind:

• the code for G30 S0 has a bug and it doesn't work like the documentation says it should
• the documentation for G30 S30 is wrong
• you changed something else at the same time which actually fixed the problem

I haven't a clue what is going on.

Frederick

@claustro

How many "adjusters" do you have - 3 or 4?

Frederick

@BDPrinters

I think you M671 is wrong.

I think the X50.8 should be the in the 2nd position based on the three G30s but perhaps they are out of order.

Frederick

@BDPrinters

The last G30 P2 has F550 instead of Y550

Frederick

@DieterSw said in 6HC inductive 4 wire endstop wiring:

@Mr-Crispin Why do you think that? I connected BN to 5V_EXT, BU to GND. And BK to iO.in. I might switch black/white to use the NO closed contact but the rest seems correct I think?

Aside from the issue of the signal level being invalid you have it wired correctly in regards to what wires are going where.

I don't know that switching to the NO connection would change the signal level.

If memory serves me I went with NPN devices (rather the PNP) just for this signal level problem. I also remember during testing creating a voltage divider using two resistors to get a suitable signal level.

Frederick

@airscapes said in During Bed Probe G29:

Can you explain the P25 to P500?

When triggered my BLTouch probes read 1000. When not triggered they read 0. The setting of P500 is midway between 0 and 1000.

It has always worked for me.

Frederick

@airscapes said in During Bed Probe G29:

This probe has been in place for a year I have made other maps and tend to reuse them. This has happened with the failure before complete one other time.

M558 P9 C"^zprobe.in" H3 F100 T6000 A3 R1.25 S0.01 B0.
G31 X0 Y-21 Z1.57 P25 ;

In M558:

Change the S0.01 to S0.03

Change the R1.25 to R0

In G31:

Change the P25 to P500

Let us know if those changes help.

Frederick

@airscapes

Typically the reading of 1000 indicates the Z probe is triggered, while a reading of 0 indicates the probe is NOT triggered.

We would need to see the two Z probe configuration commands (M558 and G31) in regards to the inconsistent readings - it may just be a setting issue.

Frederick

@nico-rast

With the G10 Z parameter of -3.667 that is saying the BLTouch triggers 3.667 BELOW the surface of the bed which is very unlikely.

Frederick

@DieterSw

I would say that 3.2 is too high. Possibly a resistor from the input to ground could reduce that voltage to a suitable level.

Do they have a NPN version?

Frederick

@Yao said in Z position changes after X or Y home - RRF 3.4.0:

we sometimes print on a sloped surface. if the position away from 0 is lower and homing is not compensated the head would crash into the printsurface.

I have no idea what you mean. How can you print on a sloped surface?

we always lift the head about 10 mm before homing so never had an issue. But it could give an issue if the slope is over 10mm.

All of my printers have Z endstops, so Z is homed first. That allows positioning Z at a safe distance from the bed before homing X and Y.

Frederick

@gnydick said in mesh compensation too aggressive?:

I think you're asking me if I home my Z axis at the same place every time. Yes.

Yes and no.

Since I don't home Z using the Z probe I always speak of setting the Z=0 Datum rather than homing Z.

Frederick

@Yao

There is no reason to have mesh compensation active except when actually printing.

I don't have mesh compensation active when homing so I cannot say if there is a problem when doing so. I would have to test it.

Frederick

@gnydick said in mesh compensation too aggressive?:

I'm not following what you mean about the z=0.

When you use your Z probe by executing a G30 command at a fixed XY location (always the same) you are setting the Z=0 Datum.

How are you confirming it's following it exactly, considering the source code and documentation show the first layer is subject to taper, making it impossible to follow the map exactly.

I created a heightmap using a text editor that had deviations ranging from 0 at the left edge to 100mm at the center then back to 0 at the right edge. With these large values it was easy to move the nozzle to various X positions and measure the Z position of the nozzle.

In any case the amount of taper adjustment applied to the first layer is very little.

Frederick

@gnydick said in mesh compensation too aggressive?:

@fcwilt yes, it smooshes too much in some areas, and I have a great bed.

But the point is, it is literally impossible to get a perfect first layer if it's not following the contour.

I am using 3.4.6 on five different printers and mesh comp works fine. I have verified that it follows the height map exactly.

Perhaps the problem lies in 3.5.x?

Do you set the Z=0 Datum at the same fixed XY position when creating the height map and loading the height map?

Frederick

@gnydick

I think you will find that for a useful taper setting that the effect on the first layer is negligible.

Have you been having problems?

Frederick

@BoA said in automatic start a marco when the printer is on?:

@fcwilt Wouldn't it be easier to just use start.g and stop.g files that are called automatically on print start and stop instead of creating separe ones and putting a call in slicer generated g-code?

It has to do when they are called. The file "start.g" is called before any slicer code executes which can result in the slicer code changing settings that were set in the "start.g" file.

At least with the slicers I have used I can insure that my files are called and take precedence over anything the slicer may have already done.

Frederick