h3n3/endorphin
1
0
Fork 0
Code Issues 8 Pull Requests 1 Packages Projects Releases Wiki Activity

EVA system not quite compatible with Endorphin #3

New Issue
Open
opened 2023-10-23 08:59:00 +02:00 by TristanPeers · 16 comments
TristanPeers commented 2023-10-23 08:59:00 +02:00 (Migrated from github.com)
Copy Link

Hi - the EVA system is not compatible without some modification (sadly the setup you have listed does not work as is).

Firstly many thanks for creating this system!!!

I did stage 1 first a few weeks back and everything was working fine. I changed the kinematics to hybrid_corexy - all good. I printed all the parts for stage 2/3 and EVA on this new setup - no issues.

I've just tried to do stages 2/3 with the EVA carriage this weekend.

Sadly the first problem is that X became reversed. I changed the X dir_pin to fix this, but then when you move Y, X also moves at the same time.

This is exactly the same as this person reports (see my comments): https://www.reddit.com/r/ender5/comments/169eomj/endorphin_y_motion/

The problem is that the belt attachments for the EVA setup with Endorphin are on the back. As you can see from the Reddit thread above the person has decided to update his hybrid_corexy python code to combat this.

I have opted for the simpler approach of moving the belt attachment to the front however the EVA front attachment with the current Endorphin parts cause the belt to rub.

Just thought I'd let you know.

Hi - the EVA system is not compatible without some modification (sadly the setup you have listed does not work as is). Firstly many thanks for creating this system!!! I did stage 1 first a few weeks back and everything was working fine. I changed the kinematics to `hybrid_corexy` - all good. I printed all the parts for stage 2/3 and EVA on this new setup - no issues. I've just tried to do stages 2/3 with the EVA carriage this weekend. Sadly the first problem is that X became reversed. I changed the X `dir_pin` to fix this, but then when you move Y, X also moves at the same time. This is exactly the same as this person reports (see my comments): https://www.reddit.com/r/ender5/comments/169eomj/endorphin_y_motion/ The problem is that the belt attachments for the EVA setup with Endorphin are on the [back](https://github.com/endorphin3d/endorphin/blob/main/docs/stages/stage-3.md?plain=1#L97-L101). As you can see from the Reddit thread above the person has decided to update his `hybrid_corexy` python code to combat this. I have opted for the simpler approach of moving the belt attachment to the front however the EVA front attachment with the current Endorphin parts cause the belt to rub. Just thought I'd let you know.
endorphin3d commented 2023-10-23 20:20:16 +02:00 (Migrated from github.com)
Copy Link

Ok, I think I know the issue you guys are facing because I ran the EVA for a good while without any issues. I think rather than inverting the pin, you need to tell Klipper the endstops are on the other end (200 rather than 0). Here's my Klipper config for X and Y:

[stepper_x]
step_pin: PB9
dir_pin: PC2
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: ^PA5
position_endstop: 220
position_max: 220
homing_speed: 50

[stepper_y]
step_pin: PB7
dir_pin: PB8
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: ^PA6
position_endstop: 200
position_max: 200
homing_speed: 50

If you do this with the belt on the back and this fixes things, I'll update the docs that position_endstop should be 200.

Ok, I think I know the issue you guys are facing because I ran the EVA for a good while without any issues. I think rather than inverting the pin, you need to tell Klipper the endstops are on the other end (200 rather than 0). Here's my Klipper config for X and Y: ```yml [stepper_x] step_pin: PB9 dir_pin: PC2 enable_pin: !PC3 microsteps: 16 rotation_distance: 40 endstop_pin: ^PA5 position_endstop: 220 position_max: 220 homing_speed: 50 [stepper_y] step_pin: PB7 dir_pin: PB8 enable_pin: !PC3 microsteps: 16 rotation_distance: 40 endstop_pin: ^PA6 position_endstop: 200 position_max: 200 homing_speed: 50 ``` If you do this with the belt on the back and this fixes things, I'll update the docs that `position_endstop` should be `200`.
TristanPeers commented 2023-10-23 21:24:46 +02:00 (Migrated from github.com)
Copy Link

Hi - sorry, that's not the issue. My config is pretty much identical to yours and my endstops are also on the end of the axes (position_max):

[stepper_x]
step_pin: PB9
dir_pin: PC2
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: ^PA5
position_endstop: 220
position_max: 220
homing_speed: 50
homing_retract_dist: 0

[stepper_y]
step_pin: PB7
dir_pin: PB8
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: ^PA6
position_endstop: 190
position_max: 190
homing_speed: 50
homing_retract_dist: 0

This config above is what I had running with stage 1.

As soon as I installed the EVA carriage (with the belt attached on the back) and turned the printer on with the config above, X was reversed. It tried to home on the left of the printer. And the X movements were reversed in Fluidd. Pressing right in the console moved the carriage left and vice versa.

As X was now reversed, I changed it to:

[stepper_x]
step_pin: PB9
dir_pin: !PC2
...

And X behaved correctly....however when moving Y, it also moves X at the same time.
Moving the belt attachment to the front has fixed the issue (keeping the config above, not the inverted dir_pin)

Hi - sorry, that's not the issue. My config is pretty much identical to yours and my endstops are also on the end of the axes (position_max): ```ini [stepper_x] step_pin: PB9 dir_pin: PC2 enable_pin: !PC3 microsteps: 16 rotation_distance: 40 endstop_pin: ^PA5 position_endstop: 220 position_max: 220 homing_speed: 50 homing_retract_dist: 0 [stepper_y] step_pin: PB7 dir_pin: PB8 enable_pin: !PC3 microsteps: 16 rotation_distance: 40 endstop_pin: ^PA6 position_endstop: 190 position_max: 190 homing_speed: 50 homing_retract_dist: 0 ``` This config above is what I had running with stage 1. As soon as I installed the EVA carriage (with the belt attached on the back) and turned the printer on with the config above, X was reversed. It tried to home on the left of the printer. And the X movements were reversed in Fluidd. Pressing right in the console moved the carriage left and vice versa. As X was now reversed, I changed it to: ```ini [stepper_x] step_pin: PB9 dir_pin: !PC2 ... ``` And X behaved correctly....however when moving Y, it also moves X at the same time. Moving the belt attachment to the front has fixed the issue (keeping the config above, not the inverted `dir_pin`)
endorphin3d commented 2023-10-23 21:49:29 +02:00 (Migrated from github.com)
Copy Link

Okay I see. As I now am running the Vz printhead with the belts at the front, I don't know exactly what my config looked like when I had the EVA, but I'm curious what would happen if you changed the X settings to the following:

[stepper_x]
step_pin: PB9
dir_pin: PC2
position_endstop: 0
position_max: 220
Okay I see. As I now am running the Vz printhead with the belts at the front, I don't know exactly what my config looked like when I had the EVA, but I'm curious what would happen if you changed the X settings to the following: ```yml [stepper_x] step_pin: PB9 dir_pin: PC2 position_endstop: 0 position_max: 220 ```
TristanPeers commented 2023-10-23 22:04:58 +02:00 (Migrated from github.com)
Copy Link

The endstop position is just telling klipper where the microswitch is located.

As per the discussion I posted here it doesn't really have any effect for this problem.

...and the X motion would still be reversed.

You could recreate the issue yourself by attaching the belts to the back of your Vz instead of the front to mimic the EVA.

The endstop position is just telling klipper where the microswitch is located. As per the discussion I posted [here](https://www.reddit.com/r/ender5/comments/169eomj/comment/k5yaqto/?utm_source=share&utm_medium=web2x&context=3) it doesn't really have any effect for this problem. ...and the X motion would still be reversed. You could recreate the issue yourself by attaching the belts to the back of your Vz instead of the front to mimic the EVA.
endorphin3d commented 2023-10-24 00:45:58 +02:00 (Migrated from github.com)
Copy Link

Ok so I switched my belts to the back and changed my X settings to the ones I recommended and it works just as expected--X moves as I step it, Y moves as I step it, and there's no unnecessary movement from one when I move the other. I'd recommend trying those X settings I mentioned.

Ok so I switched my belts to the back and changed my X settings to the ones I recommended and it works just as expected--X moves as I step it, Y moves as I step it, and there's no unnecessary movement from one when I move the other. I'd recommend trying those X settings I mentioned.
TristanPeers commented 2023-10-24 08:39:02 +02:00 (Migrated from github.com)
Copy Link

Thank you for trying, but I think I'm just going to stick with the front attachments. It's simple, the endstops are in the default location and everything works as intended.

As per the other person, they said:

I changed the position_endstop for X to zero and no[sic] Y moves correctly but that creates a new problem.

I've no idea what the other new problem is they mention but unfortunately I don't have the time to keep switching the belts to experiment. I really need a stable system, this is my only printer and due to the location of the front attachments in EVA I have to fully strip the carriage to access them. That means doing all the wiring, fans, extruder, redoing BLtouch, resetting XYZ offsets and also using different belts.

I'm just going to remix either the EVA front or your Endorphin right rail mount in a few weeks time. I've just cut/sanded off the corner of the Endorphin rail mount for now to stop the belt rubbing.

Perhaps you can find out what the other problem is? I'm guessing something to do with prints being reversed.

Thank you for trying, but I think I'm just going to stick with the front attachments. It's simple, the endstops are in the default location and everything works as intended. As per the other person, they [said](https://www.reddit.com/r/ender5/comments/169eomj/comment/jz3eyml/?utm_source=share&utm_medium=web2x&context=3): > I changed the position_endstop for X to zero and no[sic] Y moves correctly but that creates a new problem. I've no idea what the other `new` problem is they mention but unfortunately I don't have the time to keep switching the belts to `experiment`. I really need a stable system, this is my only printer and due to the location of the front attachments in EVA I have to fully strip the carriage to access them. That means doing all the wiring, fans, extruder, redoing BLtouch, resetting XYZ offsets and also using different belts. I'm just going to remix either the EVA front or your Endorphin right rail mount in a few weeks time. I've just cut/sanded off the corner of the Endorphin rail mount for now to stop the belt rubbing. Perhaps you can find out what the other problem is? I'm guessing something to do with prints being reversed.
roastcuprepeat commented 2023-11-26 17:10:05 +01:00 (Migrated from github.com)
Copy Link

I can also confirm that modification needed in klipper/klippy/kinematics/hybrid_corexy.py

I can also confirm that modification needed in klipper/klippy/kinematics/hybrid_corexy.py
endorphin3d commented 2023-11-26 19:12:14 +01:00 (Migrated from github.com)
Copy Link

@roastcuprepeat did you happen to mess with position_endstop for both stepper_x and stepper_y? I'm trying to pin down exactly what the variable is here, because I ran the EVA printhead just fine without any modification to the hybrid_corexy.py for quite some time.

There's four possible combinations for position_endstop:

  1. Set to 0 for both x and y
  2. Set to the max for both x and y
  3. 0 for x, max for y
  4. Max for x, 0 for y

I'm now running the Vz printhead with the belt attached at the front, and both my x and y are set to the max (220 and 200 respectively). I'm guessing that some combination other than that will yield you a working kinematic without having to touch the .py file.

@roastcuprepeat did you happen to mess with `position_endstop` for both stepper_x and stepper_y? I'm trying to pin down exactly what the variable is here, because I ran the EVA printhead just fine without any modification to the `hybrid_corexy.py` for quite some time. There's four possible combinations for position_endstop: 1. Set to 0 for both x and y 2. Set to the max for both x and y 3. 0 for x, max for y 4. Max for x, 0 for y I'm now running the Vz printhead with the belt attached at the front, and both my x and y are set to the max (220 and 200 respectively). I'm guessing that some combination other than that will yield you a working kinematic without having to touch the .py file.
roastcuprepeat commented 2023-11-27 01:17:58 +01:00 (Migrated from github.com)
Copy Link

@roastcuprepeat did you happen to mess with position_endstop for both stepper_x and stepper_y? I'm trying to pin down exactly what the variable is here, because I ran the EVA printhead just fine without any modification to the hybrid_corexy.py for quite some time.

There's four possible combinations for position_endstop:

  1. Set to 0 for both x and y
  2. Set to the max for both x and y
  3. 0 for x, max for y
  4. Max for x, 0 for y

I'm now running the Vz printhead with the belt attached at the front, and both my x and y are set to the max (220 and 200 respectively). I'm guessing that some combination other than that will yield you a working kinematic without having to touch the .py file.

@endorphin3d Currently I 'm runnning x and y endstop at max position, dir pin is reversed from the original config.

> @roastcuprepeat did you happen to mess with `position_endstop` for both stepper_x and stepper_y? I'm trying to pin down exactly what the variable is here, because I ran the EVA printhead just fine without any modification to the `hybrid_corexy.py` for quite some time. > > There's four possible combinations for position_endstop: > > 1. Set to 0 for both x and y > 2. Set to the max for both x and y > 3. 0 for x, max for y > 4. Max for x, 0 for y > > I'm now running the Vz printhead with the belt attached at the front, and both my x and y are set to the max (220 and 200 respectively). I'm guessing that some combination other than that will yield you a working kinematic without having to touch the .py file. @endorphin3d Currently I 'm runnning x and y endstop at max position, dir pin is reversed from the original config.
endorphin3d commented 2023-11-28 01:18:40 +01:00 (Migrated from github.com)
Copy Link

@roastcuprepeat If you're willing, I'd love to know what the printer does when you do the following:

  1. Set the direction pins back to the original
  2. Set the x position_endstop: 0
  3. Leave the y endstop set to the max
  4. Undo your changes in the .py file

I just did this on my printer and it moved correctly for a printhead where the belts attach at the back rather than the front.

@roastcuprepeat If you're willing, I'd love to know what the printer does when you do the following: 1. Set the direction pins back to the original 2. Set the x `position_endstop: 0` 3. Leave the y endstop set to the max 4. Undo your changes in the .py file I just did this on my printer and it moved correctly for a printhead where the belts attach at the back rather than the front.
roastcuprepeat commented 2023-11-29 05:06:02 +01:00 (Migrated from github.com)
Copy Link

@endorphin3d

Unless my understanding is wrong I think we have to reverse the direction pins.
However I'll try more test when i have more time this weekend because I really don't want to touch the hybrid_corexy.py

@endorphin3d Unless my understanding is wrong I think we have to reverse the direction pins. However I'll try more test when i have more time this weekend because I really don't want to touch the hybrid_corexy.py
endorphin3d commented 2023-12-04 20:23:36 +01:00 (Migrated from github.com)
Copy Link

@roastcuprepeat I can't speak for your printer, but reversing the pin wasn't necessary for me. I guess it depends on which direction it runs by default. Klipper sees a position_endstop: 0 and moves the printhead along the X in one direction when homing and position_endstop: 220 makes the printhead in the opposite direction. If you're able to try the suggestions I mentioned above, it would provide me with some valuable insight.

@roastcuprepeat I can't speak for your printer, but reversing the pin wasn't necessary for me. I guess it depends on which direction it runs by default. Klipper sees a `position_endstop: 0` and moves the printhead along the X in one direction when homing and `position_endstop: 220` makes the printhead in the opposite direction. If you're able to try the suggestions I mentioned above, it would provide me with some valuable insight.
roastcuprepeat commented 2023-12-04 21:01:43 +01:00 (Migrated from github.com)
Copy Link

@endorphin3d Sure. Sorry didnt have time last weekend but definity will test and report back.

@endorphin3d Sure. Sorry didnt have time last weekend but definity will test and report back.
roastcuprepeat commented 2023-12-06 00:15:45 +01:00 (Migrated from github.com)
Copy Link

@endorphin3d

  1. I switch back to the original hybrid_corexy.py
  2. Set the direction pins back to the original
  3. Set the x position_endstop: 0

with G28 X0, X home to the switch.
Y moves without moving X
but now the coordinate is mirrored on X?
now I have (220,0)at bottom left.

@endorphin3d 1. I switch back to the original hybrid_corexy.py 2. Set the direction pins back to the original 3. Set the x position_endstop: 0 with G28 X0, X home to the switch. Y moves without moving X but now the coordinate is mirrored on X? now I have (220,0)at bottom left.
endorphin3d commented 2023-12-06 15:33:16 +01:00 (Migrated from github.com)
Copy Link

@roastcuprepeat Thanks so much for the info--I knew there was some tradeoff to this but I couldn't remember what it was. You can actually change the print origin in your slicer to match the printer. This is what my settings look like in OrcaSlicer. You could play with both X and Y to see what fits your printer.

Screenshot 2023-12-06 at 9 28 28 AM

@roastcuprepeat Thanks so much for the info--I knew there was some tradeoff to this but I couldn't remember what it was. You can actually change the print origin in your slicer to match the printer. This is what my settings look like in OrcaSlicer. You could play with both X and Y to see what fits your printer. ![Screenshot 2023-12-06 at 9 28 28 AM](https://github.com/endorphin3d/endorphin/assets/128183604/00b694e5-b426-47bc-8521-9b55603f4430)
roastcuprepeat commented 2023-12-06 17:09:35 +01:00 (Migrated from github.com)
Copy Link

@endorphin3d This setting doesnt let us to mirror the axis, however in theory if I reverse the dir pin of y i can get a 180 degree rotated bed.

edited - just tried reversing dir pin of Y.. now moving Y crashes X. so afterall I still need to change the schematic file..

@endorphin3d This setting doesnt let us to mirror the axis, however in theory if I reverse the dir pin of y i can get a 180 degree rotated bed. edited - just tried reversing dir pin of Y.. now moving Y crashes X. so afterall I still need to change the schematic file..
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something isn't working
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 enhancement
New feature or request
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 invalid
This doesn't seem right
 question
Further information is requested
 wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
h3n3
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: h3n3/endorphin#3
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?