TCR suggested I add delays between the commands I was having trouble with. Didn't help. I added a 2 second delay, smart macro last, made no difference.
I found that if the smartmacro came last, the RF light never blinks on the antenna module, and no blue blink happens on the 400. If it's not first, the remote doesn’t send RF, apparently.
So I had a theory which I tested and it appears to be correct. Theory was IR device commands can't come before RF based comands. Taking Smart Macros out of the original theory as the problem. I moved to IR vs RF as the culprit.
Theory test:
Place 2 commands, seperated by a 2 second delay to be sure delay was not the issue.
Case 1: 1. Command that is a direct IR command, with the device's signal set to IR (only) in the RF control window (e.g. CineSlide IR). 2. SmartMacro (RF based) command FAILS. Smartmacro is NOT executed. No RF signal transmitted, no blink of antenna module
Case 2: 1. SmartMacro (RF) command 2. Command that is a direct IR command, with the device's signal set to IR (only) in the RF control window (e.g. CineSlide IR). Excutes properly
Case 3: 1. Individual button press command from a device set as RF in the RF control window (e.g. Oppo ON). MSC-400 sends IR command. Not a smartmacro. 2. SmartMacro (RF based) command 3. Command that is a direct IR command, with the device's signal set to IR(only) in the RF control window. Excutes properly.
Case 4: Same as failing case #1 above, only this time set the same IR (only) device to "IR & RF" in the RF control window 1. Command that is a direct IR command, with the device's signal set to IR & RF in the RF control window (e.g. CineSlide IR, edited to send IR and RF). 2. SmartMacro (RF) command Executes properly.
Conclusion: Devices with IR only settings before a RF based command casue subesquent RF commands to fail. At least within a macro, my MX-1200 will not swith back to RF once a IR (only) device command is executed.
Fix: Set all IR only devices to IR and RF. I set the RF output port to Blaster to avoid unneeded static on other output ports.
Shouldn't have to, but there it is. I'd be very interested if anyone can duplicate. The MX-980 in the same CC file did not have this issue, so I can only assume the bug/problem is with the MX-1200.
