Printing with EPL via PHP: Storing Images

Background Information:
Mac OS X Lion 10.7.3 (11D50b)
EPL: http://en.wikipedia.org/wiki/Eltron_Programming_Language
EPL Manual: http://www.geksagon.ru/i/2/EPL2_Manual.pdf

I am connecting to the printer via a 2-port serial to Ethernet server.

Printer Config Readout:

UKQ1935H U UPS V4.14   
S/N: 64A024100181
Serial port:96,N,8,1
Image buffer size:0245K
Fmem:001.0K,059.9K avl
Gmem:000K,0058K avl
Emem:010K,0058K avl
I8,C,001 rY
S4 D10 R000,000 ZT UN
q832 Q609,24
Option:D
oUs,t,u
10 19 29

Using PHP I am able to send commands to an EPL printer.
I can send Barcodes and ASCII lines no problem.
I can store images and then later use those images.

Problem:

When I mix the binary data with any other commands strange it breaks.

Example:

<?php
    $filename = WWW_ROOT . 'img/labels/mylogo.pcx';
    $handle = fopen( $filename , 'r' );
    $image = fread( $handle , filesize( $filename ) );
    $bytes = strlen( $image );
    fclose( $handle );

    # Store the image.
    # Delete twice when dealing with Printer Flash
    $commands = array(
        'GK"MYLOGO"', # Del
        'GK"MYLOGO"', # Del
        'GM"MYLOGO"' . $image_bytes, # Store
        $image_data # Binary data
    );
?>

That works fine by itself.

This also works fine - if run on a separate REQUEST:

<?php
    $commands = array(
        '', # <-- As per the manual, a blank line prior to a new label.
        'N', # Clear Image Buffer, New Label
        'GG30,10,"MYLOGO"', # Get image variable MYLOGO
        'P' # Print
    );
?>

So after the image has been stored MYLOGO will end up printing the stored logo.

But if I do this:

<?php
     $commands = array(
        'GK"MYLOGO"', # Del
        'GK"MYLOGO"', # Del
        'GM"MYLOGO"' . $image_bytes, # Store
        $image_data, # Binary data
        '', # <-- As per the manual, a blank line prior to a new label.
        'N', # Clear Image Buffer, New Label
        'GG30,10,"MYLOGO"', # Get image variable MYLOGO
        'P' # Print

     );
?>

It prints the logo but then starts to hang up.
If I had ASCII instructions with it they would not complete as they should.

Doing a dump from the printer shows that the first sequence of commands run, but once it gets into the binary data it starts receiving it, then in the MIDDLE and END of the binary data it starts trying to run the next set of commands (the ASCII commands) and then the binary continues.

This of course means it won't print…because the P command wasn't received after the image data.

Why is it doing this?

So it works: When to HTTP requests are made issuing the command sets separately (new socket connections).
It does not work when both sets of command are in the same HTTP request.

If the binary data is made with other commands - the printer enters an "odd" state and has to be power cycled in order to start receiving commands again.

End Goal: Be able to pass binary data with other commands and it not have a conniption.

Example code: https://gist.github.com/de3a1ba2f0decc36b6e6

Images

Entering dump: http://imageshack.us/photo/my-images/193/photo1any.jpg/

Top of the dump: http://imageshack.us/photo/my-images/37/photo2ln.jpg/

Showing up in the middle of the dump: http://imageshack.us/photo/my-images/820/photosaz.jpg/

What it "should" look like: http://imageshack.us/photo/my-images/832/photo5uc.jpg/

What it looks like with just ASCII and Barcodes: http://imageshack.us/photo/my-images/23/photo4ucf.jpg/

What it looks like messed up: http://imageshack.us/photo/my-images/708/photo3si.jpg/

Update 1: The other dev tried something and it may have worked, more testing to do, but ... for SOME reason...using 4 new lines after storing the image seems to work... this is not documented in the manual.

Update 2: After more testing, adding new lines does seem to "improve" the situation, but it does not fix it.

Update 3: After more testing I think the problem can be narrowed down to this:

If you run the STORE command once, everything is fine. Running it again causes seizures.

Update 4: This appears to be a problem with the printer itself or how it is networked to the application. Called up the customer and printed remotely to theirs and it seems to work perfectly.

As per Update #4: This appears to be a problem with the printer itself or how it is networked to the application. Called up the customer and printed remotely to theirs and it seems to work perfectly.