In general, the Texmate Tiger operating system already takes care of the correct timing of inputs and outputs for its built-in functions. However, for writing macros with time critical I/O it is important to have some understanding of the interaction with the operating system.
During the macro loop, only time critical (interrupt based) tasks are performed by the operating system in the background. This includes the sampling of raw input data but not the processing of the raw input data. Apart from that, all other signal processing tasks are suspended by the operating system.
During the macro loop the input registers (e.g. CH1, RESULT) are not updated by the operating system. This allows the macro to test for different values (IF, SELECT) of an input channel without having to consider changes between two tests.
Any changes to registers from the macro are done immediately but the operating system will act upon these changes only after the macro loop is finished.
The main macro is called at the currently selected output rate (10 or 100 milliseconds). If a macro loop takes longer than the 10 or 100ms window and has not finished before the next input sample is ready to be processed, it will effectively slow down the overall output rate. As soon as the macro finishes the loop, the operating system will process the last input sample it has and do any other housekeeping routines before it calls the main macro again. This means that if the macro loop is greater than 2 times the output rate, the overall sampling rate will be reduced. If the loop extends pas serveral seconds the operating system will trigger a reset and the meter will restart.
Serial communications are an interrupt driven operating system task. Incoming data is buffered during the macro loop but not accessible before the next operating system cycle. When outgoing data is initiated by the macro (PRINT), it is copied into a serial buffer and the operating system starts sending it out straight away, so it does not wait until the data is sent - even though the PRINT command is one of the more time consuming functions.
The display update is handled by the operating system. Similar to the serial communication the WRITE command does not wait until it is finished but it still is a rather complex and thus time consuming function.
Smart modules have their own micro which allows them to act independent of the main micro. Therefore they can achieve a higher I/O rate which is not influenced by the macro.
A read of any of the rear pins (i.e. HOLD_PIN, LOCK_PIN, CAPTURE_PIN etc.) from the macro will actually read the instantaneous state of the input pin, so you may see different states within one macro loop.
In recent versions of the operating system (3.09, 4.02) the macro was given direct control over the relay outputs (RELAY_STATUS). This allows the macro to switch the relays faster since it does not have to wait for the setpoint logic of the operating system.
Within the Modbus_Master_Macro of the Tiger 380 you can issue Modbus read/write requests. Once a request is sent it will wait in the background (non-blocking) until it gets a reply so it can continue with the next instruction. This allows the operating system to get its turn and eliminates the need to constantly check for a reply.
On the Tiger 320 the USER_MEMORY is located on an EEPROM with a write time of 10ms per byte (i.e. 20ms per register). For time critical applications we suggest to avoid these registers by storing data in unused setup registers (e.g. setpoint values and delays...) which are located in FRAM with a much shorter write time. Another alternative is to postpone the EEPROM access to a less critical section of your application.
To check how much processing time your macro spends you can poll the CPU_LOADING register. This percentage refers only to the 10/100 millisecond output rate. If the macro takes longer than that you often get readings that switch between 100% and a lower percentage.
The simplest way to check whether your macro affects the output rate is to increment a variable in the main macro and compare its value to the actual time or a built-in timer (TIMER1 and TIMER2 are updated by the system clock every 100ms). If you compare it to the built-in timers be aware that the macro loop is not synchronized to the system clock and the timers might change at a different instant so they may be off by one for a 100ms output rate.