G29 on CoreXY does not move correctly

fcwilt

Just FYI.

G32 executes bed.g - which is intended to do bed leveling, not create the heightmap needed for mesh bed compensation.

What you have done will, of course, work but it is using bed.g in a somewhat unusual way.

Now as to you Core XY settings.

I would like you to do this from the DWC console:

execute M564 H0 which will allow moving axes that are not yet homed
jog X to the near the center of the bed
jog Y to the near the center of the bed
execute G92 X160 Y135 which will set the X and Y logical positions to appx halfway between axis min and max
execute G90 which will set absolute move mode
execute G1 X210 Y185 just to test a move command
execute G1 X110 Y85 just to test another move command

Does the jogging move as expected?

Do the G1 commands move as expected?

Frederick

Phaedrux

Can you make a video of you homing the printer and running a mesh compnesation?

G28 G29

TechButterfly

@fcwilt I ran the commands you said - everything moved as expected, both jogging and using G1 commands. X+ was to the right. Y+ was toward the back.

What should I do next?

As far as G32, bed.g, and G29, whatever I have is either the default or perhaps came along with something I copied from somewhere. Please feel free to tell me a more acceptable way to accomplish things like bed leveling or mesh compensation. There's definitely plenty I don't know.

Phaedrux

Your homing files and config and mesh.g look alright to me. I don't see anything that would cause weird movement behaviour anyway.

TechButterfly

@phaedrux To verify what I posted before, after doing the tests @fcwilt requested, I homed Y and tested the movement - everything was still fine. I then homed X and once again, the movement is now wrong. The Y motor no longer turns - it is locked in place, so it's not just dead, the controller thinks it's not supposed to turn. I don't know what to do next.

fcwilt

@techbutterfly said in G29 on CoreXY does not move correctly:

I ran the commands you said - everything moved as expected, both jogging and using G1 commands. X+ was to the right. Y+ was toward the back.

Just to be sure, did both of the G1 commands move on the diagonal and ended up at the correct XY position?

I know this is a pain but maybe if you made a video showing what happened during the tests I suggested we would see something that would give us a clue.

Right now I am somewhat baffled.

Thanks.

Frederick

fcwilt

@techbutterfly

One other thing - could you edit the homey.g file to add a G1 move?

G90     ; existing G90 at end of file
G1 Y135 ; move to middle of Y axis

I would like to be sure that the Y axis can still move correctly after homing.

Frederick

TechButterfly

@fcwilt Yes when I ran the G1 commands, the head moved diagonally to the assigned positions. I ran them back and forth a couple of times. I also ran just the X110 to X210 part by itself several times and observed the head going left and right between those spots, and the Y85 to Y185 part by itself and watched the head go forward and back between those spots.

Then I homed Y and jogged the head around a bit. And then I homed X and now the Y motor doesn't turn, just the X motor, regardless of the direction requested, so the head moves diagonally. The panel due says the motor is moving as requested, but the head is not moving that way.

Let me see if I can put together a video.

fcwilt

@techbutterfly said in G29 on CoreXY does not move correctly:

@fcwilt Yes when I ran the G1 commands, the head moved diagonally to the assigned positions. I ran them back and forth a couple of times. I also ran just the X110 to X210 part by itself several times and observed the head going left and right between those spots, and the Y85 to Y185 part by itself and watched the head go forward and back between those spots.

Then I homed Y and jogged the head around a bit. And then I homed X and now the Y motor doesn't turn, just the X motor, regardless of the direction requested, so the head moves diagonally. The panel due says the motor is moving as requested, but the head is not moving that way.

Let me see if I can put together a video.

That is just so strange.

I've look at the homex.g file and I don't see anything that would cause the behavior you are seeing.

We must be overlooking something.

Hang in there. We will get it sorted. I've built 9 different printers over time and I got them all to work despite the odd problem know and then.

Frederick

TechButterfly

@fcwilt Thanks - I appreciate your taking the time. I'm going to see if I can make a video.

TechButterfly

@phaedrux I just saw this request - I will try this when I make the video. I know it will end in a crash, because the movement will be screwed up, but I'll give it a try at the end.

fcwilt

@techbutterfly

I think I see the problem.

In the homex.g file you have a M92 X0 instead of G92 X0.

I hope my example didn't have that mistake. That would be very embarrassing. Very.

Frederick

TechButterfly

@fcwilt Oh I'm sure it was my mistake. Let me fix that and try again...

TechButterfly

@fcwilt That was it! Thanks so much! I need to be more mindful of my M's and G's I guess!

So while we're here - can you tell me the difference between the bed.g and mesh.g, and how I should use them correctly?

TechButterfly

@fcwilt I tried to run G29, but there's something wrong with my heater settings - I think I'm just addressing the tools incorrectly. It looks to me like I'm supposed to set the active and standby temps for each tool with the M568 command, and then set those tools to active with the A2 attribute. And if I want them to wait before proceeding, I have to put an M116 command. That is essentially what I'm trying to do with this section of my mesh.g but it's not working right. Can you tell me what's wrong with these commands?

;set temps
M568 P0 S60 R60                   ;set bed temp
M568 P1 S200 R160                 ;set extruder temps
M568 P0 A2                        ;set bed temp to active
M568 P1 A2                        ;set extruder to active
M116 H0 S5                        ;wait for bed to reach temp +-5
M116 H1 S10                       ;wait for extruder to reach temp +-10

TechButterfly

Hmm. It looks like I'm supposed to just use a regular old M140 for the bed temp part of it.

fcwilt

@techbutterfly said in G29 on CoreXY does not move correctly:

Hmm. It looks like I'm supposed to just use a regular old M140 for the bed temp part of it.

Correct. M568 is only for tools.

Frederick

fcwilt

@techbutterfly said in G29 on CoreXY does not move correctly:

So while we're here - can you tell me the difference between the bed.g and mesh.g, and how I should use them correctly?

G32 is associated with Bed Leveling (Auto or Manual). G32 runs bed.g which is intended to contain all the commands needed to level the bed.

G29 is associated with Mesh Bed Compensation. In current firmware G29 runs mesh.g which is intended to contain all the commands needed to create the heightmap which is required for using Mesh Bed Compensation.

They are very different things.

Bed Leveling, as the name implies, is for leveling the bed. This is done before printing. In my case it is part of homing Z.

Mesh Bed Compensation is a feature which is used to try and compensate for bed irregularities during printing.

If you printer is well made and stable you can usually create the heightmap once and use it for all subsequent prints. I have a macro which I run manually to create the heightmap. In my "print start" I load the pre-existing heightmap.

Once a month or so I re-create the heightmap just to be sure it reflects the current state of the bed.

Generally you create the heightmap with the hotend and bed at printing temps. Some folks create multiple heightmaps for different bed temps.

Frederick

TechButterfly

@fcwilt Okay, I think I get it. Bed leveling is physically leveling or tramming the bed - like a voron 2.4 would do with its 4 z motors - or I guess if doing it manually, it might have commands that move the head to different points for adjustment. Mesh compensation moves z up and down as printing happens.

I do not have a self leveling bed, so I want to use G29. I ran G29 S0 already so I should have a heightmap.csv in my sys folder. And I need to add G29 S1 P"heightmap.g" in the code that runs before the print starts. Is that correct? Do I need to create a print start file or is there already a way to include this code?

fcwilt

@techbutterfly said in G29 on CoreXY does not move correctly:

@fcwilt Okay, I think I get it. Bed leveling is physically leveling or tramming the bed - like a voron 2.4 would do with its 4 z motors - or I guess if doing it manually, it might have commands that move the head to different points for adjustment. Mesh compensation moves z up and down as printing happens.

I think you've got it. You can certainly use both. Any printer with a Z probe can use Mesh Bed Compensation. Most any printer with multiple Z steppers or bed leveling thumb screws can use Bed Leveling. I use both as all of my printers have Z probes and all have some way to level the bed.

I do not have a self leveling bed, so I want to use G29. I ran G29 S0 already so I should have a heightmap.csv in my sys folder. And I need to add G29 S1 P"heightmap.g" in the code that runs before the print starts. Is that correct?

If G29 S0 worked you should have seen the probe moving from point to point of the grid you specified and not report any errors.

You should have a heightmap.csv file in the SYS folder.

G29 S1 will load the existing heightmap file if it is named heightmap.csv

You can view the height map with the built-in Height Map viewer.

Do I need to create a print start file or is there already a way to include this code?

Generally you need batch of commands to start the print and another batch of commands to execute when printing is complete.

Slicers have a place for you to enter these two batches of code - and some folks do that.

I don't.

What I do is enter into those two places in the slicer just the commands M98 P"print_begin.g" and M98 P"print_end.g"

You can use any names you want but it makes sense to have the names reflect what the files do.

In those files I put the commands I want to execute when printing starts and when printing is done.

The slicer will add a few commands on its own at the beginning of the file and at the end of the actual file you print from. If you configure the slicer correctly these commands will not interfere with the commands that you put into your own two files.

The reason I do it this way is that I use different slicers from time to time but they all can be configured to run my two files. Thus I don't have to maintain multiple batches of code in the various slicers.

Also my approach relies on using the DWC Filament handling feature.

It's moderately advanced stuff and you may not want to use it. But I will be glad to do my best to explain it to you if desired.

Frederick