@oliof Hello,
Background story: I was trying to translate the error status bit which the board has reported back. I looked at the data sheet to figure out what the error corresponds to is and got confused.
As i attached the image of datasheet and the duet event table above, Tried to compare the values that i got back and computed the binary for it but the value was bit different.

the binary of 192 is 1100 0000 , but according to data sheet it is 96: 0110 0000 if we take the 8 bits from MSB 31 to 24.
Conclusion : The above mentioned discrepancy made me look into the RRF in the section CANlib/src/RRF3common.h -> union StandardDriverStatus , it is calculated differently. And it make sense now why the value was 192.
But can be a problem if someone wants to translate the error status bits to the proper error message. Thank you for your time.

Hello,
Can you please help me understanding how the error status bits are output when there is a driver warning or error based on the trinamic driver datasheet ?
.

I cannot really understand the values. For example 26th bit is high means Overtemp pre warning flag. What would be the output status from Duet?.

@dc42 Thank you , I will check it out

@dc42 It seems to be working. I have tried all the above conditions and works as intended. Can i expect the same fix for Duet3 6HC board as well, as i observed the same behavior in it as well. Thank you

@dc42 I have tried beta2 and same error happened. I think you are already working on it. I have another topic on multiple motion system active now. Thank you .

@dc42 Thank you

@Alva Looks like it is a timing problem or something.

@Alva

@dc42 I have edited the code and logic a bit. Found different cases:

; File Name: 		/sys/daemon.g
if(!exists(global.daemonStop))
	global daemonStop = false	; Set to 1 to stop the daemon.g, it can be use to upload a new daemon.g file

while( global.daemonStop == false )
    if(state.status== "processing")
        G91
        M596 P1
        G1 U5 F300      
        M596
    G4 P0
M99; Exit

test_2nd_MS.gcode
.
This happened when i activated the daemon before the move to X0 Y0. But if i activate the daemon after that then it works perfectly. Cannot relate whats going on.

set global.daemonStop = true ; stopped the daemon
M118 S{"starting to move"}
G90
G1 X0 Y0
M400 S1
G91
set global.daemonStop = false ; activated the daemon which only use U axis
G1 X100 Y100 F200
M400 S1
G90
M118 S{"move done"}
M99

@Alva Looks like there was a mistake in the 3.6.0.beta2 release and David updated the new one today. I will try out that one.