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
S1 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
-
@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
-
@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.
-
@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.
-
@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
-
@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
-
@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
-
@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
-
@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?
-
@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
-
-