Posts made by alexjx

@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.

Hi all,

I'm new to RRF and duet, but found it advance and exciting.
And I've just converted my ultimaker 2 clone to use duet2 wifi. One feature I was hoping to get back is the firmware retraction.
It has the advantage to adjust the retraction amount and speed on the fly, instead of cancel and re-slice the model.

To achieve this, I need to improve the following things,

1. Make the status reporting the current retraction settings. Maybe in type 2?
2. Add an extra parameter to M207 to set the tool if more than one tool is configured. Default is to choose the current tool.
3. Enhance the DWC to have input components for adjusting these values.

Maybe this might not eventually merge back to the mainstream, but I'd like some advice before I got started.
And avoiding conflicting with mainstream direction will also make my life easier when maintaining it.
Thanks in advance.

Jia

I observed a similar issue recently too. When sending "M0 H1", if I put any code into stop.g, my heaters are all off and my tool got deselected. But the behavior is different if the file is empty. I believe this is a bug. I think the problem happens because the machine state is pushed to stack but the gcode buffer is not.
The stopping logic is executed after the macro runs, then testing the "H" flag. By then the gcode buffer contains the last line in the macro. The stopping will always be executed as if there is no "H" flag. This is confirmed if I put an "M117 H1" into the last line of stop.g, "M0 H1" behaves as expected.

I currently don't have a simple solution, since the state should be set to "normal" when macro exists, but by then the state has already pushed to stack...

@dc42 said in Any g-code in stop.g causes heaters to turn off:

[I didn't agree with the introduction of the H1 parameter, and I am minded to remove it.]

I think the H flag has its use for cases. Excuse me that I'm new to RRF. But I found that once the heater got disabled, only tool re-select will enable it back on.
I have a dual extrusion printer, similar to an Ultimaker 3 with a lifted second nozzle. With this setup, the "no tool selected" state is actually invalid.
If the current mechanically activated tool is selected again, the switch will hit the switching dock in a very unpleasant way. If there is no other solution, I think the "H" flag, in this case, will benefit my scenario.