Best posts made by alexjx

I've tested this by adding the extra E:xxx field into the M114 result. octoprint is now happy.

There is a bug in the latest 3.5B4 input shaping plugin, when we try capturing data, we always get "Data collection cancelled" error message. If it's a multi-move test, only the first move will be recorded due to this error. Others have seen such issue too.[https://forum.duet3d.com/topic/32383/input-shaping-plugin-not-collecting-data-using-3-5-0-beta-3/23]
I'm using a proper shielded cable (shield grounded), so I think I could rule out the potential cable issue.

The problem is that the plugin assumes we're always using the CANBUS to connect the accelerameter, and following code will throw if it's a none CANBUS board, as in my case a Duet2 WIFI.

// src\plugins\InputShaping\RecordMotionProfileDialog.vue:494

			// Get board
			const board = this.boards.find(board => board.canAddress === parseInt(matches[1]));
			if (!board) {
				throw new Error("Failed to get accelerometer board");
			}

I have zero exprience in Vue, and less in frontend, so I don't know what a proper fix should be. However, can we assume that for a none CAN-connencted board, the canAddress will always be null? And there should only be one such board? Like following?

			// Get board
			const board = this.boards.find(board => board.canAddress === null || board.canAddress === parseInt(matches[1]));
			if (!board) {
				throw new Error("Failed to get accelerometer board");
			}

Thanks
Jia

Hi gurus,

I was confused that G92 has no effect on E axis. After a bit of search, I came across the post @dc42 wrote. I understood the philosophy that RRF has chosen to prefer relative extrusion over absolute. However, this also breaks the compatibility with other firmware like MARLIN.

My case is that I was using octoprint with MARLIN before I converted to duet wifi recently. I managed to make octoprint to handle filament run outs... However the "pausing" of octoprint relies on the M114 to get the positions of the axes include E axis. And this is broken because the M114 in RRF returns the "extrusion since the board started."

I know I could just use relative extrusion everywhere. But for the sake of completeness, should M114 return the "virtual extrusion position" as the E axis without any suffix? For example:

X:0.000 Y:0.000 Z:0.000 E:0.0 E0:0.0 E1:0.0 E2:0.0 E3:0.0 E4:0.0 E5:0.0 E6:0.0 E7:0.0 E8:0.0 Count 0 0 0 Machine 0.000 0.000 0.000 Bed comp 0.000

I haven't tried this yet, Is there anything bad about this idea?

Jia

@chrishamm The patch works.