Over the past several years I have had different 3D printers and controllers, Melzi, MKS... I have used Marlin and repetier firmware, all with success and generally I have always been able to print what I needed.

My latest is a TronXY X5SA Pro, I really like the mechanics of this printer, it's solid and works well. The stock controller was not terrible, but I wanted better ( to me anyway ). I replaced the controller with a Duet WiFi and 5" paneldue display.

For the most part the new setup just worked. Had to change my way of thinking from what I did in the past, but it was not a big deal.

For what issues I did have questions about, folks on this forum provided quick and useful help and made things that much easier.

So thanks to the developers of this hardware and firmware and to the folks that helped me and the many others I see in the forum.

Joel

@tomasl

I had issues trying to set a static IP as well. I finally got it to work with some suggestions. The steps seems to be very picky. See this thread,

https://forum.duet3d.com/topic/22703/duet-3d-wifi-set-ip-address/7?_=1621469740585

@droftarts

I did think of that, but I notice my MCU just never gets hot and I think it is too far removed from the drivers.

@fcwilt

If I ever open up my controller case, it would not be horrible to glue a thermistor to one of the drivers.

Thanks

OK, I think I got it, was not hard to figure out. Seems M584 is order driven. I just changed Z2:4 to Z4:2 and it seem to be working.

Joel

@Phaedrux

The macro sets the Z height offset which I do before every printing run.

Removing that line you pointed out fixed the issue.

I think I can wait and see what develops. For now things are still working well.

Thanks

@T3P3Tony

I think I'm actually OK with it working the way it does. I moved my build surface back so the far edge is at the end stop. I then gave myself some overhang at the front. Now when I start a print I move the nozzle off the build surface at the front and prime. When I start the print, any ooz gets sliced off.

Thanks For the help

I think I found my issue,

In my Z-offset routine, when I was restoring the probe type, I did not restore the Z trigger height.

Once I fixed the G31 command, the height map works as expected.

OK, I think I found more stuff wrong in the way I'm doing things. My slicer is set up to move the head to where I want it after a print, then I turn off the steppers. I found that turning off the steppers is causing the issue.

What I will do is remove the ending moves from my slicer and let stop.g do it.

Still not sure why I did not see this in 3.4

So far about every update exposes an issue, so far it has been things I have set up that are not quiet right.

So now 4 printers later and numerous clean ups ( each new printer started with the previous printers files ), I think my scripts and setups are zeroing in on being right.

Thanks
Joel

@OwenD

That's easy enough to say, the change lists are sometimes quite long. Unless you have something in mind or it happens to pop in your head while "browsing" through those lists that something might affect you...

Basically, you don't know, what you don't know.

In any case, your pointer was right and I was able to sort it out.

Thanks!

@OwenD

That's easy enough to say, the change lists are sometimes quite long. Unless you have something in mind or it happens to pop in your head while "browsing" through those lists that something might affect you...

Basically, you don't know, what you don't know.

In any case, your pointer was right and I was able to sort it out.

Thanks!

OK, I think I found more stuff wrong in the way I'm doing things. My slicer is set up to move the head to where I want it after a print, then I turn off the steppers. I found that turning off the steppers is causing the issue.

What I will do is remove the ending moves from my slicer and let stop.g do it.

Still not sure why I did not see this in 3.4

So far about every update exposes an issue, so far it has been things I have set up that are not quiet right.

So now 4 printers later and numerous clean ups ( each new printer started with the previous printers files ), I think my scripts and setups are zeroing in on being right.

Thanks
Joel

@OwenD

There is a G1 move at line 7 but I thought stop.g was only called when you cancel a print, not at the end of a print.

This is a new behavior for 3.5.1.

OK - I renamed my stop.g to something else and the error went away. I'm not sure how to fix this. Why is this now being called at the end of a print when in 3.4.x it seemed not to be ( never saw this error before )?

Hi,

I'm getting this error at the end of every print,

Error: in file macro line 7: G1: insufficient axes homed

I am not sure where it is coming from. I made a very simple gcode file,

G90
G1 Z10 X175 Y175 F6000
M84

It does its thing and then gives me the same error.

Any ideas where I should look?

Thanks
Joel

I think I found my issue,

In my Z-offset routine, when I was restoring the probe type, I did not restore the Z trigger height.

Once I fixed the G31 command, the height map works as expected.

@Phaedrux

OK, but it still leaves open what changed? Is there an issue with file handling?

@Phaedrux

I was cleaning up my config.g file and going through it. It brought a question to mind that when I changed something, the height map started working, but I'm not sure why.

In my config file, there is a line G31 P500 X0 Y0 Z-.45 . This setup the offsets for the probe

At the end of my config file there is a G10 X0 Y0 Z0 which I thought was another tool offset, how does it relate to G31? When I do my Z-offset macro, it adds a line to config-override that is a G10 P0 Z xxxx. I thought this was an adjustment to the offset in the G31 Z-.45 offset.

When I commented out the G10 X0 Y0 Z0 in my config.g the height map was still broken. When I changed it G10 X0 Y0 Z-.45 ( to match the G31 setting ), the heightmap started working.

What should I be doing here?

I still don't know how to do the insert gcode thing, so I will attach my config.g as a file

Config.g.txt

Thanks
Joel

@jay_s_uk

I took it out of the Z-home, because I believe that is true. But for Z-offset, config-override gets updated, so won't it need to be read again?

In my z-offset macro I added a delay between M500 and M501, and now it does not get stuck busy.
This is a change in behavior for 3.5.1, in 3.4.x, this was not an issue.

I tried something,

I commented out the M501 from my z-offset macro, everything worked fine. I then ran M501 from the console and everything still worked OK. I uncommented M501 in my z-offset macro, the machine stayed busy again.

I used to have an M501 in my Z-home macro, did the same thing there ( stayed busy ).

Hi,

I did do some more playing and it seems to happen when I use my Z offset macro.
Sometimes calling M122 resets the machine. This morning I was able to get some output.
I can't connect via USB, the controller is unresponsive using the web interface and at the PanelDue.

Config.g.txt Config-override.g.txt M122.txt Z-offset.txt