Kavya is correct.
Of course the ideal solution is that you eliminate the polls altogether and allow your device to send a 'response' which was never polled for. If your central XBee (on the PC) is in API mode, then your PC application merely gathers all the incoming data, using the Xbee addressing to know which sensor sent the data. Your PC would also maintain a timer (some sense of time) to detect when sensors have NOT reported in as required. For example, I have tank level sensors which report in only once per hour (or day). It would be impossible to do what you do - attempt to 'pre-poll' for 24 hours expecting 99.99% poll failure.
To use the IR value, you set IR to 0xFFFF (max value) plus make sure at least 1 of the digital pins is in mode 3-5 (such as DIO3). This causes the sleeping device to send upon waking an IS message to the DH/DL destination (if 0/0, is the coordinator). Then ST must be high/long enough to allow your PC time to detect the message and issue its poll. Start with 5 seconds, but you might be able to lower this after success.
However, your battery life will suffer greatly in this design because:
1) you are sending a useless message (TX takes power)
2) the PC might not always reply fast enough, meaning a percentage of your samples are lost anyway.
3) this solution scales VERY badly, so what works with 1 sensor might not work with 10, and what works with 10 might not work with 50.
4) the XBee+device remains awake for longer than normally required - for example if ST=1 sec and the PC can poll in say 200msec, the Xbee+your sensor might be done at 300msec, but remain awake for 700 more msec, even sending 7 more beacon/polls to the parent for no purpose.
Do keep in mind that as long as the sleeping end-device is awake, it is sending RF polls to its parent every 100msec - see the PO (P-Oh not zero) setting.