I could use some help
-
@mac said in I could use some help:
Hey mac,
Nice but G1 H2 is not the same as G1 H1.
To make use of the endstop for homing, you have to use G1 H1.
Frederick
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt yep one down, two to go.
-
@fcwilt of course there has to be something weird going on.
I changed the H2 to H1. When I hit SEND, the board went back a bit, then stopped. So I sent the instructions 3 more times to get the bed all the way back to the end stop.
So H2 makes the bed home as is expected. And H1 does something unexpected.
-
@fcwilt the printer's back to its old tricks. It's pounding on the front of the bed when I tell it to home. I'm just trying to get it to do what it did, and it's telling me something I won't write. I'm thinking the same thing towards it.
-
@fcwilt I'm having a hard time believing this, but it's true.
I sent G91
Then I wrote G1 H2 Y-220 F2600 (not 3600) (that was just a typo, but I'm not going to change it).
Now the jog menu to the right of Home Y is available. Before, it wasn't. (Like I had to Home Y to get the jog menu to function).
Now, when I use the jog menu to send the bed forwards 50mm, it goes all the way to the front of the printer.
Then, when I send the code again (G1 H2 Y-220 F2600) it goes all the way back to the end stop.
And I see that in the Status box, Y is showing as -220.0It seems to me that DWC is making shite up, Frederick. What say you?
-
@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.
-
@fcwilt I’m done for today. Did something to my ear that’s killing me.
-
@mac said in I could use some help:
@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
-
@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
-
@fcwilt I’ve been looking at the M208 lines in my config.g.
M208 X0 Y0 Z0 S1 M208 X220 Y220 Z240 S0S1 means Forwards? S0 means backwards.
Why do those M208 lines end with S commands?
-
@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 S0I 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
-
@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 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
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@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
-
@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
Printers: A FT-5 with the 713 upgrade bits, a custom MarkForged style, a small Utilmaker style, a small CoreXY from kit and a E3D MS/TC setup. Various hotends. Using Duets (2 and 3) running 3.4.6
-
@fcwilt
Well, you've certainly found a good one!
-
@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
-
@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
-
@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?
-
@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.
