OK SO!!!
For anyone else trying.... almost every guide is completely wrong when it comes to access for the camera... You have to turn OFF the remote access settings... if you turn them ON then the Motion Service actually restricts... turning them OFF allows them to be seen remotely, and for whatever reason, even though it is being ran ON THE SAME PI AS DUET... it sees it as a remote computer and thus blocks access...
For a quick update, this doesn't seem to work. It loads a link into the 'webcam' section
I've tried following multiple guides on how to get the system running, but it will not allow a computer to connect to it to view the images, nor does it allow 'itself' to see the images. If you click the link, it just simply reloads the Duet Interface.
I'm going to try and see if changing the default ports on it solves this. As maybe that port is already in use by the Duet Interface.
@Phaedrux Is this capable of being ran on the same Pi that's controlling the 6HC? 
if so, then I think this is exactly what I was looking for then.
So I know the original Duets (Not the 6HC) did not natively support physically attaching a webcam. In order to utilize a webcam, you had to use a Raspberry Pi or some other hardware, and use an embedded jpeg stream...
After playing around with my new 6HC with a Raspberry Pi attached, I couldn't find any 'webcam' settings. Has this functionality been removed?
Now with the prelude of that out of the way, my bigger question is:
Is there any way to directly integrate the camera into the Web Interface? I mean... The Pi IS the Web Interface now... And the Pi already has FULL WebCam functionality via the Camera Ribbon Cable Connection, or via USB.
Am I just blind and missing something in the settings? Is my Google-Fu not strong enough to actually find the info I'm looking for?
Any info on this would be highly appreciated 
If this is not currently a part of the SBC interface solution, may I ask why it has not been implemented yet? Its fully possible to do, so if it isn't, why hasn't it been?
Also, I'm not sure if this post should be here, or in the Web Interface Catagory. I figured here at first because I'm looking for info on connecting a piece of hardware (A Camera) to the Duet System to have an All-In-One solution, without having to set up yet another pi to use the Motion Eye system as a 'WebCam' solution..
@Phaedrux That it will Thankfully there are forums and wiki's to help people
Just kinda bumping basically to keep this abit alive...
But also to point out, that this should probably be somewhere in the documentation for how to set up the board. There is only a mention of "you should put ! infront of the pin name to invert", but for people who have never used this board before, that means nothing to them..
I had spent nearly 3-4 hours trying to get my Z-Probe to work again since all the typical things I know of that worked on my Duet Wifi, does not work on this board at all. Having seen "you need to put ! infront of the pin name" meant nothing to me. I had no clue what I was supposed to be putting the ! infront of. It wasn't until a completely unrelated search that magically brought this thread up, that I saw an actual example of what people keep talking about. So thank you Phaedrux! I would still be destroying my hair for the next few hours if you hadn't posted an actual example of the code, instead of just simply saying "Put an ! at the front" like everyone else
Yes I've read the other threads.
I can't get the Duet Wifi to work via the internet. I don't see any sort of port that the Duet Wifi itself is using, thus can't forward anything to it... If I just give it an unused port in the router, then it just says there's no connection.
YES I know its not the most secure. I DO NOT CARE. Printer is located in an area where if it were to catch fire, oh well. A foot of solid concrete in every direction does not, and will not, burn.
I NEED access, because lately the printer has been skipping steps randomly, and I have several things I need to get printed in the coming weeks as I wait for possible new motors to come in. Nothing about the printer has changed but the motors appear to have slop. so while i'm waiting for shipping, I'd MUCH rather be able to just remote into the printer when at work, check the camera feed to see if its still printing properly, and if not, tell it to turn off.
I do not care if it is a vulnerability for MY network. It is my network, not yours, so please let me worry about that. The port is only going to be active when I'm AWAY from home, not 24/7. Have a lovely script for that.
So if anyone can be kind enough to give a legitimate answer to how this is accomplished without going "use a vpn" or "don't do it its not secure", I'd greatly appreciate it...
Well here's the results lol.
The blue pieces in a 'square' are made with eSUN PETG as a fast test. First print with both X and Y gantries replaced with linear guides/rails (whatever people wanna call em). So now aka Janky v4
The clear/white is Solutech PETG with the carbon fiber tubes on both X and Y gantries..... noticeable improvement... holy crap... This is basically Janky v3
The gray pieces connected together are made with Hatchbox "Silver" PETG and have been significantly 'post processed' with razors and such. Done on what was Janky v2
And finally the blue pieces connected together were made on the very first version of Janky, which was holy crap terrible... but hey, it worked! Used the completely wrong settings for EVERYTHING... 0.4mm nozzle with 0.4mm layer height, 135% layer width, yadda yadda, complete garbage.
They were printed with Hatchbox ABS, and had the least 'post processing' of anything ironically. They just snapped together, and with alittle silicone lube, work perfectly fine. They have a slight 'uphill' travel to them but hey, they work!
Anyway, this was basically just to showcase that linear guides/rails are hands down just worth the money... 23 bucks for two carbon fiber tubes, or 23 bucks for a linear guide/rail... I'll now take that rail any day... so much easier to model parts for, so much easier to work with, so much easier in actual use....
Also, as a side note:
The test print wasn't entirely successful, hence the terrible look. The extruder kept jamming every couple of minutes, so the gaps/uneven looking shells are attributed to that... Idk why it jams so much now. All I did from v2 to v3/4 was move it from one z post to the other so that the filament was easier to reach lol.
!
@phaedrux That's my next build. I'm trying to get this one to print 'properly' and square, so that I can print out parts for a CoreXY using aluminum extrusion... Using hand cut pieces of wood for 4 years only gets ya so far... Really want to get some 'precision' going on.. so for now I gotta hope this thing works, print out as good as parts as I can, and 'pray' they all fit with the extrusion... only have this as a printer, so once i start taking it apart, there's no easy way to go back and reprint things that aren't right x-x
Yup... moving properly now.
This is why this forum is awesome. People always know what to do, even when its something super complicated, just as well when its something stupidly obvious but just slips the mind.
@phaedrux You said that, and I went to look, and instantly slammed my head onto the desk... its set up so that the Y goes -500, so even if it is 'homing' to the proper side, its thinking its moving backwards and magically hit a high switch... lemme flip that around and see if that fixes it...
I knew in my head that i should also be flipping the motor direction, but when i did it didn't move the direction it was supposed to, so now I know why it was doing that. One sec!
Ok this is another weird thing for me lol.
I just fixed some bunked components of the printer... I had originally been using 8mm linear rods (hardened steel) but they were 200mm and i wanted to make the printer larger. Having watched tons of videos and blogs and the like, I settled on switching everything over to 500mm carbon fiber tubes because "everyone was having such amazing success with them"... well, my experience so far has been nothing but good... so much vibration and warped tubing that prints actually have been coming out worse than my first original design for the printer when the z axis wobbled a good 3-5mm during its moves...
Anyway, I've swapped out those disgusting carbon fiber tubes with linear guides (mgn12h) and things have been 'somewhat' better.
I say somewhat, because I goofed and made the belt area for the X gantry alittle too far out, and so it can't fit the normal way against the boards... SO I just flipped it, and turned the whole printer 180 degrees so the back is now the 'front'. Since normally you'd just go into the firmware and go "well now the Y endstop is the high point instead of low" and things just work, I went into the firmware, set the M574 command to reflect X1 Y2 (to set it high) Z0 S0.
The problem is, it will home just fine. And it lists the homed Y location as being what it should be, 250. BUT when it goes to move to 100 to home the Z axis, it moves the wrong direction............ It tries to continue going towards the 'high' direction instead of the low.... If i flip the motor direction, it obviously begins homing towards what is now the "low" direction...
This doesn't make any sense to me... because if it knows that Y is at the max, and that to get to the max you need to be going the direction that it is moving in, why does it think it needs to continue going that direction to get low?
I mean like... gah my brain doesn't know how to word it properly right now...
Like, it knows that it needs to move in that direction and that when it hits an endstop, then its at the max it can go. So why then would it continue to go in that direction, knowing full well that it CAN'T go any further in that direction? Why does it think that MAX's direction will make it go LOW?
my config for the drives/endstops:
; Endstops
M581 E1 S1 T1 C0
M574 X1 Y2 Z0 S0 ; Define active low and unused microswitches
;M574 Z1 E1 S1 ; Define active high Z axis switch
M558 P4 X0 Y0 Z1 H3 F120 T6000 I1 ; Set Z probe type to switch, the axes for which it is used and the probe + travel speeds
G31 P500 X-44 Y5 Z0.85; Set Z probe trigger value, offset and trigger height
M557 X15:264 Y5:185 S45 ; Define mesh grid
; Drives
M569 P0 S0 ; Drive X goes backwards
M569 P1 S0 ; Drive Y goes backwards
M569 P2 S0 ; Drive Z goes backwards
M569 P3 S0 ; Drive 3 goes backwards
Lol this is probably a dead one, but this sounds almost EXACTLY the same issue I had been having with my printer when I finally bought a Duet WiFi and tried to get my bed probe working. When It would home/level, and I did the paper trick, everything looked perfectly fine. But when I would start a print, the nozzle would be anywhere between 0.3 to 3mm above the bed and sometimes below... scratched a freshly installed aluminum plate that day...
Anyway, I posted on here about it, and everyone suggested that it was because I didn't actually have the bed leveling action dictating the final Z height. As in, after it homed Z using the probe, it didn't actually 'save' the detected height. And so when it went to level the bed, it didn't have the proper height saved to begin with, and thus all the leveling showed my bed was 1-3mm below/above the expected Z0. Thus when it started a print, it'd float up in the air/dig into the bed...
I forget what the actual code is, and I'm not near the printer atm to be able to look at my configs, but I know there was some GCODE I had to implement after homing and after probing, that dc42 had told me to add if I remember correctly. It basically forced the Z Position to set based on whatever the sensor detected. Since then I've had nothing but amazing first layers print after print. Only issues I've had is when the extruder borks up and I gotta clear the ptfe tube...
Try the following:
1. Upload Duet2CombinedFirmware.bin through Settings->General in DWC.
2. In DWC go to System Editor and delete the old DuetWiFiFirmware.bin file.
3. Rename Duet2CombinedFirmware.bin to DuetWiFiFirmware.bin.
4. Send M997.
I'll give this a shot once the current print is over. (in about 15 hours x-x). Currently in the process of overhauling the printer with new parts in a slightly more stable design, so trying to utilize all the time I've got when I'm at work and sleeping.
Well tried to update, but it won't go to RC4 lol. Just says that the upload contained an update and when I click yes, does the 'update' and kicks me out, then when logged back in, still at RC3 XD
USB just states that comwrite errors have occurred and/or that the device didn't recognize the command
Doesn't update via USB for me either. Just does the disconnect sound, says that it could not read from printer, then can not write to printer, then that the device did not recognize the command (M997, M997 S0/S1).
Just stays stuck at RC3 lol
Ah! That could very well be it. I use the desktop to monitor it with a tiny screen to the side, but use my S8+ with it when I'm physically at the printer (in a different room, and a desktop is kinda heavy to lug around XD ).
Welp! I tried to update from RC3 to RC4, and it detects that its a firmware upgrade, goes through the process, but when it 'restarts' it just states that there was an invalid password, in which once the password is entered, the 'firmware version' is still at RC3 
No not consistently. The heaters staying on does, but the other things not so much. Every now and then it'll shut off things properly, but only has happened maybe 4 out of 10 prints since bringing the printer back to life sadly… I'm about to read through the RC4 update, and then upgrade to that if fitting, and see if things work.
EDIT:
Nvm, I missread the title lol. that's for paneldue not duet XD
AND EDIT:
Ok, my eyes must be tired today.... First I coulda sworn that it said new firmware for duet, then I see its for paneldue, and now I saw one for the duet again XD Sorry XD
The showing heightmap thing just started with this print. It wouldn't shut off heaters again, so I figured I'd take a look at the console. When I manually type in ANY command, even selecting the 'M0' command, it brings up the heightmap.
I thought it was weird one print when I went back to the computer and noticed the heightmap was open. I thought maybe someone had just hit a button. So this would make twice out of 10 prints for me. As a note, it did it both times when there were random notifications popping up everywhere after every command as well. when you do an 'emergency stop' the issues go away but then come back a print or two later.
Also as a weird note… if i manually put in M104/M140... it actually brings up the heightmap for some reason.