What is the resolution of llSetRot()?

Am I doing something wrong? Despite using float values with all the precision in the world I can only get a rotational positioning to about the nearst 6 degrees. How do I set an object to points in between?

The resolution may be dependant on the conversion from Quaternion to Euler and back again.
I remember reading somewhere that a call to llSetRot would take the quaternion and convert it to Euler to set the rotation of the object which is then stored in Quaternion (makes no sense to me, I hope to be corrected).

Although there are bounds on the precision both of the FP representation and of any conversions or calculations the script uses, it should take a fortnight of calculations to accumulate a 6 degree error range. Something else must be happening, but to figure out what, probably need to see a bit of code.

Good call Qie.
As Qie mentioned it could be something in the script, how about posting the script or any parts associated with the llSetRot and maths for the values passed to it. I won't get a chance to get in-world to experiment with the function for a while.

OK here is a simplified code extracted from the script that will demonstrate the 6 degree limit on display resolution.

OR YOU CAN SEE IT ALREADY SET UP AT http://slurl.com/secondlife/Whanganui/226/232/39

Make a dummy object and lengthen the y direction so you can see rotation angle.
Insert the script, save and touch.
The program is set to use 50 rotation increments of PI/100 for a total of PI/2.
However the llSetRot()s have no effect until about 6 degrees are accumulated and then the object moves. I'm sure the internal resolution is good but the display is going to the nearst 6 degree (approx) increment.

integer DOOR_OPEN;    //Door status - OPEN if TRUE
integer DOOR_NORMAL; //Door swing one way/opposite way
rotation DoorRot;
vector DoorPos;     // door position (objects move a tiny amount
                        // away from their position each time they are rotated,
                        // thus we need to workaround this by resetting
                        // the position after rotating)
swingDoor()      

{
    rotation rot;
    rotation delta;
    float pival= PI/100; //Set for High Resolution
    if (DOOR_OPEN==TRUE) pival = -pival;
    if (DOOR_NORMAL==TRUE) pival = -pival;
    rot=llGetRot();
    delta=llEuler2Rot(<pival,0,0>);
    integer i;
    for (i=1;i<=50;i++){  //Try for 50 small steps
        rot=delta*rot;
        llSetRot(rot);
        llSleep(0.25);
    }
    DOOR_OPEN= !DOOR_OPEN;
    if (DOOR_OPEN==TRUE){
        llSetTimerEvent(10.0); //to shut in 10 seconds
    }
    else {
        llSetTimerEvent(0.0);
        llSetPos(DoorPos);
        llSetRot(DoorRot);
    }
}

default
{
    state_entry()
    {
        DoorRot = llGetRot();
        DoorPos = llGetPos();
    }

    touch_start(integer total_number)
    {
        swingDoor();
    }
    
    timer(){
        if(DOOR_OPEN=TRUE) swingDoor();
    }    
}

Actually, the problem is not floating point errors, but a limitation in the viewer.

Any rotation less than ~6 degrees does not generate an update to be sent to the viewer. The object DOES get rotated in the sim, but viewers won't get updated until the rotation exceeds the update threshold.

Sadly, yes. I suppose that's to cut down on lag so it's a good thing! If you have the object selected in Edit while it's turning you can see that it's indeed turning the smaller increments.

In Edit I see it turning 1.8 degrees per step, which is correct, 90 / 50 = 1.8

As Talarus says.

I recently had a similar situation with a head-turning script on a model giraffe!

See this extract from the llSetRot() Wiki page at http://wiki.secondlife.com/wiki/LlSetRot