Issue Found!
Turns out the copy instruction is native to windows and not the program itself. The documentation doesn't make it very clear that this instruction line shouldn't be prepend with 'bmp2c.exe'. Or it could just be me a bit slow on the uptake.
anyway, all sorted!
prelude: I wont get into the whole moral dilemma of if you should buy a clone vs OEM, as that frankly, is up to you, and I don't think people should be telling others how to spend their money.
Abstract: FYSETC make ok products, some stuff they do better (in my opinion) such as the integrated screens, and others they do okay with like the logic boards. They are not to the same high standard as Duet is, however functionally, they are able to provide the same experience, and have been reliable in doing so.
Quality: The main difference when it comes to FYSETC parts vs Duet other than the substituted components (probably due to local supply differences) is that the FYSETC duets tend to be a bit weaker overall. They are more susceptible to EMI and as such the webOS tends to get negatively affected more often than a true Duet would.
Accelerometer support also backs up this as the official duets can cope will full speed data capture, however the FYSETC needs to be turned down to half speed in order for an uncorrupted data stream. This is still more than acceptable resolution, however it does show some of the differences caused by the design differences
Wire interferences is also slightly more noticeable with the FYSETC boards. For reference, I use a 7" PanelDue and a 7" FYSETC integrated panel across multiple machines. Both have the same behaviour independently. However, with the FYSETC Duet boards, the screens are more suseptable to the EMI the machine produces, and it has shown up a couple of times, where the data lines suddenly produce garbled commands, which show up on the screens as bad json commands.
With that being said, both official Duet boards, and FYSETC share this issue, however FYSETC appear to have a interference rate 5x higher than that of the official Duet boards.
Panel Due:
Its kind of sad to say, but FYSETC make a much nicer touch screen. They have integrated the breakout board into their screens, and overall has made the PCB footprint smaller. You do loose the speaker for this, however for that size reduction, I have to admit that I prefer the FYSETC 7i screens, and they also support all the new PanelDue firmware.
Updating:
This is the only major difference I have seen between official Duet products and the FYSETC clones. When updating the firmware to new versions, the FYSETC boards don't tend to consistently update. The boards will download the files fine, and install them, however the firmware will not update after that - almost like it backdated the version to the one already present on the board. This isn't a massive issue as you can just upload it manually instead of through the WebOS, but it is a noticeable difference, as official Duet boards only rarely have this issue.
Conclusion:
FYSETC is fully functional as a board manufacturer, even if the quality is slightly lacking, the products do tend to work fit for purpose.
They make some really nice screens, and their logicboards - while not 100% clones - do act like official duets, except for some behaviour changes, where I think the corners have been cut for cost, means they are more susceptible to EMI/EMF.
@Phaedrux Hit the nail on the head. It looks like Cura has reset all my printer profiles to marlin instead of RRF.
How embarrasing!
@dc42 weirdly enough, just starting a print.
Im currently using Cura 5.3 with a newly updated RRF plugin (1.2.9) the behaviour seems consistent between sending via cura or uploading Gcode directly (sliced in cura)
@dc42 Sorry I should have clarified. The line of text is visible inside the DWC and PanelDue screen consoles.
From what you have said it looks like its something I don't need to worry about thankfully.
Bit of a weird one. every now and again i get the following console response:
T:220.4 /220.0 T0:220.4 /220.0 B:68.0 /68.0
No idea where to even start looking at to diagnose the cause. I feel like T and T0 are the tool heads, and B is the bed heater. as that would make sense as 68 is what I had the bed set to and the nozzle to 220.
Is this anything I should be worried about?
@dc42
Thanks for the response, unfortunately it doesn't seem to have worked, but It could be how I am inputting the site data to the console. The following picture is all the combinations I have tried.
How does this look?
I also tried this: 
But it also hasn't worked.
Its annoying because it feels so close to getting it working but not close enough for it to actually work.
Bit of further digging, It looks like when I turn the Iframe option off I get this warning instead
Bit of further digging, Using the f12 dev tools. I have a single error relating to the webcam component:
Refused to display 'http://192.168.1.51/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
Unfortunately I am not savvy enough to know how to fix this, but it does seem like a clue
@Phaedrux
Just doubled checked, The machine was running 3.4.0 - I have now updated it to 3.4.5 however the behaviour is identical.
Hi, the version is 3.4.5, Tho on a single machine we have is DWC 3.4.0 - I havent checked which machine DWC I was trying to update the webcam for.
Also I just realised the G-Code directory button when you open .g files links to the dozuki page and not the new docs page. Is there a way for me to change this as clicking the button sends to a de-activeated webpage.
