2nd independent Z-Axis labeled V Homing failed

jsinicro

@o_lampe I shouldn't be, maybe that's my mistake, 0.1 and 0.4 should be 2 motors on one Z axis and 0.0 and 0.5 should be on the V axis or vice versa but not mixed. thankyou for catching that.

jsinicro

@dc42 OK, I will try that, I am currently using G30 for both but with different tools K0, K1. OK I have RRF 3.2.2 on all 3 boards the doc says 3 and later, but will test.

jsinicro

@jsinicro looks like it is correct :

M584 X1.0:3.0 U3.0 Y0.2:0.3 Z0.0:0.5:0.1:0.4 V0.1:0.4 E1.1:3.1 p5

Z0.0:0.5:0.1:0.4 these 4 motors for both Z axis. Driver0 and 5 on main 6HC then a ":" 0.1:0.4 these are for the 2nd Z axes called V so then V0.1:0.4 has the other 2 motors on driver1,4 on 6Hc. That was my interpretation of the M584. I think in my opinion these G-code commands are hard to interpret meaning: the exact syntax. is there a parsing grammar associated with it or BNF grammar.

Maybe in the above command for Z all i need is the 0.0:0.5 but the X axis is defined in the same manner and both X and U home successfully.

jsinicro

@jsinicro G38.2 P0 doesn't deploy the bltouch.

jsinicro

@jsinicro I've separated the M584 X and Z axis to:

M584 X1.0 U3.0 Y0.2:0.3 Z0.0:0.5  V0.1:0.4 E1.1:3.1 p5

Each axis now homes individually except for the V axis the bltouch will not deploy using the G38.2 P0 command with RRF 3.2.2

I tried G30 K0 and the probe deployed on the V axis but the Z axis moved down instead the V axis did not move down.

if I do G28 V it doesn't deploy nor move down.

Looks like I can deploy both bltouch probes if I combine all motors to the Z axis but so far can't deploy the V axis with its own bltouch.

dc42

@jsinicro said in 2nd independent Z-Axis labeled V Homing failed:

@jsinicro G38.2 P0 doesn't deploy the bltouch.

See my previous response.

jsinicro

@dc42 Yes, I was confirming what you said that in 3.2.2 it will not deploy the blotouch. I was looking on how to upgrade from 3.2.2 to 3.3RC2 however I was not sure on how to do the upgrade with out building the binaries, then I found this link https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3RC2 which lists all the .bin files and others, so looks like I will need to download all individual files one at a time, or will it be easier to connect to an SBC in my case raspberry pi 4, which is what I used to upgrade to 3.2.2, but still you mention that you're not sure if it will take the trigger height into account. I've decided to combine all motors to just the X, and Z axis and get rid of the U, V and test it out everything is working except the X axis when homing is moving in the opposite direction of where the endstops are located not sure why. I tried to configure M574 with X1 and X2 parameters but it always moves away from the endstops. Not sure what to do here.

Phaedrux

@jsinicro said in 2nd independent Z-Axis labeled V Homing failed:

I tried to configure M574 with X1 and X2 parameters but it always moves away from the endstops. Not sure what to do here.

You control the direction of movement in the homing files. The M574 just defines if the endstop is at low or high end. It's up to you do set the direction towards the endstop in the homing files.

jsinicro

@phaedrux do you have a link on how to do that

homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v3.2.3 on Sun Apr 18 2021 23:08:10 GMT-0400 (Eastern Daylight Time)
G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 X-705 F1100 ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F6000    ; go back a few mm
G1 H1 X-705 F360  ; move slowly to X axis endstop once more (second pass)
G1 H2 X5 F6000  
G1 H2 Z-5 F6000   ; lower Z again
G90               ; absolute positioning

Do I need to change this line: G1 H1 X-705 F1100 to G1 H1 X705 F1100
thx

jsinicro

@jsinicro But that would mean that the positive X axis is in the reverse direction as it was before

Phaedrux

The G1 H1 X move being positive or negative moves it to the low or high end.

The actual direction of travel is dictated by the direction of the rotation of the motor itself defined by M569 S0/S1.

Typically you'd want it configured such that 0,0 is in the front left corner when looking at the printer from the front with -x moving to the left, +x moving to the right, -y moving to the front, +y moving to the back. This maintains a coordinate system compatible with CAD and slicing software and keeps the preview matching the actual print with no mirroring or flipping.

In a Corexy it gets a bit more complicated because of the shared motion between 2 motors in tandem. https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter#Section_Testing_motor_movement

jsinicro

@phaedrux yes this is what I have:

jsinicro

@jsinicro it was moving correctly before, but now when I move +X it moves towards the negative X and when I home it moves towards the +X direction away from the endstops.

o_lampe

@jsinicro
There is another way to screw up the printing directions, when you set a custom kinematics model.
Do you have such a line in your config.g?

Example:

M669 K1 X1:1:0:0 Y1:-1:0:1 Z0:0:1:0 V0:0:0:-1

The positive and negative signs can change the whole printer behaviour.

Phaedrux

@jsinicro said in 2nd independent Z-Axis labeled V Homing failed:

it was moving correctly before

Before what? What changed?

What is the kinematic model used? I don't even see a M669 line in your config posted above.

jsinicro

@phaedrux OK, you are correct, M669. I didn't know about it, I will add that.

So I've been doing a little research on the benefits of having individual controlled X and Z axis, however I have not found anything on my original thought on how I wanted the printer to benefit from it. Basically separate extrusion in parallel on the same print. I've not seen any firmware supporting this. Looks like at most I can do 2 separate prints in parallel or have one print with separate color filament.

This is my current test config.g, I was able to have X,Y,Z and U homed correctly in the right direction.

[0_1621031069933_latest_sys.zip](Uploading 100%)

jsinicro

@o_lampe OK, I do not have a M669, but looks like I need it. Reading up on, trying to understand it. I've actually upgraded to 3.3.RC2 and will test G38.2 and see if that works

jsinicro

@o_lampe Hi, so for a cartesian printer would this be correct:
M669 K0 X1:0:0 Y0:1:0 Z0:0:1 U1:0:0 V0:0:1

jsinicro

@jsinicro What is the target position in G38.2 V? P0

jsinicro

@jsinicro OK, I tested it target position basically how much to lower the axis. However the V axis moves down the correct probe deploys and once it hits the bed it retracts and stops moving, but I still get Homing failed.