mscomm - barcode label printer problems

[mtb1996]

I have inherited a VB app that is used to retrieve label information from a SQL server then print the data to a barcode label printer over COM1 using the MSComm control. Depending on the product, either 2 or 4 labels get printed. The app was recently upgraded from VB5 to VB6 and now the first label intermittently prints twice. I've ran over the code seaching for any indication that it's a problem with the code and even implemented a log file to track the progress of the code as it executes and all indications are that the code is working flawlessly. As a test I've removed the new system and placed the old computer with the old app in service and so far everything is working fine. Here's some information on the two systems,

OLD SYSTEM:
Winnt 4.0 sp6a
mscomm32.ocx version 5.00.3714

NEW SYSTEM:
Win2K sp3
mscomm32.ocx version 6.00.8169

Aside from the newer, faster computer and the new mscomm32.ocx control, not much else has changed. I was going to try to copy the older version of the ocx to the new computer and try it again. Anyway have any other suggestions???

Thanks in advance.
Matt

 

[ADoozer]

little more info on the printer and the app might help (ie baudrate, handshaking, etc)
only thing of the top of my head is some kind of speed issue with the old (i assume slower) printer and the new faster PC.

If somethings hard to do, its not worth doing - Homer Simpson

 

[mtb1996]

I don't have any printer information right now, I'll pick that up today while I'm on site. The settings for the mscomm control are as follows:

CommPort: 1
DTREnable: True
EOFEnable: False
HandShaking: comXonXoff
InBufferSize: 1024
InputLen: 0
InputMode: comInputModeText
NullDiscard: False
OutBufferSize: 512
ParityReplace: ?
RThreshold: 0
RTSEnable: False
Settings: 9600,e,7,1
SThreshold: 0

The one thing I did check is the size of the text string we're sending, and it's >600 characters while our OutBufferSize is set to 512. I thought this might be the problem, but I would expect more random failure results than what I am seeing. The problem we have is that the first label in a set of four is printed twice. Whenever it fails, it's always the first label. I'll follow this post with another containing the code.

Thanks,
Matt

 

[mtb1996]

Here's the code that prints the label...

******************************************************
Sub Print_Label()
On Error GoTo Error_Handler
gcErrSub$ = "Print_Label"

gnRetry% = 0

Set dbsSQLServer = Workspaces(0).OpenDatabase(gcDbName$, dbDriverNoPrompt, False, gcConnect$)

'This checks if one or two pallets
Do
gnRetry% = gnRetry% + 1

gcTagName$ = "AP_TWOPALLETS_S" + gcPrinter$
gnEdaErr&(0) = eda_get_one_float(gcNode$, gcTagName$, "F_CV", gnOnePallet)

Call Sleep(100) 'Delay .1 second
Loop Until gnRetry% > 5 Or gnEdaErr&(0) = 0

If gnOnePallet < 1 Then
'Log File
strOutput = Now() & " " & gnOnePallet & " : Printing 2 labels"
WriteToLogFile strOutput

Call Read_PLC_Info_Pal_1(1)
Call Read_PalNum_Info(1)
Call Read_PrdEnt_Info(1)
Call Calc_Values(1)

'Log File
strOutput = Now() & " Printing barcode label 1"
WriteToLogFile strOutput
Call Print_Barcode_Label(1)

'Log File
strOutput = Now() & " Printing barcode label 2"
WriteToLogFile strOutput
Call Print_Barcode_Label(1)
Else
'Log File
strOutput = Now() & " " & gnOnePallet & " : Printing 4 labels"
WriteToLogFile strOutput

Call Read_PLC_Info_Pal_1(1)
Call Read_PalNum_Info(1)
Call Read_PrdEnt_Info(1)
Call Calc_Values(1)

Call Read_PLC_Info_Pal_2(2)
Call Read_PalNum_Info(2)
Call Read_PrdEnt_Info(2)
Call Calc_Values(2)

'Log File
strOutput = Now() & " Printing barcode label 1"
WriteToLogFile strOutput
Call Print_Barcode_Label(1)

'Log File
strOutput = Now() & " Printing barcode label 2"
WriteToLogFile strOutput
Call Print_Barcode_Label(2)

'Log File
strOutput = Now() & " Printing barcode label 3"
WriteToLogFile strOutput
Call Print_Barcode_Label(1)

'Log File
strOutput = Now() & " Printing barcode label 4"
WriteToLogFile strOutput
Call Print_Barcode_Label(2)
End If
dbsSQLServer.Close

gcTagName$ = "AP_Print_Tick_S" + gcPrinter$
gnEdaErr&(0) = eda_set_one_ascii(gcNode$, gcTagName$, "A_CV", "0", Pkey)

If gnEdaErr&(0) > 0 Then
gnEdaErr&(0) = eda_set_one_ascii(gcNode$, gcTagName$, "A_CV", "0", Pkey)
End If

Exit Sub

Error_Handler:
gcMsg$ = gcErrSub$ & ": " & Err.number & "--" & Err.Description
Call Event_Log("AutoPal VB Error: " & gcMsg$, "M")
Call Set_Alarm(gcMsg$)
Call Update_List(gcMsg$)
Exit Sub
End Sub

*********************************************************


Sub Print_Barcode_Label(lnPallet%)
Dim PrintStr As String
Dim ComStatus As String
gcSaveSub$ = gcErrSub$
gcErrSub$ = "Print_Barcode_Label"
PrintStr = ""
ComStatus = MSComm1.PortOpen
If ComStatus = False Then
MSComm1.PortOpen = True
End If
'Open "Com2:" For Output As #1

PrintStr = "<STX>R<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>k<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>C0" & vbCrLf
PrintStr = PrintStr & "<SI>g1,424" & vbCrLf
PrintStr = PrintStr & "<SI>T1" & vbCrLf
PrintStr = PrintStr & "<SI>R0<SI>r0" & vbCrLf
PrintStr = PrintStr & "<SI>D0<SI>c0<SI>t1" & vbCrLf
PrintStr = PrintStr & "<SI>l0" & vbCrLf
PrintStr = PrintStr & "<SI>F2" & vbCrLf
PrintStr = PrintStr & "<SI>f10" & vbCrLf
PrintStr = PrintStr & "<SI>L1000" & vbCrLf
PrintStr = PrintStr & "<SI>I5" & vbCrLf
PrintStr = PrintStr & "<SI>i0" & vbCrLf
PrintStr = PrintStr & "<SI>S40" & vbCrLf
PrintStr = PrintStr & "<SI>d0" & vbCrLf
PrintStr = PrintStr & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>E2,1<CAN><ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F4<LF><SUB><SUB>1" & gcBarCode1$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F5<LF><SUB><SUB>1" & gcBarCode2$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F6<LF>" & gcBarCode2$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F7<LF>" & gcBarCode2$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F9<LF>" & gcBCBest$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F10<LF>" & gcLotCode$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F11<LF>" & gcBarCode2$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F12<LF>" & gcBarCode1$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F15<LF>" & gcItmDsc$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F16<LF>" & gcDshPck$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F17<LF>" & Trim(Str(gnLayerCount&(lnPallet%))) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F20<LF>" & Trim(Str(gnTotCaseCnt&(lnPallet%))) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F22<LF>" & gcContents$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><ESC>F24<LF>" & gcUnitNumber$(lnPallet%) & "<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><RS>1<ETX>" & vbCrLf
PrintStr = PrintStr & "<STX><US>1<ETX><STX><ETB><ETX>" & vbCrLf

'Log File
strOutput = PrintStr
WriteToLogFile strOutput

MSComm1.Output = PrintStr
Call Sleep(1000)
'Close #1
MSComm1.PortOpen = False
gcErrSub$ = gcSaveSub$
End Sub

Thanks again

 

[ADoozer]

so the problem only happens when printing the 4 labels?

msdn states that the outbuffersize shouldnt be an issue, but might run the risk of overflowing.

(if in doubt just increase it a bit)

there is still a possibility that the faster PC is overrunning the input buffer on the printer, or maybe the handshaking isnt implemented properly?!

not sure realy what else to make of it.

If somethings hard to do, its not worth doing - Homer Simpson

 

[mtb1996]

Thanks ADoozer,

By "handshaking", are you referring to the XonXoff of the mscomm control or to throttling the data output to the mscomm control using responses from the print and oncomm events?

By the way, the printer is an Intermec Model 3600.

Thanks

 

[ADoozer]

http://www.psditalia.it/supporto/data_sheet/intermec/3600.pdf

just to clarify:

is this only happening when printing the 4 labels?
is the data being sent to the printer absolutely correct?

couple of things to try:

try increasing the buffer size (with a faster PC this shouldnt affect the performance of the app)

try increasing your sleep period (just to test, i dont think its possible to close a comm port with data in the buffer, but best to check)

secondly try an alternative to using sleep (theres been discussion in the forum about the pros and cons of using sleep, again im not sure how this would relate to your problem, but theoretically your program is asleep so maybe thats affecting the comm port?!)

(im still assuming this is a speed issue, but dont quote me on that )

if i have any moments of inspiration ill get back to you.

good luck.

If somethings hard to do, its not worth doing - Homer Simpson

 

[mtb1996]

The problem hasn't be resolved yet, but we ran some tests and I have some more information. Basically we rolled back to ground zero, reinstalled the old computer with NT and the old VB5 app on it, then incrementally made small changes to rule certain things out.

Our assumptions for possible problems were:
1) The newer v6 mscomm32.ocx might be the culprit.
2) The newer faster computer was somehow causing the problem.
3) The delay between sending information for each label was too short.
4) Perhaps the program compiled in VB6 behaved differently than the one compiled in VB5 .

TESTS:
1) Started with the old system as it was, to make sure it still worked. Once we verified the operation of the original system, we copied the v6 mscomm32.ocx to the machine, registered it, recompiled the VB5 program with the newer control. The app worked fine. This rules out that it's a problem with the newer control.

2) We took the VB5 program and compiled it in vb6 without making changes. The app still worked fine (still on the old computer). So it's not a VB6 problem.

3) We then added in the program changes we intended to make at the outset of all this which included increasing the output buffer to 1024 and increasing the sleep time to 3 seconds. We then recompiled and stuck the app on the old machine. So far it has been working on the old machine, but the rest of the day yesterday they were only running product that required 2 labels and this was not the failure condition. I'm not on site today, but I've got a call in to the plant to find out if they've run 4 labels yet.

If this last scenario works then we are going to assume that it's a hardware problem with the new machine. The plan then is to take the app with the increased buffer size and longer sleep time to the new machine and try it. We'll see what happens then.

More info... this app has not one scrap of code to deal with events or errors from the mscomm control or responses from the printer. I guess the original programmer didn't feel it necessary to know if the printer or the control was responding with anything. He just build his message and threw it out there hoping all would turn out okay.

I'll post more information when I have it.

Thanks again.

 

[ADoozer]

XonXoff is out of our control in the VB app (i think)

instead of using sleep, could you not do something like

while(mscomm1.outbuffercount>0)
'loop until our buffer is empty
do events
wend

that way we know that all the data has been sent for a single label before you try and send more data.

the datasheet doesnt mention anything RTS/CTS etc so im assuming the original programmer wasnt being lazy.

however if you have documentation about the actual printer commands (Communicates in printable ASCII or
control characters) you might be able to look for something being returned before sending the next label.

also, does the old app work on the new machine? (dry joints etc etc could also be at fault)



If somethings hard to do, its not worth doing - Homer Simpson