Macro or Routes are normally associated with setting up path through multiple turnouts or activating some actions on the layout all involving DCC accessory decoders.
Sometime people can experience accessory decoder not responding to command sent to it resulting in a incomplete implementation of the Macro function or track route.
Solution: There is no guaranteed solution but on idea to mitigate the problem because there are to many variables involved. The general idea is to make sure that the same accessory decoder never gets more than one command per Macro or Route. This will allow the given accessory decoder to finish the command it has long before another command will come along.
Problem Background:
The NMRA standards regarding Accessory decoders is not a clear indication of how well the device will work in the real world. Part of the problem is the speed at which the command are sent to a given decoder versus the decoder ability to accept them the moment they are sent. DCC Command buffering and limitation on back to back command rates for example are NOT well discussed by the NMRA DCC standards regarding accessory decoders. But in practice it really does affect performance and need to be carefully defined. Since there is no clear standard, the speed/buffering issue it is not implemented consistently by every vendor because there is no benchmark or test the represent a real world application they must pass. Examples; DCC Command are lost because a given decoder is busy processing the current command and/or is not listening for the next command. Another possibility is the accessory decoders buffer is overflowed because it is not deep enough for all the commands sent to it.
One specific example where buffering is very important are accessory decoder driving twin coil based machines. Typically a capacitive discharge circuit is built up but it take time to recharge the capacitor. The decoder waits for the capacitor to recharge before it carries out the current command it has to throw the switch. If it get several command during the time the capacitor it recharging, it may not accept those commands and they get lost. The faulty design assumption in the accessory decoder design is that the accessory decoder will never get commands back to back in less time it takes to recharge the caps. This is where a intelligent command queue could be implemented to figure out what is the final state it need to drive the twin coil machine if it "pre-evaluates" all of the command in it the command queue and only throws the turnout ONE TIME. In other words, it does not waste time throwing the twin coil back and forth needlessly and the associated delays that come with that.