Posts made by CMP

@dc42 thanks for the quick reply!

I will test it as soon as it becomes available.

Is there a reason the ratio 'Encoder counts/rev' vs 'steps/rev' has to be that high? With my current encoder I'll only get a ratio of 2:1.

Hi,

I have problems getting my encoder to work.

The relevant config.g line looks like this:

M569.1 P50.0 T2 C400.0 S200.0 R100.0 I0.0 D0.0
M569 P50.0 D4 S0

This doesn't seemed to be supported by the firmware, because I get this error:

"Error in start-up file macro line 26: Encoder counts/rev must be at least four times steps/rev"

The encoder is an RLS LM10IA Linear encoder that outputs an quadrature signal. The encoder and the steps/revolution is fixed. Is there someway I can ignore the error meassage?

The purpose of the encoder is to counteract a bad/inconsistent Linear Motion System.

I know that linear encoders should be combined with a magnetic shaft encoder but why shouldn't it work standalone?

Thanks!

@t3p3tony thanks for the quick response/help!

I want to design a DIN Rail Adapter for the Duet 3 Expansion 1HCL.
A CAD-File would be helpfull, but I can't find it anywhere (not on docs.duet3d.com or github).

Am I missing something or is the file not uploaded yet?

Since I manually cool my hotend and swap it with the milling tool, I only have a post.g for tool 4:

• tpost4.g
  ; called after tool 4 has been selected
  M280 P7 S40 ;start ESC
  G4 P2000
  M280 P7 S1150 ;Start Motor with 10% speed
  G4 P1000
  M280 P7 S2000 ; 100% Motorspeed

I didn't have time to the test yet, but updating the firmware to 3.3 hasn't changed anything.

@generisi
Thanks for trying to help me out!

I'm running RFF 3.2.2 (2021-02-11).

Your first Idea seems to be the same as powering the printer down and restarting it. I do this every day and still get different results.

I'll try these 3 variations next Wednesday since I don't have access to the printer up till then.
Hopefully some of these test will reveal the reasons I'm having these problems

This is my result after homing+milling 5 times the same spot. I could't spot any difference.

I know, that this is not the center of my part, this is due to the problem with the offset of the milling tool

@generisi

I know that the ASMBL is not meant for milling the whole part, thats why I'm milling very slowly.

My steps are:

1. Homing with the print head connected and an selected (Tool 1 in dwc)
2. printing the part
3. swapping to the milling tool/Tool 4 in dwc (without homing)
4. milling the part

I did this a few times. The gcodes for milling and printing stayed the same. I didn't copy those codes together but used them individually, as they came out of Cura and Fusion360.
The reason I did this is to dial in the offset for the milling tool. The printhead/Tool 1 has no Offset in X/Y (G10 P1 X0 Y0 Z-0.50). The offset for the milling tool right now is G10 P4 X-14.49 Y4.14 Z-17.00

At first I thought the problem was the gcode from Fusion360. So I wrote the milling-gcode by myself. But the problems stayed the same.

So my next step was to check if the toolchanging system had a problem. I printed and milled the part and then changed to the printhead again. I moved the printhead a few mm in every direction and then switched to the milling tool again. I milled the exact same part, that I milled before, again and noticed no deviation. This should mean, that my toolchanging system has no significant tolerance.

Thats when I started the tests as described above. Since my first post I have got more test/measuring results:

deviation in Y [mm]:

deviation in X [mm]:

I will try the test you proposed and report back with the results. But I'll still thing that homing should not matter.

@generisi i have endstops. But those should impact the tool offset.

@fcwilt

I'm using something similar to this: https://e3d-online.com/blogs/news/asmbl
The goal is to get increase the accuracy of the dimensions of the printed part and also to improve the quality of the surface.

To adjust to offset between the printhead and the milling tool I printed this part:

After milling it I me measured X1, X2, Y1 and Y2 (see drawing below)

The dimensions in my first post are the difference between X1/X2 and Y1/Y2. According to the constrution of the part and the milling programm the difference should be close to 0. But it keeps changing (especially in the Y-direction).

I hope you can understand my problem better now.

Hi everyone,

my printer with a Duet 3 6HC Board has a stange behavoir. When I print the exact same part and mill it afterwards I get diffrent results every time. I'm printing a rectangle with a cube on top of it and then milling that cube. I measured the distance from the edge of the rectangle to the cube in every direction. Here are my results.

deviation Y-Axis [mm]:

deviation X-Axis [mm]:

I noticed this behavior bevor measuring these parts, so prior to these test I removed my removeable glasbed and checked if every bolt is tight.
When changing the tools and milling the same part again there is no noticeable offset. But when I print the part again the problem appears. So the toolchanger is not the problem but the printer seems to place the part "randomly" on the printbed.

Any Advice on how to fix that problem?

Thank you for the Information.
I'll try it in standalone mode, the next time I get the chance.

Yes I did and it didn't work

@Veti I think thats because I didn't care to write the command for 1/16 step for all steppers since its the default.

No, I'm using it with the Pi. But the Problem was the same with the duet 2 ethernet (but with an older RRF 3 Version)

The password on the PI and the duet are the same.

DWC 3.2.0

I tried changing it with the command line after refreshing nothing changed.
Accessing with a diffrent browers: No password required.

When using M98 P"config.g":
Microstepping - X:16(on), Y:16(on), Z:16(on), U:16(on), E:16(on):16(on)
Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 299C
Warning: M307: Heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 299C
Warning: M307: Heater 1 appears to be over-powered. If left on at full power, its temperature is predicted to reach 644C

I assume that means my config.g is working.

Is it possible that this problem has to do something with our network?

M551 P"dummy2021" ; Machine password

Hi everybody,

after I update to RRF 3, I no longer get ask for the password in webcontrol (with the duet 2 ethernet).
It doesn't mather which devise I use.

After swiching to the duet3 6HC this Problem still exists (running RFF 3.2).

Does anyone else have this Problem?