G29 on CoreXY does not move correctly

[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

[TechButterfly]

@fcwilt Thanks! Makes sense the way you do it with the start and end files. I have mostly used prusaslicer for the last several years, but I do have a simplify3d license and also have Cura installed, so making the printer as slicer-agnostic as possible makes sense.

I am not afraid of more advanced stuff - could you explain more about the filament handling?

[fcwilt]

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

@fcwilt Thanks! Makes sense the way you do it with the start and end files. I have mostly used prusaslicer for the last several years, but I do have a simplify3d license and also have Cura installed, so making the printer as slicer-agnostic as possible makes sense.

I am not afraid of more advanced stuff - could you explain more about the filament handling?

The DWC implements a basic filament handling system for dealing with different types of filaments. Each filament you add to the system creates three files specific to that filament:

• load.g
• unload.g
• config.g

Here is an entry on my printer for Amazon Gray PLA. I make entries for different colors because I have found that sometimes they needed different settings.

Here is an example of one of the filament specific config.g files:

M221 S100 D0                       ; set extrusion multiplier
M568 P0 S190 R60 A2                ; set extruder temps
M140 S60 30                        ; set bed temps

set global.print_beg_prime   =  10 ;
set global.print_beg_retract = 0.5 ;
set global.print_end_retract = 0.5 ;

Here is an example of one of the filament specific unload.g files:

M221 D0 S100	; reset extrusion multiplier
M568 P0 A0      ; turn off extruder
M140 S-299      ; turn off bed heater

If you load a filament from the DWC both the filament specific load.g and config.g are executed.

There is a also a command M703 which executes the filament specific config.g file.

In my print start code there is a T0 to select the starting tool and a M703 to invoke the filament specific config.g file.

You with me so far?

Frederick

[TechButterfly]

Yes, I follow. I was also just reading about filaments on the dozuki wiki. Does the selected filament remain loaded even when the machine is rebooted?

[fcwilt]

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

Yes, I follow. I was also just reading about filaments on the dozuki wiki. Does the selected filament remain loaded even when the machine is rebooted?

Physically yes but after a re-boot everything returns to the default states which means no filament is loaded.

Frederick