Well I have no idea what's happening. I added the sub routine at the end of the code and then called it thus
Code:
Term_RX:

TempWD = 0
    HSERIN[nTest]
    SELECT CASE nTest
    CASE "S"
    TempWD = 0	
    HSERIN 1000,RX_Bombed,[DEC3 TempWD]
	normtemp[0] = TempWD   
	gosub send

    end select 
    RETURN
RX_Bombed:
gosub FlushBuffer
	LCDOUT $FE,$80
    lcdOUT $FE,$D4,"all we got was", dec TempWD
    LCDOUT $FE,$80 
return


FlushBuffer:
While PIR1.5
HSERIN [TempWd]
WEND
TempWd=0
LCDOUT $FE,1,"Buffer flushed"
RETURN
And the subroutine gets called as part of the initialization before it checks the port in the main program loop. The results when using the serial coms util in MCS were again random. I managed three changes in a row before the LCD reported 0 received. I tried the application written in LB and that too had similar results. I've also tried this application from my Son's PC and got the same result, so that would rule out my PC's port as the issue.

I've re-loaded one of the versions which included code written by DT which uses hyperterm to display data and allow variables to be changed one at a time and that functions just fine so that would suggest the coms on the EasyPIC5 board and the PIC don't have an issues.

One thing I have noticed, When I simplify the code to simply read the variable
Code:
Term_RX:
    HSERIN[nTest]
    SELECT CASE nTest
        CASE "Q" 
        gosub send
        CASE "S"
        gosub update
    End select
Return

update:

            HSERIN [DEC normtemp[0]]
            setpoints(0)=normtemp[0]
            gosub flushbuffer:

return
and send say S789 from the serial communicator the LCD changes but displays 007 as if it's picked up the 1st byte and then ignored the rest. If I change the HSERIN line by removing DEC statement the LCD displays 055 ???? - I was expecting at least 078 ???

I would welcome any further suggestions