Epson Slip Printer Problems Using Custom ESC/POS Driver Using Delphi XE2
Greetings,
I developed my own custom Epson slip printer driver using the ESC/POS command sequence using Delphi XE2.
The printing overall is no issue and all seems to be working fine, but the only thing that I can't seem to figure out, is why the speed of the printer is affected on other machines other than my development machine?
Let me explain:
On my development computer, after the baud rate is set to 9600 for the Epson TM-T88 IV, this thermal slip printer prints lightning fast which I assume is the speed that it's suppose to print at. I also tested other Epson thermals which yield the same result on my development computer.
But when I install the application that's using my custom driver on any other PC, the printers slows down dramatcially with the exact same settings and software I'm using on my computer.
I honestly have no idea how and why this is happening. I checked everything on the comport settings under "Device Manager"in Windows, but to no avail. At first I thought that it could be that I'm using a RS232 to USB Serial converter that mine is printing so fast, and the fact that the other computers are using traditional RS232 serial ports, that that could be causing the speed to slow down for some reason, but even this analogy prove to be wrong after I installed the USB converter on the other computers and running the printer through them as well. USB converter or not, they continue to print extremenly slow.
So my question is this:
Why is this happening and how do I go about getting the printer at the speed it's suppose to print on the other computers that's actually running the Point Of Sale software? It doesn't help me that the printer is printing at the intended speed the printer was built for on my development computer, but on the client computers that's actually being used in the live environment, is for some unknown reason literally printing at a 1/10 of the speed I get on my computer with the EXACT same settings across the board??? It literally "drip-feeds" the entire slip print job until the paper is then cut.
Can anyone please give me advice as to why this is happening and what am I to do to resolve this issue, cause at the moment it's creating a problem in the live environment where slips are printing extremely slow at the printer while other critical print jobs are also thrown into the que waiting for their chance to print.
If I can just get the printer to print at the same speed on all computers as with my development computer. This is another classical example of one of those sayings "But it works on my pc...".
Just some more technical info:
* Operating Systems Tested On: Windows 7 Professional, Windows Server 2007
* Development Computer: Dell Vostro 3700 Core i5 with Windows 7 Professional running a USB to RS232 Serial converter.
* Client Machines Where Problem Persists: All-In-One POS computers running Windows 7 with traditional RS232 serial ports, and also tested USB to Serial converter on them as well with no positive result.
* Also tested on a computer running Windows Server 2007 which yields the exact same slow printing result as with the client computers.
So far I'm only able to get my development computer to get the printer to print at the speed it was built for. So what could possibly be different??? The baud rates, parity, stop bits etc. is exactly the same on the comports itself, as well as the same settings within my software where you can set these settings with the comport component I'm using within Delphi.
That's another important thing to mention, and that is that I'm using the comport component from the "Turbo Power Apro" component package for Delphi that is freely available on SourceForge. I have no idea whether this could be the culprit or not.
Any ideas or advice to help me resolve this issue?
Thank you.
I developed my own custom Epson slip printer driver using the ESC/POS command sequence using Delphi XE2.
The printing overall is no issue and all seems to be working fine, but the only thing that I can't seem to figure out, is why the speed of the printer is affected on other machines other than my development machine?
Let me explain:
On my development computer, after the baud rate is set to 9600 for the Epson TM-T88 IV, this thermal slip printer prints lightning fast which I assume is the speed that it's suppose to print at. I also tested other Epson thermals which yield the same result on my development computer.
But when I install the application that's using my custom driver on any other PC, the printers slows down dramatcially with the exact same settings and software I'm using on my computer.
I honestly have no idea how and why this is happening. I checked everything on the comport settings under "Device Manager"in Windows, but to no avail. At first I thought that it could be that I'm using a RS232 to USB Serial converter that mine is printing so fast, and the fact that the other computers are using traditional RS232 serial ports, that that could be causing the speed to slow down for some reason, but even this analogy prove to be wrong after I installed the USB converter on the other computers and running the printer through them as well. USB converter or not, they continue to print extremenly slow.
So my question is this:
Why is this happening and how do I go about getting the printer at the speed it's suppose to print on the other computers that's actually running the Point Of Sale software? It doesn't help me that the printer is printing at the intended speed the printer was built for on my development computer, but on the client computers that's actually being used in the live environment, is for some unknown reason literally printing at a 1/10 of the speed I get on my computer with the EXACT same settings across the board??? It literally "drip-feeds" the entire slip print job until the paper is then cut.
Can anyone please give me advice as to why this is happening and what am I to do to resolve this issue, cause at the moment it's creating a problem in the live environment where slips are printing extremely slow at the printer while other critical print jobs are also thrown into the que waiting for their chance to print.
If I can just get the printer to print at the same speed on all computers as with my development computer. This is another classical example of one of those sayings "But it works on my pc...".
Just some more technical info:
* Operating Systems Tested On: Windows 7 Professional, Windows Server 2007
* Development Computer: Dell Vostro 3700 Core i5 with Windows 7 Professional running a USB to RS232 Serial converter.
* Client Machines Where Problem Persists: All-In-One POS computers running Windows 7 with traditional RS232 serial ports, and also tested USB to Serial converter on them as well with no positive result.
* Also tested on a computer running Windows Server 2007 which yields the exact same slow printing result as with the client computers.
So far I'm only able to get my development computer to get the printer to print at the speed it was built for. So what could possibly be different??? The baud rates, parity, stop bits etc. is exactly the same on the comports itself, as well as the same settings within my software where you can set these settings with the comport component I'm using within Delphi.
That's another important thing to mention, and that is that I'm using the comport component from the "Turbo Power Apro" component package for Delphi that is freely available on SourceForge. I have no idea whether this could be the culprit or not.
Any ideas or advice to help me resolve this issue?
Thank you.
Igor UL7AAjr
May be you have any extra sofware realtive to Epson printer on development computer. And it automatically adjust printer perfomance.
windows server 2007 ????
what does that look like ... never seen that before
don't you mean 2008 ?
anitvirus showing anything in it's logs about your program ?
>> have you set exclusions ?
what does that look like ... never seen that before
don't you mean 2008 ?
anitvirus showing anything in it's logs about your program ?
>> have you set exclusions ?
Recommended to:
- in Device Manager -> COMx -> Properties -> Port Settings -> Advanced -> set buffers to Low
- to send initialization command ( char(27) + char(64) ) to printer before each receipt
- to look that there is no other additional software which monitor port communication or other printer driver difined as text driver and assigned to this port
- try to use some port monitor (as portmon) and compare output on your dev. machine against output form customers one
- try using printer OPOS drivers available for almost all printer manufacturer
- in Device Manager -> COMx -> Properties -> Port Settings -> Advanced -> set buffers to Low
- to send initialization command ( char(27) + char(64) ) to printer before each receipt
- to look that there is no other additional software which monitor port communication or other printer driver difined as text driver and assigned to this port
- try to use some port monitor (as portmon) and compare output on your dev. machine against output form customers one
- try using printer OPOS drivers available for almost all printer manufacturer
ASKER
@ITugay: No additional software loaded. Only direct comport communication is taking place.
@Geert_Gruwez: It was a typo. Yes, I meant Windows Server 2008. My Anti-Virus software is not reporting anything on the application, so no exclusions were necessary.
@sinisav: Tried your first suggestion. Doesn't work. Tried your second suggestion. Also doesn't work. I have no other software monitoring the comports, neither is there any other printer defined. The OPOS drivers are not needed for this, as I'm specifically testing on Epson series printers using Epson's ESC/POS commands.
Portmon thus far seems to push out the same results, but I have a few more tests to do on it.
Is there any other reasons why this is happening? I checked all the baud rate settings and all, and the machines are identical, but the development machine prints lighting fast compared to all the other machines, which prints at less than half of the speed. What can cause this?
@Geert_Gruwez: It was a typo. Yes, I meant Windows Server 2008. My Anti-Virus software is not reporting anything on the application, so no exclusions were necessary.
@sinisav: Tried your first suggestion. Doesn't work. Tried your second suggestion. Also doesn't work. I have no other software monitoring the comports, neither is there any other printer defined. The OPOS drivers are not needed for this, as I'm specifically testing on Epson series printers using Epson's ESC/POS commands.
Portmon thus far seems to push out the same results, but I have a few more tests to do on it.
Is there any other reasons why this is happening? I checked all the baud rate settings and all, and the machines are identical, but the development machine prints lighting fast compared to all the other machines, which prints at less than half of the speed. What can cause this?
If no additional software and same settings, then it should be hardware feature. Why not to install development tools on "slow printing" computer and try to debug and compare timings. See no other way to solve this.
ASKER
This has been tested on no less than 15-other machines, ALL yield the exact same result, besides for the development machine. Whether executed from within Delphi or as the application itself, the development machine constantly produces the expected result and print as exepected, which is not the case for the other machines.
So its difficult to track the problem, as the development machine is working as expected. (?)
I can't install the development tools on the other machines, as they're clients of ours machines, unless I aquire a whole new pc just for this test.
It just doesn't make any sense whatsoever. If it was the comport component that was faulty, the same result is suppose to stick its head out even on the development machine.
So its difficult to track the problem, as the development machine is working as expected. (?)
I can't install the development tools on the other machines, as they're clients of ours machines, unless I aquire a whole new pc just for this test.
It just doesn't make any sense whatsoever. If it was the comport component that was faulty, the same result is suppose to stick its head out even on the development machine.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
very odd to say the least
you've probably started pulling your hair out by now ... i know i would be :)
one thought, which probably won't be accepted:
the development machine prints lighting fast compared to all the other machines,
>>> sell your dev machine at a very high price !!!
you don't have a line like this in your code ?
if computername <> mydevmachine then sleep(5000);
ok, enough jokes,
looks like you'll need to list all the differences
your dev machine must be different here somehow
>> hardware
>> check the hardware list in devices manager
>> any special hardware card ???
>> OS
>> versions home/embedded/pro/enterpri
>> also check the bios for the ports
you've probably started pulling your hair out by now ... i know i would be :)
one thought, which probably won't be accepted:
the development machine prints lighting fast compared to all the other machines,
>>> sell your dev machine at a very high price !!!
you don't have a line like this in your code ?
if computername <> mydevmachine then sleep(5000);
ok, enough jokes,
looks like you'll need to list all the differences
your dev machine must be different here somehow
>> hardware
>> check the hardware list in devices manager
>> any special hardware card ???
>> OS
>> versions home/embedded/pro/enterpri
>> also check the bios for the ports
have you tried remote debugging from within delphi ?
the clients machine will have to be in the same LAN
a client will probably let you bring in your dev machine in the LAN to pinpoint the cause in this problem
http://docwiki.embarcadero.com/RADStudio/en/Overview_of_Remote_Debugging
the clients machine will have to be in the same LAN
a client will probably let you bring in your dev machine in the LAN to pinpoint the cause in this problem
http://docwiki.embarcadero.com/RADStudio/en/Overview_of_Remote_Debugging
One more idea. Try to use oscilloscope to look at signals on com port. There is three possibilities:
At least you will have a direction to work.
1.
Slow baud rate.2.
Delay between character sent.3.
Right boud rate, right delay but printing same text takes more packages - something wrong with transmission (possible resent regarding errors).At least you will have a direction to work.
ASKER
@Geert_GruwezPosted
"you've probably started pulling your hair out by now ... i know i would be :)"
You have NO IDEA! Frustrating is an understatement. I have no more hair left to pull out! :)
I have tried all suggestions all but one thus far, but to no avail.
I will now try the suggestion by "sinisav" to try and use the suggested comport library, instead of using my current comport component which is from "TurboPower ASYNCPro".
My test application will use both of these components to print test prints in order for me to compare them directly with one another.
I shall return with the verdict in order for us to rule out the comport itself for being problematic, or maybe not. Maye a different comport will fix this issue.
In the mean while, any other suggestions are more than welcome.
Thanks.
"you've probably started pulling your hair out by now ... i know i would be :)"
You have NO IDEA! Frustrating is an understatement. I have no more hair left to pull out! :)
I have tried all suggestions all but one thus far, but to no avail.
I will now try the suggestion by "sinisav" to try and use the suggested comport library, instead of using my current comport component which is from "TurboPower ASYNCPro".
My test application will use both of these components to print test prints in order for me to compare them directly with one another.
I shall return with the verdict in order for us to rule out the comport itself for being problematic, or maybe not. Maye a different comport will fix this issue.
In the mean while, any other suggestions are more than welcome.
Thanks.
Question:
Did you try same printer on your (development) machine and same on clients machine?
I suspect that is a problem.
Did you try same printer on your (development) machine and same on clients machine?
I suspect that is a problem.
ASKER
Yes, I already tried that.
I tried the exact same printer model on my machine and on the client machines. The very same printer I use for development has been tested at a client with the same result.
If you plug the printer as is straight into the development machine, the speed is as expected, but not on the client's machine.
Still unexplainable at this point.
I tried the exact same printer model on my machine and on the client machines. The very same printer I use for development has been tested at a client with the same result.
If you plug the printer as is straight into the development machine, the speed is as expected, but not on the client's machine.
Still unexplainable at this point.
So, last chance is oscilloscope:) Beleave me, it's really easy, just try.
Recently, we have problem with additional com port pci-e card. When we put printer on motherboard com port all becomes fine.
ASKER
The problem with the ApdComport library finally came to surface!!
This is the problem:
The component "TApdComport" requires one to slow down the processing of a string when sending it through to the printer buffer character for character when processing ESC/POS commands. Typically this is achieved with a "Sleep(1)" command after each character that is sent through to the printer buffer.
If this sleep command is not present with this component, the print job is not completed and will only perform a partial print, stopping in the middle of nowhere.
For some reason, my development PC is treating the "Sleep(1)" command as if it's not even there, but if you remove it, the print job only prints partially. With the sleep command, the development PC prints at the normal expected speed, but all other machines actually slow down to cause a slow print job, but should you remove the "Sleep(1)" command, they too only complete a partial print job, loosing all other characters and commands in the process. Therefore it was determined that with this component, this specific "Sleep(1)" command needs to be there to get any kind of slip printed at all.
Witht the suggested comport component by "sinisav", I developed a little test application with the two comport components, and by removing the initial "Sleep(1)" command from the code, the printing is now fast and completely normal by using the "TComport" component.
Conclusion:
So the original issue is the fact that "TApdComport" is not able to process individual character print requests concurrently without having the "Sleep(1)" command in between the process of sending the individual characters to the printer buffer.
With the "TComport" component, the "Sleep(1)" command is not necessary at all, and works as expected when processing individual characters to the printer buffer, which should have been the case with the "TApdComport" component.
What still remains a mystery to me, is the fact that my development PC, a DELL Vostro 3700, is the only PC that managed to somehow print all print requests at the expected speed with the containing "Sleep(1)" command, where all other PC's, literally tens of other PC's, all reacted on the actual sleep command by slowing down the print speed, but also stops printing halfway in when the sleep command is removed.
So I'll be spending time to go through my entire code base to upgrade my comport component workings from "TApdComport" to "TComport".
Thanks for everbody's ideas and input. Hope this helps somebody else from not wasting precious time trying to figure this one out.
Thanks!
This is the problem:
The component "TApdComport" requires one to slow down the processing of a string when sending it through to the printer buffer character for character when processing ESC/POS commands. Typically this is achieved with a "Sleep(1)" command after each character that is sent through to the printer buffer.
If this sleep command is not present with this component, the print job is not completed and will only perform a partial print, stopping in the middle of nowhere.
For some reason, my development PC is treating the "Sleep(1)" command as if it's not even there, but if you remove it, the print job only prints partially. With the sleep command, the development PC prints at the normal expected speed, but all other machines actually slow down to cause a slow print job, but should you remove the "Sleep(1)" command, they too only complete a partial print job, loosing all other characters and commands in the process. Therefore it was determined that with this component, this specific "Sleep(1)" command needs to be there to get any kind of slip printed at all.
Witht the suggested comport component by "sinisav", I developed a little test application with the two comport components, and by removing the initial "Sleep(1)" command from the code, the printing is now fast and completely normal by using the "TComport" component.
Conclusion:
So the original issue is the fact that "TApdComport" is not able to process individual character print requests concurrently without having the "Sleep(1)" command in between the process of sending the individual characters to the printer buffer.
With the "TComport" component, the "Sleep(1)" command is not necessary at all, and works as expected when processing individual characters to the printer buffer, which should have been the case with the "TApdComport" component.
What still remains a mystery to me, is the fact that my development PC, a DELL Vostro 3700, is the only PC that managed to somehow print all print requests at the expected speed with the containing "Sleep(1)" command, where all other PC's, literally tens of other PC's, all reacted on the actual sleep command by slowing down the print speed, but also stops printing halfway in when the sleep command is removed.
So I'll be spending time to go through my entire code base to upgrade my comport component workings from "TApdComport" to "TComport".
Thanks for everbody's ideas and input. Hope this helps somebody else from not wasting precious time trying to figure this one out.
Thanks!