Homeall.g fails when homing all axes

developeralgo222

@fcwilt said in Homeall.g fails when homing all axes:

Now if you have specified your X axis with M208 -170:170, meaning X=0 is at the center of the axis you could add the following:

i have M208 X0:340 Y0:447

developeralgo222

@developeralgo222

Attached is my config

config.g

fcwilt

@developeralgo222 said in Homeall.g fails when homing all axes:

i have M208 X0:340 Y0:447

That is fine - you don't have to have X=0 at the center of the bed. Some folks just prefer it that way - I am one of them.

Frederick

developeralgo222

@fcwilt
That worked for X &Y and Z , i am going through all the axes one-by-one following your insights .

How do you configure the endstops of a shared z-axis cam based

i have to configure endstops for 6-Nozzles ( 2 Nozzles share a single Z-axis based Stepper motor ) so that they trigger correctly

i.e 3 Stepper Motors for Z, U, V axis but each axis shared with 2 nozzles each with a Z-axis type.

fcwilt

@developeralgo222 said in Homeall.g fails when homing all axes:

How do you configure the endstops of a shared z-axis cam based

i have to configure endstops for 6-Nozzles ( 2 Nozzles share a single Z-axis based Stepper motor ) so that they trigger correctly

i.e 3 Stepper Motors for Z, U, V axis but each axis shared with 2 nozzles each with a Z-axis type.

That is not a setup I have seen or heard of.

Does the "Z stepper" turn the cam to raise/lower the nozzle?

Does each nozzle have it's own endstop sensor?

Frederick

developeralgo222

@fcwilt said in Homeall.g fails when homing all axes:

Does each nozzle have it's own endstop sensor?

Yes, Each Nozzle has its own endstop . With CAM kind of shared axis when it moves down 1 nozzle the other stays at zero or is lifted back to zero point by the spring to where there is a stopper to prevent it from flying over.

fcwilt

@developeralgo222 said in Homeall.g fails when homing all axes:

Does each nozzle have it's own endstop sensor?

Yes, Each Nozzle has its own endstop . With CAM kind of shared axis when it moves down 1 nozzle the other stays at zero or is lifted back to zero point by the spring to where there is a stopper to prevent it from flying over.

OK.

Since you are using NPN sensors the outputs pull the inputs they are connected to to ground (GND)

I'm assuming only one of the sensors has the beam of light blocked when the nozzle is down.

If I am reading the spec sheet correctly the white wire is pulled to ground when the beam is blocked.

If so, you would want to connect both of the white wires to the Duet input and use the ! prefix character to treat the low input signal as active.

As before you would have a G1 H1 move in the direction of the sensor.

Are these nozzles simply up or down OR do they move over a range of vertical travel?

Frederick

developeralgo222

@fcwilt said in Homeall.g fails when homing all axes:

Are these nozzles simply up or down OR do they move over a range of vertical travel?

They move over a vertical range of travel actually from 0 to -/+ 70 before they trigger the endstop . all have a range of -90:90 but technically
so
(1) On Z-Axis Motor , Z1 has a move range from 0 to -90 and Z2 has a move range from 0 to +90. When one is down , then other is always at zero
(2) On U-Axis Motor , Z3 has a move range from 0 to -90 and Z4 has a move range from 0 to +90. When one is down , then other is always at zero
(3) On V-Axis Motor , Z5 has a move range from 0 to -90 and Z6 has a move range from 0 to +90. When one is down , then other is always at zero

fcwilt

@developeralgo222

Thanks, that makes things more clear.

The homing code should be pretty much the same as before, though I don't actually know how the firmware handles two endstops.

How do you convert stepper position to nozzle position?

Frederick

developeralgo222

@fcwilt said in Homeall.g fails when homing all axes:

How do you convert stepper position to nozzle position?

its just Z-axis as any other , no difference .The CAM on the motor just moves or rotates clockwise or counterclockwise to move the nozzles on the Z-based axes up or down

droftarts

@developeralgo222 As each endstop is triggered at the end of movement for each nozzle, I would think you are best off redefining the endstop when a different tool is requested, followed by a move to trigger that endstop. eg something like

; home Z1
M574 Z1 S1 P"1.io0.in"  ; configure active high endstop switch for low end on Z via pin 1.io0.in
G91                     ; Use relative positioning
G1 H1 Z-180             ; go to endstop
G90                     ; Use absolute positioning

; home Z2
M574 Z2 S1 P"1.io1.in"             ; configure active high endstop switch for High end on Z via pin 1.io1.in
G91                     ; Use relative positioning
G1 H1 Z180              ; go to endstop
G90                     ; Use absolute positioning

I'm not sure how this would interact with OpenPNP, though.

Ian

developeralgo222

@droftarts said in Homeall.g fails when homing all axes:

I'm not sure how this would interact with OpenPNP, though.

this is where i am also having doubts how that would work with OpenPNP

droftarts

@developeralgo222 How does OpenPNP enable a tool? If it uses tool commands, eg T0, T1, T2 etc, then you can put the above code in the tpre#.g tool change macro. See https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing

Ian

T3P3Tony

@developeralgo222

I would get it working directly and then see how that translates to OpenPnP

developeralgo222

@droftarts @T3P3Tony @dc42

FYI,

this method doesn't work on both Duet and OpenPnP. Only one end point is active & can be triggered on the shared axis Z, U or V. I am not sure how to configure this is Duet3 for it to work.

Can someone help on this ?

i have 1 motor for each CAM shared Z-type axis . i.e 3 Axes ( Z , U , V ) each with its own Motor controlling the shared axis with Nozzle pair

Z-axis is shared between CAM Z1 (Has an Endstop1 & Nozzle 1 ) & Z2 axis ( Has an Endstop2 &Nozzle 2)

V-axis is shared between CAM Z3 (Has an Endstop3 & Nozzle 3 ) & Z4 axis (Has an Endstop4 & Nozzle 4)

V-axis is shared between CAM Z5 (Has an Endstop5 & Nozzle 5 ) & Z6 axis (Has an Endstop6 & Nozzle 6)

Z , U , V ( Z-Axis = (Z1, Z2), U-Axis = (Z3, Z4), V-Axis= (Z5, Z6) ) only Z2 , Z4, Z6 triggers Z , U , V respectively but not Z1, Z3, Z5

They move over a vertical Z-based axis range of travel actually from 0 to -/+70 degrees before they trigger the endstop . all have a rotational range of -90:90 but technically
so
(1) On Z-Axis Motor , Z1 has a move range from 0 to -90 and Z2 has a move range from 0 to +90. When one is down , then other is always at zero
(2) On U-Axis Motor , Z3 has a move range from 0 to -90 and Z4 has a move range from 0 to +90. When one is down , then other is always at zero
(3) On V-Axis Motor , Z5 has a move range from 0 to -90 and Z6 has a move range from 0 to +90. When one is down , then other is always at zero

developeralgo222

@developeralgo222

Any help on this please ?

droftarts

@developeralgo222 I think this is more of an OpenPNP configuration issue than a Duet configuration issue, and I'm not sure how to resolve it. I've had a look at the OpenPNP documentation for defining nozzles here https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_Nozzle-Setup and axis mapping here https://github.com/openpnp/openpnp/wiki/Mapping-Axes

This makes me think that, rather than using the RepRapFirmware toolchanging mechanism, ie T0, T1, T2 etc, it interacts with the axes directly. Also, with the 'Nozzle Pair, Shared Z Axis, Cam' option selected, it seems the additional endstop on each axis isn't particularly needed, and the nozzle pair just has the axis offsets set in OpenPNP. However, that's just how it appears to me, and I don't have a test setup to even begin to check this.

So I think it this case it might be best to ask the OpenPNP users how this should be set up, if you haven't already. See https://github.com/openpnp/openpnp/wiki/Getting-Help for their support options.

Alternatively, if you can supply some Gcode generated by OpenPNP that includes how it changes tool, it may give us a better idea about how to control the tool changes.

Ian

developeralgo222

@droftarts

i think on the Duet3D side we need to use endstops while on the OpenPNP side you use soft limits . The issue happens when you have a Axes with soft limit, it will sometimes go past the soft limit by a very small offset but when there is an endstop triggered that motion/ movement comes to a stop and does not go past.

On all the Axes, i have endstops in Duet3D 6XD controller and i have Soft Limits on OpenPnP