Well, no error messages or codes, it just kinda decided to run bed leveling starting from away from the endstop and moving toward it. After it scaring me twice, I reset the x probe area to 200 and let it run and it works fine.
My map comes up with the axis indicator(those xyz lines that form a partial box) on the right now instead of the left, kinda confusing at first but it works so I must adapt.
And I did get a perfect first layer so it's definitely functioning right.
I'll mark this as answered because it does work.

I've had my printer going for a while now, but just upgraded to direct drive. I had to change my z offset with the new mount, and when I try to g29(with a fully functional Bltouch), it will probe for home then goes all the way to the other side of the print bed. It never did this before, is this normal?

Here's my g29 macro:
G28
G91
G1 Z4 F300
G90
M98 Pdeployprobe.g
M557 X1:220 Y0:160 S20
G29
M98 Pretractprobe.g
G1 X25 Y0 Z20 F5000

does this look wrong? I'm at a loss here.

I'm by no means tech savvy, but I couldn't get a webcam to work by reading any instructions. but this worked.

I entered the webcam's IP, hit apply settings, it said something like image not available on the print status page. I right clicked on it, and opened image in new tab. then I found the webcam feed(turns out I had a password prompt in the way of the stream), and I right clicked on it, copy image address, and pasted that in the webcam IP box. Worked great.

Maybe that is written somewhere and I missed it, or maybe that's just common knowledge and I'm way behind on the learning curve, but either way, I feel it doesn't hurt to share it here.

@HikariNoKitsune:

So basically, something that is usually seen relatively easy to accomplish, is seen as too hard to maintain for the Duet? With the sheer amount of support there is out there for all these other displays that are out here in the wild, most notably the "Reprap Discount Full Graphic Smart Controller", it is abit mind blowing to hear someone state that it is difficult to not just add, but 'maintain' something that seemingly wouldn't ever need to be changed, and thus maintaining would something to not even really worry about.

The only issue I can see would be that since it isn't arduino based like a RAMPS, it obviously wouldn't be the same 'menu' and 'layout' as something like the Marlin firmware. Thus the layout and menu would need to be created. But, again, that seems insanely simple to do considering there is already a pretty amazing web interface that already has all the variables and such, not to mention the already existing code to interact with the PanelDue. Granted, I believe the PanelDue is kind of its own separate system in itself and is merely just being fed values and then spitting out gcode back to the Duet. So all the infrastructure to enable support for these other screens appears to be pretty straight forward, with the only other reason for not including support for them being to keep the ecosystem of components closed off to drive up sales of those components… That, or the hardware itself is designed in such a way that other displays couldn't be used, but then that thought gets tossed aside because the same exact pins that are used to connect to an 'external SD card' on the back of a screen, can be used for running a TFT28 or similar screen, or even the Full Graphic Smart Controller....

So it seems more of a 'We just don't want to do it' and not a 'its too much for us to do' when the board itself is basically finished and the firmware working near flawlessly.

It is all open source, so you can implement it yourself if you want.

It would need to be changed as new features are continually added though.

The pins can be configured in almost anyway you can imagine, so I don't think pinout would be an issue.

The board has a 3.3v logic, which might be an issue.

They are rather busy perfecting the firmware, which is always being improved and new features added. But it is a wifi board, so you can control it on any computer, tablet, or smart phone. That kinda pushes it's necessity further down the priority list.

But I do feel that it is inappropriate to imply greed a a motivating factor for not having the time to write the support. They work very hard to develop the most advanced and most versatile board on the market today. Please check out the firmware wishlist to get an idea of the types of features they are constantly adding.

I got the 1.15 web control installed, and it seems to hold a more stable connection now, because I was having problems with that before.

I tried the reset from emergency stop function. I hit emergency stop, a screen prompted me if I would ike to reboot, I said yes, and it disconnected from the web interface, then it asked me again if I would like to reboot. I am still running 1.17e firmware, that might have something to do with it, but I figured I'd note it.

Thanks everyone for all the hard work!

This may be a stupid question, but is there any way to get my chrome account to auto log in to the web interface?
Or at least have chrome recognize the web interface password prompt for auto-fill?
Thank you for this, and all your efforts, I will try it as soon as I'm done printing.

@dc42:

It sounds to me that the wifi module lost the connection to your router. I have a major rework of the wifi code planned, which will include automatic reconnect.

Sending M552 S0 followed by M552 S1 from either USB or PanelDue may get the connection working again without interrupting the print.

Update: I am having a lotof issues connecting to the web interface now. m552 reset proceedure not helping. Printer connects to the server easily, but web interface will not.

https://youtu.be/ZmujcBFAkEo

Should I reinstall the web interface firmware? It doesn't seem to be a hardware issue. Any settings I can change?

I did try closing and opening google chrome and deleting cookies n cache

@Sasha:

I think I may have found the source of the problem. While I had the web interface working I did home the axes. This left my Z endstop triggered which is pulling V to GND constantly it looks like. I'll have to fix this in the morning.

I am able to communicate if I disconnect the Z endstop. I may have to re-design my endstops to use all 3 pins? Or maybe I just have them configured wrong…

EDIT: I just saw your post. Yes, it does look like the same issue.

I had to re arrange the pins on my endstop to fix it. Mine are the "dumb" 2 wire endstops, and I connected the wires on the outside, leaving the middle blank. The polarity on it doesn't matter. 3 wire endstops are a little more confusing though.

edit: I can't spell

@Sasha:

Additionally, the 3.3V LED is not on. If the 3V3 rail is bad, that would explain why I can't communicate to it at all. Is there a way to repair this? I still don't even know how this could have happened, I never connected/disconnected anything.

You can try unplugging your endstops, see if that helps. My board did that because I wired it wrong, and it was sending 3.3v to ground, and messing up my entire day.

@minsk:

errr….so what part of the code do i tell the config.g the size of the bed is 500mm x 500 mm

set axis minimum x0 y0

set axis maximum x500 y500

Then do that for bed.g, I think(don't have mine on right now.

If your home location is outside the print bed, you set it as a minus.
for example, my x homes 25mm past where I can print, so set axis minimum x-25
That way g code still prints starting at zero, when it's really 25mm past home.