So I could not find a bug report forum so I might as well write everything in one post instead.

So I decided to start up an prototype printer we built at work a while back but had stood unused for about 1.5-2 years and set it up for use and calibrate it.

The upgrade first failed when I tried to install the latest immediately but worked when I did the step by step upgrade as the instructions said so that was my mistake and in the end no problem.

The problems:

1. The max and min for the print volume had been reversed.
2. One of the motors directions had been reversed.
   (Those two added together to a rather unexpected behavior with the axis being driven to the defined max and min without stopping between everytime a move instruction was given. see video).
3. After I got everything working and setup the web interface suddenly complained that it couldn't save a file I was editing and when I tried to open it again it was empty so was every other file.
   When I shut down the printer and checked the card it was suddenly not readable and windows wanted to format it again.

Some other stuff:
What is the proper way to define the offset of the Probe in relation to the nozzle?
I have defined the print volume as the area that the nozzle can reach so that 0:0:0 is when the x and y endstop is triggered and the nozzle is in hight with the print bed. (furthest back and to the right).
My assumption was that if the probe offset was correctly set it would still move the print head with the previous defined limits and just do a software correction to the heightmap etc so that the height would be correct with regards to the tool position not the probe.
When I set the offset between the tool and the z-probe with G31 and run G29(and G32) the printer tries to move the probe to the right to reach 0:0 ignoring the triggered endstop and making a whole lot of noise as it was running full speed into the x- stepper.

Is this a bug or expected behavior and what is the way that corrections to probe offset should be used with the heightmap.

G32:
I think that it is a good idea and helpful with it giving information on how many turns to rotate the screws I am unsure how correct the values can be calculated without the offset set.
I would also like to be able to have it write out the z trigger heights as it did in previous versions so I can check if the values are looks to be correct.

G32 interactions with G29.
The company I work for use a removable build plate with 4 calibration points. We would of course like to use the heightmap to get the best possible result but we would like to be able to use the G32 measurement before print to do a quick check before print and to do some fine adjustments of the base plane the heightmap is applied on.
It would also be a good thing to be able to use the G32 for a confirmation that the build plate is within limits for what is considered flat and can be corrected for in print. If the build plate fails this test it would be good if an error msg was shown and the print aborted.

Best regards
Axel

The video https://photos.app.goo.gl/e78HytZowKtFqhjy9
The Z-axis is set to have a movement range between 0 and 22 mm and it is triggered ahead of time to not have it run into the print head.
In the video I tell it to go to +1 mm but each time I press +1 it moves to either 0 or 22 depending on what it was at before but it do not stop between those numbers.

P.S.
64 characters are to few for topic titles

@dc42
The drivers are set to 1500mA (12v) and while the drivers could take more I am not comfortable running the motor at much more.

I suspect the real cause of the problem is the 8mm Y transfer axel instead of the 5mm that is usually used and the Iglidur G bearings don't like the kind of transverse load that the bands put it under.
I hope to be able to replace the Iglidur with roller bearings soon as that will likely solve the problem for real.

@dc42
yeah.
That was the first I checked, all the pulleys are well attached and all belts are tight.

I suspect the problem is in the end that the Gates power grip gt belts stretches just a little bit when changing directions.
As the weight in the Y carriage is substantial and I likely have too much friction in it that I need to remove by rebuilding the gantry.
The problem is that I won't have time to do that rebuild for a while so I was looking if any solution exist that I can use in the meantime

I have run into a interesting problem where the Y axis change direction a fraction of a second later than the X axis creating ovals that have its long axis instead of being at 0° and 180°(or 90° and 270°) the long axis are on 110° and 290°, Y also have a flat area from 90 and 270 toward 110° and 290° but not before 90 and 270.

I hope that description makes sense. In reality the issue is because of friction in Y byt if any way to change the timing between Y and X exist I would be interested to know about it as I suspect knowing about something like that will be useful sooner or later and might solve this problem until I have the ability to rebuild the Y transfer.
The machine is a Cartesian and the X band is direct drive but the 2 Y bands are connected to a shared axis that is driven by motor connected to it by a band.

I have locked into the m596 and M670 but can't make heads or tails of if any of those commands could do that.

I run a duet wifi on this machine but I also have a duet 3 in an other machine.

np

Thanks that was what I wanted to know.
as the page on cabling didn't say anything on powering the duet 5v from [5v_ext] so I wanted to check before I started to run the machine for any longer time.

Maybe I should note but I am not trying to power the duet 5v from the SBC so I do still fail to see why I should connect [JP5]

I do lack the knowledge or the experience to actually read something like that but form what I can see I guess you wanted to point out something like this:

So the [SBC -> 5v] are catastrophically mislabeled?
and it is allot better to just use the internal 5v?

Correct?

When I got the card it had [5v->SBC] and [int_5v] jumped.
having both [5v->SBC] and [SBC -> 5v] jumped at the same time seems counterproductive?
or is SBC in those cases actually referring to the [ext_5v +5V] pin?

It seem to work as it should with the SBC when I only have the [SBC -> 5v] jumped.

The way I understand it from the documentation is that the [5v->SBC] and [SBC -> 5v] change if the 5v pin on the flat cable is an output or an input pin?

If I want the duet to receive 5v power from the PSU and to power the SMC, would it be correct to leave [5V->SBC] jumped but not the other 2?

I also wonder if it exist any specific reason why it would be better to use the internal 5V or power the 5V with the [ext_5v +5V] pin?

It makes it easier for me to wire in a on/off switch on the [+5 V standby] cable and then control the rest of the PSU with M80/M81 commands

Thank you for all the help.

Turning the fans off works as you said with noctua fans.

But turning of out4-out6 even when set to work as regular fans don't seem to work though.

Edit:
I thought I got some odd values on the tachometer as I use rather long cables but apparently noctuas 40mm fans are supposed to go at 5000 rpm

Thanks.

Any idea if it might be possible to shut down the power to/from the fan it they are form a maker that don't shut them down completely or if someone have to use the out and gnd pins of the 4 pin connections to control "regular" fans?