Y-axis homing with proximity sensor, ever thought of?

Some people are having problems with the connectors on the microswitch for homing the Y-axis.
That got me thinking using the proximity sensor for the Y-axis too. By adding a small tab on the table at X0, Y0.

The tab would sit high enough for the sensor to detect it without the nozzle touching the bed.And stick out almost all the way to the tab for homing the X-axis. Sittin in the corner of the bed it would never have to go past the Z-axis extrution.

I am thinking that this will require the Z-axis to be homed and to home the Z-axis the Y-axis needs to be homed => catch 22...

If it would work the would be ledd points of failure, a cleaner and neater set up, I think....

Has this been discussed before?
Could it work?
What about firmwares?



Edit: spelling

Edited 1 time(s). Last edit at 01/08/2016 01:57PM by fotomas.

What is the problem that people are having.... I replaced mine micro switch as it was sticking with one from Maplin.

The common problem is that the connection gets lost. I use a soldered connection and everything is fine.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

You could do it if you oversized the bed in the Y direction, so that wherever the bed is, the IR sensor is always over the bed at at (say) X=10. To home all, you would first home X, then move the head to X=10 and home Z, and finally move the head off the bed to (say) X=-5 and home Y.

The firmware would need to be changed so that instead of requiring that X and Y are homed before Z, it requires only X to be homed before homing Z, and also Z before Y.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
Treito
The common problem is that the connection gets lost. I use a soldered connection and everything is fine.

The problem is that the micro switch used is not designed to be used in it's current location.
Upon my machine it's a 3 pin one with the middle pin level with the centre of the Y stepper motor, so that wires go around each side of the shaft and attached to the top and bottom pins. The cable then sits on the shaft which caused to become disconnected. That was fixed with a cable clamp clip fixed to the unused screw hole on the stepper motor.

1) One solution would be move the stepper motor forward and place the switch behind the motor.
Move the lug on printed part, move the hole in end plate.

2) Design a better switch which would have connection nearer the duet connections.

Using a proximity sensor IMHO would be a bit over engineered

Edited 1 time(s). Last edit at 01/08/2016 10:50AM by orictosh.

---

Supporting 3D Printers with Parts and Build services.
Printer: Ormerod 2 (528.4) Duel extruder set-up with Aluminium X-Rib, RRPro Firmware v1.11-ch (2016-04-08)

Unless the design was changed with the Ormerod 2, the main problem IMO is that the cable receptacles provided were made to mate with 0.1" pin headers, not with the solder lugs on the microswitch. So they fall off. A solution would be to use a microswitch with proper Quick Connect (i.e. blade) terminals.

I plan to manufacture some small Hall endstop sensors in the near future, and although I intend them for use in delta printers, they could be used to replace the microswitch on the Ormerod. It's overkill because you don't need accurate homing on a Cartesian printer, unless you are going to home, do part of a print, and home again before finishing the print e.g. to handle a power failure. It's already possible to buy Hall endstop sensors on eBay, but mine will be smaller, neater and 3.3V-compatible.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

For a hall sensor you will need a magnet, don't you? What about a small reflective photo sensor? That was my idea
Something like that. They are also available in another package but my distributor used a wrong device name so I do not know how they are called exactly:
[www.everlight.com]
This is my one:
[cdn-reichelt.de]

Besides that like I said the pin headers fell off the connectors so I exchanged the switch and soldered the dconnection. Regarding the wire path you could put a screw into the steppe motor and connect the cable to it in a away that the wires are pushed away from the pulley. I did this for my Ormerod 1 and my 2 was planned similarly since the beginning.

---

Slicer: Simplify3D 4.0; sometimes CraftWare 1.14 or Cura 2.7
Delta with Duet-WiFi, FW: 1.20.1RC2; mini-sensor board by dc42 for auto-leveling
Ormerod common modifications: Mini-sensor board by dc42, aluminum X-arm, 0.4 mm nozzle E3D like, 2nd fan, Z stepper nut M5 x 15, Herringbone gears, Z-axis bearing at top, spring loaded extruder with pneumatic fitting, Y belt axis tensioner
Ormerod 2: FW: 1.19-dc42 on Duet-WiFi. own build, modifications: GT2-belts, silicone heat-bed, different motors and so on. Printed parts: bed support, (PSU holder) and Y-feet.
Ormerod 1: FW: 1.15c-dc42 on 1k Duet-Board. Modifications: Aluminium bed-support, (nearly) all parts reprinted in PLA/ ABS, and so on.

If you ask me it would solve some problem if the switch was moved on the other side of the ormerod(like Ormerod 1) and the motor would stay in place. You would only need to tell the firmware when it hits the swtich Y=~210.

If you ask me it would solve some problem if the switch was moved on the other side of the ormerod(like Ormerod 1) and the motor would stay in place. You would only need to tell the firmware when it hits the swtich Y=~210.

Quote
orictosh
Using a proximity sensor IMHO would be a bit over engineered

Removing a microswitch and a cable and using an existing sensor is not what I call over engineered. Using software instead if hardware will not cause hardware failure

I am more interested in a discussion around how to implement usage if the proximity sensor for homing instead of the microswitchs be or not to be.

dc42:
I read your comment about the firmware that there would be more to it than change order of things in the homeall.g and specify that the y axis is homed in the low end. The order of homing axis are hard coded to be x,y,z?

Iguess thatbthe is no config value making the firmware using proximity sensor for the y axis either?

Regarding a larger bed to always having bed below the sensor. I have eyeballed my printer and the sensor is always above the bed. Maybe 2-3 mm missing at each side in worst case.

Edited 1 time(s). Last edit at 01/08/2016 02:18PM by fotomas.

The homing order is fixed at X, Y, Z except that if all axes are specified then homeall.g is run instead, leaving you free to choose the homing order. You can already specify in the M558 command that the proximity sensor is used to home the Y axis. So I think there may be enough support already to execute a plain G28, but not G28 Y Z. Also, in the event of resuming a print after a power failure, you would want to home Y without homing Z.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].