MSComm
in [Visual Studio]
|
From: Henning on 26 May 2010 11:03 Hi, Problem: Communicating with an external device using a RS-232/RS-485 simplex converter. The Rx/Tx is switched using DTR. I set SThreshold = 1 wich causes an OnComm with comEvSend when the last byte in the buffer is moved to the shiftout register in the UART. I have a Boolean TxOn that I set True before transmitting, and reset to False in the comEvSend. The problem is that the HW shiftout register is not empty when comEvSend triggers. The external device starts sending a 5-byte Ack after 5 ms silence on the RS-485 line. In the timegap between last bit shifted out, and 5 ms silence I have to switch the RS-485 converter back to receive mode. I have tried different ways to wait for the last byte to be shifted out of the UART + 2 ms, but not made it 100% reliable. Someone have some idea how to solve that? /Henning
From: Jim Mack on 26 May 2010 11:53 Henning wrote: > Hi, > > Problem: > Communicating with an external device using a RS-232/RS-485 simplex > converter. > The Rx/Tx is switched using DTR. > I set SThreshold = 1 wich causes an OnComm with comEvSend when the > last byte in the buffer is moved to the shiftout register in the > UART. I have a Boolean TxOn that I set True before transmitting, > and reset to False in the comEvSend. > > The problem is that the HW shiftout register is not empty when > comEvSend triggers. > The external device starts sending a 5-byte Ack after 5 ms silence > on the RS-485 line. In the timegap between last bit shifted out, > and 5 ms silence I have to switch the RS-485 converter back to > receive mode. > > I have tried different ways to wait for the last byte to be shifted > out of the UART + 2 ms, but not made it 100% reliable. > > Someone have some idea how to solve that? > > /Henning The time delay depends entirely on the baud rate -- wait 10 bits times at the set rate. For example, at 38.4K baud (38400 bits per second), 10 bit times is ..26 mSec. If you have to wait for the converter to shift out as well, double that. Practically, 1 mSec is the shortest time you can wait on a PC, if you use the multimedia timer and apply a timeSetPeriod of 1. What have you tried so far? -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Henning on 26 May 2010 13:05 -- Customer Hatred Knows No Bounds at MSFT Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:lamdnR71E4uf2WDWnZ2dnUVZ_jGdnZ2d(a)giganews.com... > Henning wrote: >> Hi, >> >> Problem: >> Communicating with an external device using a RS-232/RS-485 simplex >> converter. >> The Rx/Tx is switched using DTR. >> I set SThreshold = 1 wich causes an OnComm with comEvSend when the >> last byte in the buffer is moved to the shiftout register in the >> UART. I have a Boolean TxOn that I set True before transmitting, >> and reset to False in the comEvSend. >> >> The problem is that the HW shiftout register is not empty when >> comEvSend triggers. >> The external device starts sending a 5-byte Ack after 5 ms silence >> on the RS-485 line. In the timegap between last bit shifted out, >> and 5 ms silence I have to switch the RS-485 converter back to >> receive mode. >> >> I have tried different ways to wait for the last byte to be shifted >> out of the UART + 2 ms, but not made it 100% reliable. >> >> Someone have some idea how to solve that? >> >> /Henning > > The time delay depends entirely on the baud rate -- wait 10 bits times > at the set rate. > > For example, at 38.4K baud (38400 bits per second), 10 bit times is > .26 mSec. If you have to wait for the converter to shift out as well, > double that. > > Practically, 1 mSec is the shortest time you can wait on a PC, if you > use the multimedia timer and apply a timeSetPeriod of 1. > > What have you tried so far? > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > The comm settings are = 9600,n,8,1 This is my last try so far, but since DoEvents timing is variable I get about 1 error in 100 sends. In my next try I will skip the DoEvents and adjust the loop count, I guess that after the last byte is transfered to the UART shiftout register there is no need for a DoEvents. I thought that someone else could have resolved some similar issue. /Henning
From: Henning on 26 May 2010 13:07 -- Customer Hatred Knows No Bounds at MSFT Free usenet access at http://www.eternal-september.org ClassicVB Users Regroup! comp.lang.basic.visual.misc "Henning" <computer_hero(a)coldmail.com> skrev i meddelandet news:htjkck$kig$1(a)news.eternal-september.org... > > > -- > Customer Hatred Knows No Bounds at MSFT > Free usenet access at http://www.eternal-september.org > ClassicVB Users Regroup! comp.lang.basic.visual.misc > "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet > news:lamdnR71E4uf2WDWnZ2dnUVZ_jGdnZ2d(a)giganews.com... >> Henning wrote: >>> Hi, >>> >>> Problem: >>> Communicating with an external device using a RS-232/RS-485 simplex >>> converter. >>> The Rx/Tx is switched using DTR. >>> I set SThreshold = 1 wich causes an OnComm with comEvSend when the >>> last byte in the buffer is moved to the shiftout register in the >>> UART. I have a Boolean TxOn that I set True before transmitting, >>> and reset to False in the comEvSend. >>> >>> The problem is that the HW shiftout register is not empty when >>> comEvSend triggers. >>> The external device starts sending a 5-byte Ack after 5 ms silence >>> on the RS-485 line. In the timegap between last bit shifted out, >>> and 5 ms silence I have to switch the RS-485 converter back to >>> receive mode. >>> >>> I have tried different ways to wait for the last byte to be shifted >>> out of the UART + 2 ms, but not made it 100% reliable. >>> >>> Someone have some idea how to solve that? >>> >>> /Henning >> >> The time delay depends entirely on the baud rate -- wait 10 bits times >> at the set rate. >> >> For example, at 38.4K baud (38400 bits per second), 10 bit times is >> .26 mSec. If you have to wait for the converter to shift out as well, >> double that. >> >> Practically, 1 mSec is the shortest time you can wait on a PC, if you >> use the multimedia timer and apply a timeSetPeriod of 1. >> >> What have you tried so far? >> >> -- >> Jim Mack >> Twisted tees at http://www.cafepress.com/2050inc >> "We sew confusion" >> > > The comm settings are = 9600,n,8,1 > > This is my last try so far, but since DoEvents timing is variable I get > about 1 error in 100 sends. > > In my next try I will skip the DoEvents and adjust the loop count, I guess > that after the last byte is transfered to the UART shiftout register there > is no need for a DoEvents. > > I thought that someone else could have resolved some similar issue. > > /Henning > > Hmmm, to quick to send... *This* is my latest try... With frm_Main If .MSComm1.PortOpen Then .MSComm1.InBufferCount = 0 RxSize = 0 .MSComm1.DTREnable = False '* Change RS485 to Tx DoEvents TxOn = True .LedTxOn.BackColor = vbGreen .MSComm1.Output = s ' DoEvents While TxOn DoEvents Wend For i = 1 To 3167 DoEvents Next .MSComm1.DTREnable = True '* Change RS485 back to Rx DoEvents End If End With SendDelay = 4 /Henning
From: Henning on 26 May 2010 13:44
>>> Henning wrote: >>>> Hi, >>>> >>>> Problem: >>>> Communicating with an external device using a RS-232/RS-485 simplex >>>> converter. >>>> The Rx/Tx is switched using DTR. >>>> I set SThreshold = 1 wich causes an OnComm with comEvSend when the >>>> last byte in the buffer is moved to the shiftout register in the >>>> UART. I have a Boolean TxOn that I set True before transmitting, >>>> and reset to False in the comEvSend. >>>> >>>> The problem is that the HW shiftout register is not empty when >>>> comEvSend triggers. >>>> The external device starts sending a 5-byte Ack after 5 ms silence >>>> on the RS-485 line. In the timegap between last bit shifted out, >>>> and 5 ms silence I have to switch the RS-485 converter back to >>>> receive mode. >>>> >>>> I have tried different ways to wait for the last byte to be shifted >>>> out of the UART + 2 ms, but not made it 100% reliable. >>>> >>>> Someone have some idea how to solve that? >>>> >>>> /Henning >>> >>> The time delay depends entirely on the baud rate -- wait 10 bits times >>> at the set rate. >>> >>> For example, at 38.4K baud (38400 bits per second), 10 bit times is >>> .26 mSec. If you have to wait for the converter to shift out as well, >>> double that. >>> >>> Practically, 1 mSec is the shortest time you can wait on a PC, if you >>> use the multimedia timer and apply a timeSetPeriod of 1. >>> >>> What have you tried so far? >>> >>> -- >>> Jim Mack >>> Twisted tees at http://www.cafepress.com/2050inc >>> "We sew confusion" >>> >> >> The comm settings are = 9600,n,8,1 >> >> This is my last try so far, but since DoEvents timing is variable I get >> about 1 error in 100 sends. >> >> In my next try I will skip the DoEvents and adjust the loop count, I >> guess that after the last byte is transfered to the UART shiftout >> register there is no need for a DoEvents. >> >> I thought that someone else could have resolved some similar issue. >> >> /Henning >> >> > > Hmmm, to quick to send... > *This* is my latest try... > > With frm_Main > If .MSComm1.PortOpen Then > .MSComm1.InBufferCount = 0 > RxSize = 0 > .MSComm1.DTREnable = False '* Change RS485 to Tx > DoEvents > TxOn = True > .LedTxOn.BackColor = vbGreen > .MSComm1.Output = s > ' DoEvents > While TxOn > DoEvents > Wend > For i = 1 To 3167 > DoEvents > Next > .MSComm1.DTREnable = True '* Change RS485 back to Rx > DoEvents > End If > End With > SendDelay = 4 > > /Henning > Seems this fixed the timing issue on my dev machine. IRL the conversion will be handled by a custom hw interface not readybuilt yet. The thought that DoEvents was not needed after the last byte transfered to the shiftout register was right (this time)... For i = 1 To 473800 ' DoEvents Next It's now 1500+ packets sent without error, and still running once per second. /Henning |