What about some knock off Bondtech gears?

I am fine with having to use the IP address for now... I am just trying to get a basic setup going so start tuning everything for my Voron 2.1 build. I will try it a bit more and post my results in a few. Thanks all for your help.

To anyone trying to do a similar setup, i got it working. When following the link that @DocTrucker provided, the command "iptables -A PREROUTING -t nat -i <ethernet_interface> -p tcp --dport 80 -j DNAT --to-destination <duet_ip>:80" is in addition to "sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE" and comes after. I have a paneldue connected and it told me the IP address that was being provided so I used that. All is working now!

Big thanks to @DocTrucker and @incogizmo !! Stay tuned for a post in a few weeks when I share my Voron 2.1

I have a voron 2.1 printer that has been working fine till this morning. I may have changed something in some config.... dont think I did but throwing it out there lol. I have 3 macros to setup Z probing. One for inductive homing fast to get a rough Z=0 and then a inductive homing slow when doing G32, bed leveling. After bed leveling x and y are homed again, and the Z probe is switched to an FSR for the nozzle to tap. All works really good until now. For some reason when using G32, both the first fast inductive home and slow inductive home at 0,0 (bed center) work fine, but something happens on the first G30 command to probe the front left of the bed. Below is the G30 sequence i use.

G30 P0 X-125 Y-125 Z-99999 H+0.00
G30 P1 X-125 Y+100 Z-99999 H+0.00
G30 P2 X+125 Y+100 Z-99999 H+0.00
G30 P3 X+125 Y-125 Z-99999 H+0.00 S4

I tried performing the steps using the console to trace where the issue is. It seems like the first line
G30 P0 X-125 Y-125 Z-99999 H+0.00

I also noticed that along the Y axis once I get close the the limits of travel, with 0,0 being bed center the Z probe trigger value hits 1000. I think this is where the Z probe already triggered is coming from but why? I checked all the wiring and all is good.

BTW using 2.03 latest. Any ideas?

Hey @dc42 , I have a Duet 2 Ethernet, latest revision with the latest firmware (issue has been observed with past versions of firmware and DWC as well) that will cause DWC/Duet 2 to disconnect every time when running a test gcode job and will not reconnect until I power cycle the Duet 2. Since I am still doing the last bit of testing/commissioning, my test gcode is of a random object with gcode generated from Cura 4.0 (also happens with Simplify3D) but since my hot end and bed heater are not connected i remove the lines that start the heaters to the required temp in a text editor and then save it, upload and run the job. About a few minutes into the test print is when the disconnect happens. I do get the error about attempting to extrude with no tool connected for almost exactly 4 minutes until I get a warning "Connection interrupted, attempting to reconnect... Request failed with status code 503". It may also be worth noting that although the board is a Duet 2 Ethernet, I do use a raspberry pi 3b to act as a bridge between a usb wireless card and the ethernet port and then to the Duet 2 Ethernet. Personally it doesn't seem like a big deal, never had the issue on my other Duet 2 Ethernet or Wifi when printing a normal print but just want to bring it up in case the underlying cause can cause issues somewhere else, for someone else. Let me know if there is any other information I can provide.

Thanks for the information. Time to re-wire lol.... i hate wiring but a good job is very satisfying.

Im building my printer and had the basics wired to check it all out, XY steppers and XY endstops. Everything worked fine but after I wired everything up in a nice wire loom/harness only the X axis homes correctly. The Y axis acts as if wherever it is at triggers the switch and sets that as the origin. My endstops are NC so when not switched the LEDs are on. I verified they work and when switched the LED goes off. Is it possible that I am getting interference or something from the stepper motors now that I have everything in a single wire loom instead of loose when testing it?

So i think it had something to do with how I was testing the printer. I created a macro that was a snippet of a full gcode file. I have been messing with it for the last hour and as soon as I let it run the macro is when I get disconnected.

I dont think that may be it. I have it setup on a static IP. This morning I gave it a try and it connected fine. Not sure what the issue was/is...

Tonight all of the sudden I lost connection with my Duet 2 Ethernet. Whenever I try to reconnect I get the red CORS Request box and then another red box that says Cannot read property of 'fanRPM' of undefined. @chrishamm any tips?

I found the culprit.... and it seems to cause RRF to glitch. It had to due with my axis min and max in the follow gcode:

M208 X-175 Y150 Z0 S1 ; Set axis min (X350/Y300/Z300)
M208 X175 Y-150 Z300 S0 ; Set axis max (X350/Y300/Z300)

You can see the my min and max Y are reversed. I noticed that when I moved the Z axis and the XY motors moved the Y coordinate would with be 150 or -150, no values in between, @dc42 could there be a checked implemented for this?

I figured out the reason my one Z was not moving the same distance as the other 3... wrong GT2 tooth count lol. If i start the printer from a fresh power up and send G92 X0 Y0 Z0 so it thinks XYZ are homed at 0,0,0 and command a Z movement both the XY motors move. Not sure if their direction is correct as I dont have my X gantry on. If from a fresh power up i send M564 H0 and move the Z axis, it moves correctly and the XY steppers do not move.

" I command Z+5 move, three of the screws move 5mm, one screw moves 2.3mm" is what happens. Its belt driven on the Z but mechanically and belt tension look ok.

I just tried using M584 H0 and then tried some moves... what do you know the XY steppers dont move. Why is that? I tried it with another config.g that is very close to what I have... mostly just format changes and it worked when entering G92 X0 Y0 Z50 and then requested movement.