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.

@chrishamm The patch works.

@tas I think you have to compile it. I will give it a try. I think it should work.

@chrishamm I think the codes lead to a subtle situation where it just happened to work unintentionally. As far as I recall, duet mini 3 has CAN bus capability, by another word, there will be a valid CAN address.

Please see following picture, the accelerometerId is "0", so long if there is a board with canAddress equals to 0, the find will return a valid board. Therefore as long as we have a board with canAddress matching, we will not have the problem.

However with duet 2 wifi, we dont have such a board, it will always return undefined in line 495, and exception afterwards.

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

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

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

Does the CPU have the available processing power for this? Or we are talking about all in-browser viewer?

@dc42 Confirmed working. Thanks.

@phaedrux Interesting link. That's a very good direction. I could just list a few candidate values. Didn't think about that. Thanks.

Thanks, @deckingman, and @T3P3Tony.
I know that M207 without parameter could get the current settings, but generating the new command to alter this by "hand" doesn't seems attractive.
As I plan to implement it on my own, and agreed there just might be too many settings for DWC, therefore my goal was not to merge it.
Since I'm new to RRF, suggestions on how it should be done will be very valuable to me. And it will reduce future maintenance headache to have my own fork.

The extruder/tool point is a very valuable point.