Hi,

I have been using Serial Port Ax version 2.9.5.77 for many years without significant problems together with Visual Basic 6.
Due to Vista problems (v2.9.5.77 causes Vista DEP to stop application), I have bought v3.x but this new version brings up at least one big problem.
As my customers are using all Windows version from Win95/NT up to Vista, I have to ensure that my application is working on all these plattforms.

New property .MaxOutQueue returns Zero, always. I have tried it on all OS and with different COM ports (native hardware COM and virtual COM like USB-2-COM bridges Prolific PL230x). This property seems useless.

So, how to set the .OutBufferSize to a max valid value? With Sport.dll v2.9.5.77, I did not care much about this. I just set .OutBufferSize=4096 and then read back .OutBufferSize. The return value was my buffersize to work with.
Using this method in sport.dll v3.0.0.142 causes problems. In Windows 98 SE running in VMware 6 for example, I can set OutBufferSize=4096 and when I read it back, the return is Zero. Of course, the buffer is not Zero. It is actually size=1, no matter what I try to set it. And here comes the problem. Sport.dll 2.9.5.77 gives me a much bigger Outbuffer than 1. Outbuffer=1 means sending byte by byte and that is horrible slow compared with OutbufferSize=1024. My speed goes down from ~150kb/s to ~10kb/s.

So, here my questions:
1. How to get the maximum valid vaule for OutBufferSize, especially in Win9x?
2. How to make the OutBufferSize > 1 like sport.dll v2.9.5.77 can do especially in Win9x?

Thanks

John

Same problem with my application. If it uses v3.0.0.142 it will not work in Win98, with v2.9 it worked flawlessly.

Hello,

According to the MaxInQueue Property Value, maximum size of the driver's internal output buffer. A value of zero indicates that no maximum value is imposed by the serial provider. Thus I kindly ask you to refer to your serial port provider.

Earlier in the majority of the cases we used WinAPi, but now we work directly with drivers of the COM port. Please note, that  Serial Port ActiveX Control is compatible with Windows 98, but it is necessary to use InitString command to initialize COM port correctly.

Hi Tina,

thanks for your answer, but it does not solve the problem. I am using InitString by the way.
Take this few lines of VB6 Code

Private Sub Form_Load()
    With SPortAx1
        .Open ("COM1")
        .InitString "19200,N,8,1"
        .OutBufferSize = 1024
        MsgBox .MaxOutQueue & vbCrLf & .OutBufferSize
        .Close
    End With
End Sub

It displays .MaxOutQueue=0 and .OutBufferSize=0 in Win98, WinME and even in WinXP with the physical COM port of my notebook.

So, same questions:

1. How to get the maximum valid vaule for OutBufferSize, especially in Win9x?
2. How to make the OutBufferSize lager than 1(one) like sport.dll v2.9.5.77 can do especially in Win9x?

regards,

John

Hello,

1) Please, be informed that if OutBufferSize returns zero, then you will not be able to get the maximum value for it. I kindly ask you to refer to developers of the drivers for your COM ports. If you are using standard COM ports, then, please refer this issue to Microsoft support team.

2) Please note, that you can set OutBufferSize larger than 1(one), but it will not work on Windows 98.

1) Please, be informed that if OutBufferSize returns zero, then you will not be able to get the maximum value for it. I kindly ask you to refer to developers of the drivers for your COM ports. If you are using standard COM ports, then, please refer this issue to Microsoft support team.

Sure. I will contact the microsoft team. They will help me instantly.
Hey, Tina, backt to planet earth, please. If your control offers no way to tell me which size the buffer actually has - how should a developer WORK with this? Try and error? Put data in until they are lost?

2) Please note, that you can set OutBufferSize lager than 1(one), but it will not work on Windows 98.

This makes sport.dll v3.x unuseable in Win9x. OutbufferSize=1 makes the communication extremly slow.

What I really do not understand is that both problems do not exist in v2.9.5.77.
This old version tells me the size of my buffer by setting a large value to OutBufferSize and then read it back and this old version gives me a large buffer in Win9x. So, where is my advantage upgrading to v3.x? The Windows Vista issue?

See, I have to solve this problem somehow. Reducing sport.dll capabilities whenever a problem occurs does not help. I put this sport.dll in my software and now I depend on it. Replacing is not easy  and I somehow have to make it work.
So, what is the best way to get maximum performance in Win9x with a large buffer and make it work in Vista?
My fallback strategy is to compile my application twice. One time with registered sport v2.9 and one time with 3.x and let my setup decide which version to install depending on targed OS. I will use v3.x in Vista only. But this does not solve the problem, that I do not know my OutBufferSize in Vista. I need to know this. It is like having a bucket whithout knowing its volume and the task to fill it up.
So, PLEASE tell your developers to solve this, like v2.9.5.77 did.

regards,

John

Sorry for the problem you have encountered.

1) To avoid data loss, I would recommend you to enable hardware flow control. As you perhaps know , dwMaxTxQueue specifies the maximum size, in bytes, of the driver's internal output buffer. A value of zero indicates that no maximum value is imposed by the serial provider.

To read more  about COMMPROP, please follow the link:
http://msdn.microsoft.com/en-us/library/aa911516.aspx

2) Please note, that version 3.x  of Serial Port ActiveX control was developed for the work with NT. And it is not fully compatible with Windows 98. Thus, for your purpose, I kindly ask you to use Serial Port ActiveX control 2.9.5.77.

I feel a little bit like repeating myself.

v2.9.5.77 can tell me the actual OutBufferSize by setting
.OutBufferSize to a large value and then reading it back. This method works in all OS, while new v3.x property .MaxOutQueue returns Zero, always.

v3.x does not behave like this. I have absolutely NO CHANCE to get the buffer size, not even using the method desribed above.
Yes, you can blame it on Microsoft or the driver manufacturer, but WHY does not v3.x offers the same way like v2.9.5.77 did?

Your suggestion using flowcontrol does not work at all.
First, my device does not support flowcontrol.
Second, flowcontrol prevents data loss between the OutBuffer and the destination system on the physical connection layer. But we are talking not about this interface but about the risk of data loss between my application and the Outbuffer. This is a completely different point in the communication chain. Flowcontrol does not tell me, how many bytes I can call the sport.Write method with.

Tina, I will bring this to a final point now. I feel like you are doing very good first level support, but this is a problem, one of the sport.dll developers has to care about.
If you are not deep into it, you cannot even realize the problem. Fact is, NO ONE can work with an Outbuffer without knowing it´s size.
Please ask a sport.dll developer to take this support thread.

regards,

John

Dear John,

First of all I can reassure you that all our supporters closely work with the developers when replies to each and every question on support. Sure, the developers were looking deep into this forum topic, perhaps there was just a misunderstanding at some point. And I want to apologize if we made you frustrated at some point.

Back to earth, as you say, let's differentiate between the two Properties: MaxOutQueue and OutBufferSize. Here I refer to the information in the User Manual which goes with Serial Port ActiveX Control v3:
 
"MaxOutQueue 
  Get maximum size of the driver's internal output buffer, in bytes. 
Property Value
    Maximum size of the driver's internal output buffer. A value of zero indicates that no maximum value is imposed by the serial provider. 
   
OutBufferSize
  Get or set specifies the recommended size of the device's internal output buffer, in bytes 
Property Value

   The recommended size of the device's internal output buffer, in bytes.
"

Now, we see that those are two different properties. The first one (MaxOutQueue) cannot allow you to set / change the value, becasue the maximum size of buffer size fully depends on the port manufacturer settings. You can only get this value.

OutBufferSize property can be used in two ways: to set the desired buffer size (note that this property doesn't guarantee that Windows will be capable to allocate the resources so that you get the buffer size equal to the value you set). Or you can use OutBufferSize to get the current buffer size. Each IDE has its own instructions on how to use this property in either of the two ways. You can refer to your IDE documentation to clarify this and see our Usage Samples.

Still, setting the Buffer size to a desired value is not the best solution according to our developers. Also note that if the MaxOutQueue returns zero in your case, you won't be able to set an output buffer size more than that value.

Regarding your device not supporting flow control, that might be true and we cannot check or help it from our side. As far as your second remark is concerned, let us disagree with you. FlowControl was initially designed to prevent data loss. It guarantees that all that is sent is delivered, or at least all that is sent before timeout. How it works: when the buffer is full and data cannot get through, you will either get a Write method hang up or the TimeOut (if you set that) will make data transmission stop. Sure, Flowcontrol does not tell you, how many bytes you can call the Write method with.

I hope this clarifies things a bit. Let me also underline that the discussed properties are those suggested by Microsoft, so you can also consult with them to get a deeper understanding of. And feel free to address us again if you have more questions.

Dear Janna,

I totally understand the difference between .OutBufferSize and .MaxOutQueue

My problem is, that I have to know the size of the buffer when calling .Write methode. Lets take this sample code in VB6 on WinXP SP3 together with a docking station physical COM Port of a Lenovo T61 notebook.

Private Sub Form_Load()
    With SPortAx1
        .Open ("COM1")
        .InitString "19200,N,8,1"
        .OutBufferSize = 1024
        MsgBox .OutBufferSize
        .Close
    End With
End Sub

With registered Sport.dll v2.9.5.77, my messagebox returns 4096. Why 4096? I have set it to 1024! Well, a bug, but I do not care, because I know, that I have a least 1024 buffersize.

Same code with registered sport.dll v3.0.0.142 returns Zero.
Reading .MaxOutQueue, returns Zero, too.
Question: What size is my buffer? And why das v3.x behave that different?

I hope, you finally see the problem. I somehow have to know the buffersize, because I have to care about when calling .Write methode. But sport v.3 says buffer is Zero. How many bytes can I pass to the .Write methode?

regards,

John

Dear John,

I have consulted with our developers and they informed that most commonly COM ports on the standard personal computers do not have an output buffer. That is why OutBufferSize property always returns 0 (zero). This was confirm by multiple tests and results from other users. As far as version 2.x of Serial Port ActiveX Control is concerned, there was an acknowleged bug with it. We didn't succeed to define OutBufferSize property correctly and that's why you got a large value.

Hello

This I use on XP SP3 and Vista. I got the same result with this version. And for the Moderator. I SURE that this problem is in the LIB. I downloaded your trial version of serial port monitor, to wath the communication. I used another software to set the device and then used eltima lib and set the very same settings and the result was that eltima lib was not able to set the buffer sizes, not even the InBuffer. I can replicate the steps at any time. That's why I try two computers one has virtual com port with profilic driver, and the another one on Vista is a card in PCI slot. The results are the same. I can send the logs from the monitor, source code used.
This log is from the software not using eltima lib but own:
--------------
[28/07/2008 09:41:51]
23  IRP_MJ_DEVICE_CONTROL - Request operates a serial port
   STATUS_SUCCESS
         IOCTL_SERIAL_SET_QUEUE_SIZE - Request sets the size of the internal receive buffer
            InSize - 1500
            OutSize - 1500
----------------------------------------------------------------------------------

This is log after setting eltima
portAX.InBufferSize = 1500
portAX.OutBufferSize = 1500

[28/07/2008 15:05:24]
8775  IRP_MJ_DEVICE_CONTROL - Request operates a serial port
   STATUS_SUCCESS
         IOCTL_SERIAL_SET_QUEUE_SIZE - Request sets the size of the internal receive buffer
            InSize - 1500
            OutSize - 0
----------------------------------------------------------------------------------
[28/07/2008 15:05:27]
8777  IRP_MJ_DEVICE_CONTROL - Request operates a serial port
   STATUS_BUFFER_TOO_SMALL
         IOCTL_SERIAL_SET_QUEUE_SIZE - Request sets the size of the internal receive buffer
            InSize - 0
            OutSize - 15663480
----------------------------------------------------------------------------------

The resulting setting is probably default:
portAX.InBufferSize = 4096
portAX.OutBufferSize = 0


Thank you for help

Hello,

Please, be informed that the problem with OutBufferSize Property is fixed by now. Please, note that the system is not obliged to execute  the customized setting. As you perhaps know the buffer size is 8 kb. Thus if you demand less buffer size it will not decrease it.

I'm glad to inform you that we released new build of Serial Port ActiveX Control.

To download the latest build,please go to:

http://www.eltima.com/download/serial-activex/

We will be eagerly waiting the test results from you.

Hello,

Thanks for the release, we tested it and it looks good, with the outboud buffer.
We tested also the API functions:

SetCommConfig, SetCommState

DCB.fBitFields - changed to see results

And as you mentioned the buffer could be not decreased. And also some drivers
have problems to set or change this setting, especialy the USB-->RS232 converters.

Some advice. It's better to use functions with a return walue like boolean or long .... to set values this way. Because your activex is using direct change through
propery which doesn't return any result of success. After setting value it reads
the value back from the port driver and changes to the readed value. So one must
check if the value is the same as wanted (sett) or the activex value is different
and set by the driver. I know that the "SetupComm" can only change value for both
out and in values and probably that was the problem. Or the problem maby was in the read function.

I know it is never possible to test all possibilities, options that can happen.

I see you are wery prompt and try to improve your products and I'm happy with that.

Your happy user

Hello,

Thank you very much.

We will surely take into account all your suggestions.

With 3.0.1.143, InBuffer problems have been fixed, but OutBuffer still is buggy.

Code: javascript:void(0);

Private Sub Form_Load()
    With SPortAx1
        .Open ("COM1")
        .InitString "19200,N,8,1"
        .OutBufferSize = 1024
        MsgBox .OutBufferSize
        .Close
    End With
End Sub
MsgBox returns OutBufferSize=0 no matter what I try to set.


@jurkak : Which portmonitor do you use?

As i told you, the COM ports on the standard personal computers do not have an output buffer. That is why OutBufferSize property always returns 0 (zero).