MSComm
in [Visual Studio]
|
From: Jim Mack on 26 May 2010 13:46 Henning wrote: >> 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 > Since you seem to be just waiting anyway, why not place a non-DoEvents delay in the OnComm event. Then you could eliminate the For loop after the While...Wend: Sub MsComm1_OnComm(event_type) if event_type is send_buffer_empty then sleep 2 TxOn = False end if End Sub I would call 'timeSetPeriod 1' on program start, and 'timeEndPeriod 1' on close to insure that your Sleep is as accurate as possible. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
From: Henning on 26 May 2010 14:01 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:mpudnRbh2NDxw2DWnZ2dnUVZ_hqdnZ2d(a)giganews.com... > Henning wrote: > >>> 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 >> > > > Since you seem to be just waiting anyway, why not place a non-DoEvents > delay in the OnComm event. Then you could eliminate the For loop after > the While...Wend: > > Sub MsComm1_OnComm(event_type) > > if event_type is send_buffer_empty then > sleep 2 > TxOn = False > end if > > End Sub > > I would call 'timeSetPeriod 1' on program start, and 'timeEndPeriod 1' > on close to insure that your Sleep is as accurate as possible. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > > Thanks, I will try that one too, it is more 'general' to be independent of cpu speed. /Henning
From: Henning on 26 May 2010 16:33 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:mpudnRbh2NDxw2DWnZ2dnUVZ_hqdnZ2d(a)giganews.com... > Henning wrote: > >>> 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 >> > > > Since you seem to be just waiting anyway, why not place a non-DoEvents > delay in the OnComm event. Then you could eliminate the For loop after > the While...Wend: > > Sub MsComm1_OnComm(event_type) > > if event_type is send_buffer_empty then > sleep 2 > TxOn = False > end if > > End Sub > > I would call 'timeSetPeriod 1' on program start, and 'timeEndPeriod 1' > on close to insure that your Sleep is as accurate as possible. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > > The Sleep version did not work for some reason. Sleep 2 was too small and Sleep 3 too large... I did call dummy = timeBeginPeriod(1) and dummy = timeEndPeriod(1). I had to change the loop value depending on the number of bytes to send. There can be 5,6,14 or 16 bytes in a packet. If Len(s) < 10 Then limit = 770000 Else limit = 1400000 End If ........ For i = 1 To limit '476800 ' DoEvents Next After this change everything is playing as it should. I can't figure out why the loopvalue has to be different for small or large packets, if the MSComm control is working as expected?? /Henning
From: Henning on 26 May 2010 16:34 "Jim Mack" <no-uce-ube(a)mdxi.com> skrev i meddelandet news:mpudnRbh2NDxw2DWnZ2dnUVZ_hqdnZ2d(a)giganews.com... > Henning wrote: > >>> 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 >> > > > Since you seem to be just waiting anyway, why not place a non-DoEvents > delay in the OnComm event. Then you could eliminate the For loop after > the While...Wend: > > Sub MsComm1_OnComm(event_type) > > if event_type is send_buffer_empty then > sleep 2 > TxOn = False > end if > > End Sub > > I would call 'timeSetPeriod 1' on program start, and 'timeEndPeriod 1' > on close to insure that your Sleep is as accurate as possible. > > -- > Jim Mack > Twisted tees at http://www.cafepress.com/2050inc > "We sew confusion" > > The Sleep version did not work for some reason. Sleep 2 was too small and Sleep 3 too large... I did call dummy = timeBeginPeriod(1) and dummy = timeEndPeriod(1). I had to change the loop value depending on the number of bytes to send. There can be 5,6,14 or 16 bytes in a packet. If Len(s) < 10 Then limit = 770000 Else limit = 1400000 End If ........ For i = 1 To limit '476800 ' DoEvents Next After this change everything is playing as it should. I can't figure out why the loopvalue has to be different for small or large packets, if the MSComm control is working as expected?? /Henning
From: Jim Mack on 26 May 2010 18:28 Henning wrote: > > The Sleep version did not work for some reason. Sleep 2 was too > small and Sleep 3 too large... > I did call dummy = timeBeginPeriod(1) and dummy = > timeEndPeriod(1). > > > I had to change the loop value depending on the number of bytes to > send. There can be 5,6,14 or 16 bytes in a packet. > > If Len(s) < 10 Then > limit = 770000 > Else > limit = 1400000 > End If > > ....... > > For i = 1 To limit '476800 > ' DoEvents > Next > > After this change everything is playing as it should. I can't > figure out why the loopvalue has to be different for small or large > packets, if the MSComm control is working as expected?? I'll bet the xmit FIFO is active, which would mean THRE would raise (cause the OnComm) as soon as the last byte entered the queue. With a full 14-byte FIFO, the transmit shift register (TSR) would take 140 bit-times to empty. If your messages were less than 14 bytes, THRE would come back instantly, but the TSR would take a variable amount of time to empty. Apart from monitoring the TSR status directly, which we used to do in the DOS days, there's no way to tell. You can probably still get it if you use the .CommID property to request a DCB from the UART. You could use the comm port control panel / advanced to turn off the xmit FIFO if you wanted to test the theory. -- Jim Mack Twisted tees at http://www.cafepress.com/2050inc "We sew confusion"
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Identifying Modified Database Fields Next: Sort order multilanguage |