Input Shaper Plugin Requires Dummy Axis to be Homed

curieos

Our machine is setup with independent Y motors, and in order to adjust for inaccuracies in the endstop positions, I have it setup to split the Y axis into Y and V after homing, moving the V motor to tram the Y gantry, and then recombining them post-homing.

I think this is causing issues with the Input Shaper plugin where it doesn't recognize the machine as being fully homed. Is there a way to deal with this?

edit: I think I miscategorized this, I think it should be in plugins for DWC. Can someone please move this?

p8blr

@curieos Shouldn't have to split up your axes with multiple endstops configured in M574

M574 Y1 S1 P"0.io2.in+0.io3.in"

M574 docs page

jay_s_uk

@p8blr you will if you need to adjust for skew. There's no way to do it when there are multiple endstop combined

p8blr

@jay_s_uk Not sure how you're adjusting the axes, but it will compensate for skew if you have adjustable endstops.

Something like this:

curieos

@p8blr The endstops do not have adjustment, nor do we have provisions in the design for this. Besides, I prefer making the endstop mount rigidly and compensating for minor inaccuracies with software adjustments. This method is more repeatable in my experience.

Phaedrux

@curieos said in Input Shaper Plugin Requires Dummy Axis to be Homed:

I think this is causing issues with the Input Shaper plugin where it doesn't recognize the machine as being fully homed.

What exactly are you seeing in the plug?

What gcode commands are you using to split and combine the axis?

curieos

@Phaedrux
All axes are homed, minus the hidden V that has no motors assigned.

homey.g looks like this:

var LY_driver = move.axes[1].drivers[0]
var RY_driver = move.axes[1].drivers[1]

G91											; relative positioning
G1 H2 Z5 F3000								; lift Z relative to current position
G1 H1 Y-655 F6000							; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y5 F3000								; go back a few mm
G1 H1 Y-10 F360								; move slowly to Y axis endstop once more (second pass)
M584 Y2.2 V2.3 P5							; separate Y axis into two axes
M584 Y{var.LY_driver} V{var.RY_driver} P5	; separate Y axis into two axes
M92 V{move.axes[1].stepsPerMm}				; set new axis steps per mm
M564 H0										; allow movement without homing to square
G1 H2 V{global.y_axis_skew}					; square Y by moving V
M584 Y{var.LY_driver, var.RY_driver} V P4	; rejoin Y axis and hide U from UI
G1 H2 Z-5 F3000								; lower Z again
M564 H1										; enforce axis minimums and maximums and only allow movement after homing
G90											; absolute positioning

Phaedrux

What does M119 show for endstop states when you get that error?

Can you try sending the lines from your homing file one at a time? Do you get any errors?

I also see you're using a mix of U and V. Do you also have a U axis?

curieos

@Phaedrux To be clear, I'm not having any issues homing. No errors are encountered at any point. Everything works perfectly, the only issue is the IS plugin won't allow me to record motion profiles because it thinks the machine is not fully homed.

It's an IDEX printer, so the secondary toolhead is the U axis. It also has a euclid as Z-probe, so that displays as being triggered when it's not deployed since it's NC.

Phaedrux

As a work around can you try unmapping the V endstop with an M574 command in your homing file after it's been hidden? Or try adding an M92 V command to force it to be marked as homed?

curieos

@Phaedrux Do you mean G92? M92 sets axis steps per mm.

Phaedrux

@curieos Yes, sorry, G92

curieos

@Phaedrux That doesn't seem to work. I was looking in the model browser, and it wasn't updating user workspace coordinates for that axis though. I added it to the homing macros, and I tried running it in the console and it didn't seem to do anything. I can try again when I get into work.

curieos

@Phaedrux It's working now. Not sure what changed, but I did put it in a slightly different place this time.