Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help!!!Big trouble when using $RXDATA system variable 1

Status
Not open for further replies.

thomas200813

Programmer
Feb 12, 2007
8
CN
Hi all,

I really run into a big strange trouble when I use aspect script in Procomm recently.

In short ,it seems that $RXDATA doen't work well all the time. It looks that the behavior of $RXDATA depends on the received byte. I think the script is correct without syntax and logic error in it. The script could run normally sometimes.But I found that the $RXDATA is not updated when we receive hex byte by com port sometimes.I am sure that bytes are received in fact with the help of monitor window tool.
E.g I send 0x01 0x46 by computc and get response with 0x01 0xff finally. We can observe 0x01 and 0xff in monitor window tool.But the $RXDATA is not updated in fact.It is still zero until I send next command and observe we can get the response for the last command togther with the next command.

The main functionality of my aspect script is to send hex command by COM port of my laptop to another RS232 UART interface.
The command will be sent by computc command and then the script will wait for the response from remote RS232 UART interface by monitoring $RXDATA system variable.The script uses comgetc the data from rxbuffer. Please refer to the script shown below in detail.

The big trouble is that:
The script doesn't always works well/normally. I don't think there is any syntax error or logic error in the aspect script because the script works well for sending/receiving some commands/bytes/data.Take hex byte 0x01 for example , the script will first send 0x1 by computc command to remote rs232 UART interface and then the script will receive two byte from remote interface. Those are 0x01 and FF . But the problem is that the procomm really received two bytes from remote system with the help of monitor window, yet the aspect is still deadlock running waiting for those two bytes.In fact , those responsed two bytes has arrived at procomm , but $RXDATA system varient is not updated corespondingly.So the aspect is still looping in the while loop all the time without exiting normally. At this time ,I make the script send another command , strangely I found that those two bytes for last command are counted together with this command.That is to say, the system varient $RXDATA is 3 at this time. I don't know why $RXDATA is not updated to 1 for the last command.

Is this the issue mentioned in .

"Another ASPECT user ran into a problem where Procomm Plus did not immediately process the character 0x01 (SOH) and only processed it when two additional characters were received. He verified this by monitoring the value of $RXDATA. He was able to resolve the problem by turning off the "Enable automatic download start for Zmodem and Kermit" checkbox in Procomm's Setup dialog"

aspect script :

func ITI_S01_C13:integer
integer result = SUCCESS
integer i=0
integer rx_chr
integer rx_array[3]

set aspect rxdata ON

computc 0x00+0x01
computc 0x46
i=0
while 1

while $RXDATA
comgetc rx_chr
rx_array = rx_chr
i++
endwhile

if( i >= 2)
exitwhile
endif

endwhile

result |= (rx_array[0]!=0x01||rx_array[1]!= 0x00)
txflush
rxflush
i=0
computc 0x80+0x01
while 1

while $RXDATA
comgetc rx_chr
rx_array = rx_chr
i++
endwhile

if( i >= 3)
exitwhile
endif

endwhile

result |= (rx_array[0]!=0x81||rx_array[1]!= 0x00)
result |= ((rx_array[0]^rx_array[1]^rx_array[2])!=0xAA)


return result
endfunc


Thanks a lot for your great help in advance,
Thomas.
 
At first glance, I would say the issue you are seeing may be related to the issue with the automatic download setting problem that you mentioned. Have you tried turning that setting off to see if it fixes your problem? If necessary, you can have your script turn that setting off at the begining and restore it when exiting with these commands:

set autodnld OFF
set autodnld ON

 
Knob,

Thanks a lot for your great help.
Just want to clarify that the procomm 4.8 is running on Windows XP operation system.I also tried to run procomm in compatibility mode.
I double check this today and I find the issue is partly fixed by turning off "Enable automatic download start for Zmodem and Kermit". But unfortunately this fix can not deal with all kinds of cases. That is to say , the $RXDATA system variable still is not updated in time for some kinds of data.

I am quit sure about "Procomm Plus did not immediately process the character 0x01 (SOH) and only processed it when two additional characters were received" by turning off/on "Enable automatic download start for Zmodem and Kermit" manually.But there are still some kinds of character that procomm will not immediately process even though I turn off "Enable automatic download start for Zmodem and Kermit"

Yesterday, I met with two kinds of failure case below.One of them is fixed by turning off "Enable automatic download start for Zmodem and Kermit".Another failure is also fixed ,but I made some test that it seems that it is not related to turning on/off "Enable automatic download start for Zmodem and Kermit". This is really quit strange for me why the second failure case works again today ,but failed yesterday.
failure case1:Send 0x01 0x46 using computc and then
Receive 0x01 0x1B. We can observe that 0x01
0x1B were both received by monitor window
tool.But $RXDATA is not updated immediately.
failure case2:Send 0x96 using computc and then
Receive 0x96 0x23 0x1F. We can observe that
0x96 0x23 0x1F were both received by monitor
window tool.But $RXDATA is not updated
immediately.
Today , I only met with one failure.
Failure case 1:Send 0x8E using computc and then
Receive 0x8E 0x34 0x10. We can observe that
0x8E 0x34 0x10 were both received by monitor
window tool.But $RXDATA is not updated
immediately.

Is there any trick/bug about $RXDATA?

It is highly appreciated that we could fix this issue completely.

Best regards,
Thomas.
 
So far as I know,both 0x01 and 0x10 will lead to aspect script issue when procomm script will not immediately process the character and only processed it when two additional characters were received.

By turning off "Enable automatic download start for Zmodem and Kermit", aspect script will work well when 0x01 is received.

How to configurate procomm so aspect script will still work too when 0x10 is received? Is there any other character which may cause $RXDATA issue?
 
Hmm, no idea off the top of my head why 0x10 would cause any problems. What terminal emulation are you using? If possible, you might try switching to TTY and see if that makes any difference. According to the ASCII table I'm looking at 0x10 is 16 ASCII or a Ctrl-P (also says DLE on the table, not sure what that code may have meant back in the day).

 
Knob,

It seems that the issue is completely fixed after I changed terminal emulation from VT100 to TTY.

Great thanks for your professional help.:)


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top