Topic: OutBufferCount does not appear to return current value
|By: Mike||Posted on: Aug 16 2017 at 03:48:07 PM|
|SComm32.OutBufferCount does not appear to return the current count like MSComm32.OutBufferCount. For testing you can check the OutBufferCount in a loop with DoEvents (to prevent a tight loop) and you will see the OutBufferCount decreasing in large chunks while the MSComm32 control shows the actual OutBufferCount progress byte for byte. I can query the control lines in the same loop and they are reported correctly so I know the control should have enough processor time available. It just doesn't look like the internal SComm32 OutBufferCount function is looking at the controls current internal output buffer count before it returns its value to the caller. Could the OutBufferCount only be getting updated when new data is added or the output count reaches 0? Could you please check your control code to see if this value is being refreshed before it returns a value. BTW, I have OverlappedIO = True. Also as expected, setting OverlappedIO = False does not update the value until the send has finished.|
|By: Mike||Posted on: Aug 16 2017 at 03:51:26 PM|
|I should also add that I using VB6 and control version 9.1.4 on Win7Pro64.|
|By: John O'G||Posted on: Aug 17 2017 at 04:53:29 PM|
|As far as I know MSComm32 is single buffered in that it doesn't have it's own transmit buffer. When you use .Output the data is written directly into the CommDrv buffer. When you then query OutbufferCount I assume MScomm32 makes an escapecom function call into the windows API to get the number of bytes in the CommDrv buffer.|
Scomm (again, afaik) is double buffered. It has it's own transmit buffers and data is written in blocks from its own buffer into the windows CommDrv buffer. This might explain why you see the value going down in blocks rather than one byte at a time.
After all that though, if you're using USB RS232 adapter or some other add-on device then that probably also has its own buffering onboard and/or in its device driver over which windows has no control so any OutbufferCount really is just never going to tell you really how many bytes are somewhere in the system making their way down through the various buffers before actually getting out of the serial port.
|By: Support||Posted on: Aug 17 2017 at 05:06:49 PM|
|John is almost correct in that SComm32 'is' double buffered. It gives SComm32 a degree of isolation from the underlying hardware. Maybe one of the reasons why people switch to Scomm32. SComm32 can never be MSComm32 otherwise there'd be no point using Scomm.|
The OutbufferCount should return the number of bytes in SComm's local buffer PLUS the number of bytes known to be in the Windows Comm Driver buffer.
But. the weakness I suppose, is that the value (number of bytes known to be in windows comm driver) is only updated each time data is shifted from Scomm's buffer into the Comm Driver buffer.
We setup low and high water marks in the windows comm driver. When that number of bytes in the windows comm driver falls below the low water mark it triggers an event in SComm that transfers the next block of data from the local buffer into the windows Comm driver filling the CommDriver back up to the high water mark.
The effect of this is that you'll see the data (appear to) go in blocks.
In theory we could make the Windows API call to get an accurate count from the comm driver each time you call OutbufferCount. I think we did that in earlier versions many years ago but now (As John said) there's so much buffering in modern serial port devices, add-on adapters, USB device, BT devices, remote port servers etc etc that any attempt to give an accurate outbuffercount would possibly just be a'feel good' lie.
|By: Guest||Posted on: Aug 18 2017 at 12:14:38 PM|
|In my application I really wanted to know when all the bytes had been sent. I'm using 2 wire RS485 where I need to toggle the transmitter chip on and off. So, when the packet has been sent I need to disable the transmitter so that the remote device can reply back over the same pair of wires.|
In the old days MSComm32 OutbufferCount was all I needed. When that was zero I could do the turn round.
With USB though MSComm32 reports outbuffercount zero even though most of the data is still in the USB outbuffer. and there's no way to know when the data has been sent because the usb device's manufacturer's don't give any API to interrogate their driver.
My solution was to loopback transmitted data to the RX pin of a second serial port. That allows my application to see each byte as it's transmitted. As soon as it sees the last byte (ETX) it knows the last byte has gone and it can do the turn round (disable local transmitter chips to allow the remote device to power up its chips and reply.
My packets are very small. With that second serial port I was able to see that MSComm32 Outbuffer count was already zero even before the first byte had actually left the serial port.
So, basically, I stopped using MSComm32 OutbufferCount years ago. It's pretty much useless as a way to monitor data being sent. So for me at least switching to this scomm32 was quite painless.
|By: Guest||Posted on: Aug 20 2017 at 09:24:07 AM|
|OutbufferCount. Just use it to check how much data will now fit into the tx buffer. Don't try to use is as a way to count the number of bytes actually sent. As previous posters have said the buffering in modern devices makes that impossible.|
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.