Why would a Zebra QLn220 Printer ignore the first couple of commands sent to it after sending it a command to update some settings?

Question

I am sending commands to a Zebra QLn220 for it to print labels (naturally). I also have code, though, that assigns values to certain printer settings, such as:

const string quote = "\"";
string keepPrinterOn = string.Format("! U1 setvar {0}power.dtr_power_off{0} {0}off{0}", quote);
string advanceToBlackBar = string.Format("! U1 setvar {0}media.sense_mode{0} {0}bar{0}", quote);
string advanceToGap = string.Format("! U1 setvar {0}media.sense_mode{0} {0}gap{0}", quote);

PrintUtils.SendCommandToPrinter(keepPrinterOn);

if (radbtnBar.Checked)
{
    PrintUtils.SendCommandToPrinter(advanceToBlackBar);
}
else if (radbtnGap.Checked)
{
    PrintUtils.SendCommandToPrinter(advanceToGap);
}

This works - after running that code with radbtnBar checked, those settings are now (as seen via running " ! U1 getvar "allcv" " in the Zebra Setup Utilities app):

power.dtr_power_off : off , Choices: on,off
media.sense_mode : bar , Choices: bar,gap

The problem is that after setting those values via the code above, and then attempting to print labels (after a lapse of at least 20 seconds, and have tested up to more than a minute), the first couple of attempts to print a label silently fail (there is no err msg, it is just that no printing takes place). On the third attempt, the label prints. Why would setting these vals cause the printer to temporarily "go deaf," and is there anything I can do to shake it back to wakefulness following the programmatic application of those settings so that it will print immediately?

Once the QLn220 finally regains responsiveness, it continues to print immediately on subsequent executions of the app with no delays; it's only after sending those commands ("power.dtr_power_off" and "media.sense_mode") that the printer is knocked out of its orbit for a season. A real zebra would never be as stubborn as a mule like this.

UPDATE

Banno's idea did the trick, apparently (appending crlfs ("\\r\\n")) to the commands to set the printer vars.

So it seems that what was happening was something like this:

Command 1 was sent to the printer to set a val (with no crlf).

Command 2 was sent to the printer to set another val (also with no crlf)

A label was then attempted to be printed; it didn't print. Seeing that it did have a crlf, though, the printer seemed to say, "Oh, you finally gave me one of the crlfs you owe me! But you're not getting off that easy - you still owe me one!"

A second attempt to print a label caused the printer to say, in effect, "Okay, then, you've paid your crlf debt; from now on, I will listen to the commands you send (as long as you terminate them with the crlf I so ravenously crave)."

UPDATE 2

Sometimes it still doesn't work (inconsistent behavior); I found that I had to "poke it" to get it to quit its somnambulism; see What Zebra QLn220 settings do I need to set (and to what value[s]) to get a setting to "stick"?

Answer 1

将“\\ r \\ n \\”附加到每个命令