@phaedrux Thanks for the link Phaedrux. Just ordered some myself.
Judging from the images you've posted, even if they're "fake Gates" they look pretty good quality.
Also, an fyi for everyone/anyone - i've gone and edited the reprap wiki page on choosing belts to include a wee warning about steel core polyurethane belts and small pulley diameters for others to find.
Link here: https://reprap.org/wiki/Choosing_Belts_and_Pulleys
@plasticmetal had I seen that advice before I might have been able to avoid this whole thing!
I suspect that’s what has happened, pulling the belt apart in my hands it snapped pretty easily at the point where it was engaging with the pulley while the rest of it was still pretty solid.
I had some spare rubber belts so I’ve gone back to those and all seems to work well again.
Thanks for you help guys, we have a winner!
My new tough metal core belt turns out to be not so tough and must have softened (probably from friction/heat) at some point and has actually stretched in the area over the toothed pulley.
I checked the movement as @T3P3Tony suggested and it was elongated near the centre of the bed's Y axis but not towards the edges. After @hurzhurz mentioned his issue with his Anet belts I then went and checked the belt and found this:
You can actually see where the rubber has stretched and increased distance between the belt's teeth!
Thanks again for everyone's help - turned out to not be a duet related issue at all but you guys got me looking in the right place.
Looks like my post last night didn't go through before the forum went down for a bit?
Anyway I tried another print after changing the steps per mm in the Y from 100 to 100/104 (~96) and got a perfect 100x100mm test print - I suppose that's a working solution.
@hurzhurz I did change my belts to a metal core GT2 a few weeks ago but have done maybe a dozen prints without issue and the heated bed was actually off for the print when things went wrong (since I'd never get the TPU print off of my PEI if it was on!) - but that's a good place for me to check. I did notice a bit of dirt on the belt where it engages with the pulley (it's a white belt so it's easy to spot) so who knows, maybe the teeth on the belt have slipped?!
In the office atm so i'll check again tonight.
Thanks for everyone's input so far.
Alright first calibration print done.
Ignore the horrible over extrusion on the lower layers!
100x100mm square came out as
100.00mm in the X and 104.02mm in the Y which roughly matches up with the measurements I took of the wheels.
XAxis
YAxis
I'm going to clean the printer up a bit and try Prusa's Slic3r (prints so far have been sliced with Cura) to rule that out as well.
Edit (23:04): Same result with Slic3r (although it did a much better job with flow control on the bottom layer solid infills) 100X by 104Y mm.
@t3p3tony cheers for the response - Yeah I should have probably mention that I do have a cartesian setup (P3SteelXL, basically a very heavy Prusa i3) finally got the kids to bed so I'm going to try some calibration prints. Not seeing M556 or M92 in the code file itself and steps/mm for both X/Y are the same value of 100 for M92 in the config.g (GT2 Belts, 16 tooth pulleys, 1.8 degree motors and the default 16 microstep)
I've taken some calliper measurements of the tyres since I realised I didn't actually know how elongated in the YAxis the model became.
I'll let you know how my calibration prints come out!
@dc42 The correct size is the lower part (circular) rather then the upper part (oval) which is why I'm confused by the issue - every mechanical issue I've had in the past, like loose belts has resulted in smaller prints or shifted prints, not consistently larger (in one axis)?
I have checked the belts though and they're pretty tight - will try run some test prints tonight.
@Catalin_RO Did you start responded in the wrong post?
I was printing a TPU Tyre for an OpenRC build and suddenly it started printing longer in the Y Axis. I let it finish as at the time it looked like a minor layer shift but it actually started printing very consistently larger and slightly offset in the Y axis.
After checking the mechanics over I have it another shot only to find the 2nd wheel was entirely longer in the Y axis with no signs of layer shifting!
I figure if it was just layer shifting or slipping belts then it should actually shift in one direction and/or get smaller, not longer? But this seems to be a very consistent increase of about 2-3% size in the Y Axis alone. So now I’m wondering if it’s a possible software or electronics issue.
I’ll keep looking for mechanical faults as I still think it’s most likely that but has anyone experienced something like this before?
Using a DuetWifi on firmware 1.21
I've added some pictures for reference
M501 /facepalm.
Yeah that was missing, and had it been there this whole time the OP issue wouldn't have happened 
Massive thanks, pid tuned values loading up from config-override.g correctly now and both H0 and H1 have voltage values in there now as well!
Thanks for the follow up. I’ve run tuning again for the hotend and M307 H1 is showing a value for V now (24.2) - presumably that’ll improve things even further after ensuring the bed was running with pwm?
And I guess M307 H0 being ignored in the config override must be potential a bug?
@dc42 M307 H1 shows 0 for the V parameter, while M307 H0 shows 23.7 (it sits at about 24.2 when the bed is off based on the machine status).
Is that an issue?
That looks like it’s done the trick, thanks!
Left cylinder printed with default bang bang for the heated bed and then with the Pid tuned values for M307 (and voltage compensation) on the right 
@dc42 said in Print becomes thinner when the heated bed is on:
M307
Thanks for the info! I strongly suspect you're right and I'm printing a cylinder just now to make sure (I can already see the bed led flickering away instead of going on and off in longer intervals)
However, when I ran M307 H0 to check the bed mode it came up with default values, which I thought was odd because I had definitely ran pid tuning on the bed and used M500 to save the results. So I checked config-override.g and could see the M307 values the pid tuning had spat out (including a voltage change value).
M307 H1 brought up the hotted values in the override correctly but M307 H0 didn't bring up the bed?
I've worked around this by copying the M307 H0 values into my config.g proper and that seems to work (calling M307 H0 now brings up the saved values).
That's not intended behaviour is it?
I have a pretty odd issue that I initially thought was z wobble and then potentially current being induced by close cables when the heated bed turns on, but I'm not so sure.
I'm getting a very consistent change in print whenever the heated bed turns on - this seems to manifest as the print becoming slightly thinner while the bed is on. Over time this looks like very slight horizontal ripples in the print.
I don't think it's z wobble as I can see it happen as the heated bed turns on and when printing a cylinder the radius reduces pretty uniformly rather than shifting in one direction. I don't think it's induction through the heat bed cable because I've separated the cables as much as possible and it's still happening. Leaving the heated bed off eliminates the issue entirely.
Any ideas?
I'm on a Duet Wifi firmware 1.20 with a CoreXY setup and 24V electronics - the heated bed is connected directly to the Duet.
I know I've got an un-level bed…but this just looks hella extreme
Any reasonable way to change the scale?
M555 P2 (which I figured out you meant) seems to do the trick with M204 S commands, cheers!
Are there any caveats we should be aware of when putting it into Marlin mode?
OK I've had a chance to test this out now.
Attempting to print a bench from Slic3r outputting M204 S commands is giving me buttloads of:
Maximum printing acceleration 1000.0, maximum travel acceleration 10000.0
However, replacing all of those M204 S commands with M204 P instead makes the messages go away.
My accelerations are set to (CoreXY rig):
[[language gcode]]
M201 X2000 Y2000 Z250 E10000
Edit:
Tested with M204 T now as well and the messages don't appear.
RRF v 1.20
Ooh, that's interesting then. I came across this because of the acceleration message spam I was getting which I came to the conclusion might have been caused by the S parameter on the M204's but I'm pretty certain I'm on 1.20 (since I'm using senseless endstops).
I'll have a poke about then when I get home and see if it's not something daft I'm doing on my end.
@dc42 perfect! I've sent a message to the Prusa guys anyway as they might want to support the more up to date version for the command.