I could use some help

fcwilt

@fcwilt I understood what you said, but when I used that code it did not work. Instead, the bed moved towards the end stop, stopped, and I had to push the button again and again to make it get there. But it never did because the firmware said you’re at 0 where you are, and that’s that.

I don't know what to say.

You did a series of short G1 H1 moves and they behaved as they should.

But a long G1 H1 move did not.

That suggests a stepper configuration issue.

Frederick

fcwilt

@mac

Here is the meaning of the various H parameter options for a G1 move:

H0 no special action (default)

H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).

H2 Individual motor mode. X refers to the X motor, Y refers to the Y motor, and so on. Normally used with relative motor coordinates (see G91).

H3 terminate the move when the endstop switch is triggered and set the axis limit to the current position, overriding the value that was set by M208.

H4 terminate the move when the endstop switch is triggered and update the current position (supported in RRF 3.2-b4 or newer)

Notice that H1, H3 and H4 do respond to the triggering of the endstop switch but H2 does not.

H1 is used for homing.

H2 is often used to move an un-homed axis in the homing code of another axis.

I've never had an occasion to use H3 or H4.

Frederick

A Former User

@fcwilt I’ve been looking at the M208 lines in my config.g.


M208 X0 Y0 Z0 S1
M208 X220 Y220 Z240 S0

S1 means Forwards? S0 means backwards.

Why do those M208 lines end with S commands?

fcwilt

@mac said in I could use some help:

@fcwilt I’ve been looking at the M208 lines in my config.g
M208 X0 Y0 Z0 S1
M208 X220 Y220 Z240 S0

I know S1 is different than S0. I’ll have to review above before I can finish this post.

Are you feeling better?

And if you recall I mentioned my preferred short form:

M208 Xmin:max Ymin:max Zmin:max

where there is no S0/S1 to remember - which I never could.

But for the old, two line way, S1 is min, S0 is max.

So your two lines are setting X, Y and Z min as 0, X and Y max as 220 and Z max as 240.

Frederick

Fredric

A Former User

@fcwilt not really I kind of punctured my ear. A bit wobbly.

I read your bit about the H commands. I wish H1 would do what it’s supposed to on my machine.

I’ve been looking at the gcode info on the duet site.

Maybe the H-command issues are related to the X or the Z somehow. Maybe working on X will provide some insight. Do you have any Job left in you to put up with my stupidity?

Mac

fcwilt

@mac said in I could use some help:

@fcwilt not really I kind of punctured my ear. A bit wobbly.

I read your bit about the H commands. I wish H1 would do what it’s supposed to on my machine.

I’ve been looking at the gcode info on the duet site.

Maybe the H-command issues are related to the X or the Z somehow. Maybe working on X will provide some insight. Do you have any Job left in you to put up with my stupidity?

Mac

Mac, I am more than happy to help you in anyway I can. At this point I am determined to understand why code that works fine for me on all my printers is not working as it should for you.

I have a theory about why the Y homing code is not working but it just a theory at this point. It will take a bit of testing to determine if my theory is correct.

You posted that you were having success doing G1 H1 Y-10 commands and it moved 10mm at a time and the DWC display for the position of Y was consistent with those moves.

Is that correct?

If it is correct I would like you to do another test, starting with the bed somewhere in the middle of it's travel, so it has a ways to go before it reaches the endstop switch.

Then from the DWC console:

issue a M119 command to check the state of the endstops
issue a G91 command to set relative movement mode which is necessary for homing
issue as many G1 H1 Y-10 F3600 moves as it takes to get the bed to the position where the endstop switch is triggered
check the DWC Y position display after each move to see if anything odd is happening
when you finally reach the position were the endstop switch is triggered issue another M119 to again check the state of the endstops

What I am trying to check is if the problem only occurs when you try to do long Y moves but short Y moves, like 10mm, work fine.

Thanks much. Wait until you feel better. Ear pain can really make it tough to focus and want to do anything.

Frederick

A Former User

@fcwilt the family has turned in. I’ll do these new tests first thing in the morning.

I absolutely want to finish this project with you.

Are you okay with the 0, 1 and 2 motor assignments? Please check those lines in the latest config.g. The ports are assigned as: “!^io5_in”, “!^io6_in”, and “!^io2_in” based on a discussion I had with @alankilian.

Mac

fcwilt

@mac said in I could use some help:

@fcwilt the family has turned in. I’ll do these new tests first thing in the morning.

I absolutely want to finish this project with you.

Are you okay with the 0, 1 and 2 motor assignments? Please check those lines in the latest config.g. The ports are assigned as: “!^io5_in”, “!^io6_in”, and “!^io2_in” based on a discussion I had with @alankilian.

Mac

You mean the M569 commands for steppers? While I can verify the syntax of the commands, the only way to verify if they have the correct values is through testing. For instance if the M569 command for the X axis says driver 0 is used but the X axis stepper is connected, by mistake, to driver 5 that will only be found is during testing or by visually verifying connections to the board.

As to the "ports" I assume you mean the M574 commands for the endstops?

Again I can verify the syntax but I cannot verify if the values are correct without testing. For example the presence of the ! character says that an NO switch is being used. But is that true? That can only be determined by viewing that actual switch and how it is wired and/or by testing.

I can say that the ^ character is incorrect. That is used to enable pull-up resistors for inputs on Duet 2 hardware. But Duet 3 hardware has fixed pull-up resistors on most inputs, including those you listed in your post. The ^ character doesn't cause a problem because it has no effect. But you might as well remove it.

Hope you feel better tomorrow. I have a number of chores to help the wife with but I will check for messages when I can.

Frederick

Nightowl

@fcwilt
Well, you've certainly found a good one!

A Former User

@fcwilt thank you for considering my concern. I’ll remove the ^ after I get up.

Here is what woke me up this morning.

Hopefully the GTS belt is not adding to our problems.

But these belts around my neck in my bad dream were my brain chewing on DWC’s statement that 452mm’s is 350mm’s. Then I realized that now, DWC thinks that the distance from the rear Y-endstop to the front of the printer (and possibly a few mm’s more) is 220mm’s. If DWC thought that 226mm’s was 220mm’s X 2, that would be 452mm’s? We have the steps set at 100, correct? If we were to change that number to 50, or 200, what would be the impact?

Also, by the labeling on those 2 belts, I wanted to imply that the X-axis still has the original belt from the XVico on it.

Maybe I should change that to a GTS belt?

And the Z-screw, it looks like what was on my Anet. Do we have the steps for Z correct?

Frankenstein’s Cinderella is giving me nightmares.

Mac

fcwilt

@mac said in I could use some help:

@fcwilt thank you for considering my concern. I’ll remove the ^ after I get up.

Here is what woke me up this morning.

Hopefully the GTS belt is not adding to our problems.

But these belts around my neck in my bad dream were my brain chewing on DWC’s statement that 452mm’s is 350mm’s. Then I realized that now, DWC thinks that the distance from the rear Y-endstop to the front of the printer (and possibly a few mm’s more) is 220mm’s. If DWC thought that 226mm’s was 220mm’s X 2, that would be 452mm’s? We have the steps set at 100, correct? If we were to change that number to 50, or 200, what would be the impact?

Also, by the labeling on those 2 belts, I wanted to imply that the X-axis still has the original belt from the XVico on it.

Maybe I should change that to a GTS belt?

And the Z-screw, it looks like what was on my Anet. Do we have the steps for Z correct?

Frankenstein’s Cinderella is giving me nightmares.

Mac

Hi mac,

Hope you are feeling better.

Don't worry about the belts for now. It is very unlikely they are part of the problem.

The Z axis in on my list of things to check.

Right now I want to get Y working, then get X working and then Z working.

Frederick

A Former User

@fcwilt It's almost 7 AM, but I can't start working until my wife gets up around 8. Is 8:30 a good time for you?

A Former User

@fcwilt here are the results: I discovered that my wireless mouse and the printer aren't really communicating. Sometimes, the bed moves the whole 10mm's, sometimes it turns half or less of that. So it isn't click, pulley turns, bed moves 10mm's, it's more like click, nothing happens, click, the pulley turns 3 mm's, click, the pulley doesn't do anything, click, it turns 10mm's.

So I turned off the wireless mouse, and plugged a USB mouse into my keyboard.

I'm going to do the test again, from the beginning.

A Former User

@fcwilt Test no. 2, same results with a wired mouse. I'm clicking the same way every time, and that's not working every time. Maybe the wifi is wonky?

Status isn't reporting anything.

A Former User

@fcwilt so here's some bad news: I'm experimenting with the code (G1 H1 Y-XX FXXXX). I used 2600 for the F, because that "speed?" worked last night? No change, really. The signal's going to the printer are having a hard time getting there, or, the printer's having a hard time understanding and acting on them?

So then I changed the code to: G1 H2 Y-20 F2600

The bed slides towards the rear like it's on ice.

And here's some more bad news: Status is displaying the position of the bed. Y is at -160 now.

The end-stop fully compressed.

Mac

A Former User

@fcwilt more bad news: I went to the Dashboard. There, Display is showing me the position of the bed. (So maybe, when you're in the CONSOLE, that information isn't available?).

Anyways, the bed is at 87 right now. That's the 18" mark (the 457mm mark).

The jog selections for Home Y are available.

Mac

A Former User

@fcwilt I'm using G1 H2 Y-20 F2600 to send the bed back to the Y-endstop. The transmission rate is working very well. The foot of the bed (underneath it, on the mounting hardware for the bed), is depressing the endstop. Status is reporting -220.0.

The Home Y jog buttons are active. However, a single click on Y+50 sends the bed all the way to Y= 0.0, which is at the front of the bed.

Mac

fcwilt

@mac said in I could use some help:

@fcwilt more bad news: I went to the Dashboard. There, Display is showing me the position of the bed. (So maybe, when you're in the CONSOLE, that information isn't available?).

Anyways, the bed is at 87 right now. That's the 18" mark (the 457mm mark).

The jog selections for Home Y are available.

Mac

Hey Mac,

As to what the DWC reports: It means nothing until the axis is homed. Yes the display changes as you issue Y movement commands but the DWC has no reference as to where the bed was before the move.

Do you have a part number for the X, Y and Z steppers? It may be printed somewhere on the stepper itself.

In your config.g file: The M906 commands which set the currents for the steppers: Where did you get those values?

Thanks.

Frederick

A Former User

@fcwilt I think what we've learned from this experiment is: G1 H1 Y-20 F2600 doesn't communicate with the board / printer very well, and G1 H2 Y-20 F2600 seems to have no problem communicating with the board / printer?

fcwilt

@mac said in I could use some help:

@fcwilt I think what we've learned from this experiment is: G1 H1 Y-20 F2600 doesn't communicate with the board / printer very well, and G1 H2 Y-20 F2600 seems to have no problem communicating with the board / printer?

Hi Mac,

The particular command issued would not in anyway affect communication with the board.

The configuration of the board may be preventing the commands from being performed correctly.

Did you do the test I asked for? The one using a series of G1 H1 Y-10 commands to move the bed until it reach the endstop.

Do you remember that list of steps I posted?

Thanks.

Frederick