02-19-2010 10:47 AM
the target system only operates at 115k.
from the port mon i do not notice any odd characters. one thing is that normally the sent message from port mon (IRP_MJ_WRITE) is perfect but right after it follows by a IRP_MJ_READ (which includes the read message and the reply from the target). In the read message from port mon i do not notice any odd characters but do see the spacing has changed a bit and a . has been added at a random position. However, this is true for when the issue is NOT observed also which does not really say a lot.
also, if i look at the text file where both the send and receive message is saved by the vi (as shown in the screen shot) then you can see some weird characters(so far i have only see squares) being print out for the sent message which i cannot explain. again, this is true for whether the issue is observed or not.
02-19-2010 10:49 AM
02-19-2010 10:53 AM
I believe PortMon has a hex mode that will tell you about what is in the squares. I'm thinking there may be an escape sequence that we have to handle.
Ben
02-19-2010 11:06 AM
yes, it does have an hex mode. well, the weird thing is that i do not see the squares with port mon but only in the text file generated by vi.
so for port mon the sent message is perfectly seen.
but that is a good idea i will try to match the hex output with the good case and bad case to see if there is any discrepancy.
02-19-2010 11:08 AM
02-19-2010 11:10 AM
I believe hyperterminal send out each character one at a time. If slowing down the rae of transmits helps then maybe we are back to hand-shaking and X-on/X-off.
but first check what the good vs bad looks like before we speculate ourselves into right field.
Ben
02-19-2010 11:14 AM
Ben wrote:I believe hyperterminal send out each character one at a time. If slowing down the rae of transmits helps then maybe we are back to hand-shaking and X-on/X-off.
but first check what the good vs bad looks like before we speculate ourselves into right field.
Ben
I have worked with hardware in the past that had very small data buffers and would not work properly if you sent a whole string at one time. To communicate with the device the data had to be sent a single byte at a time like hyperterminal does it. BTW, this device didn't support any flow control. You can try an experiment and write a simple piece of code that would send the characters out one at a time with a settable deley between each character. If this works you probably found your solution.
02-19-2010 01:46 PM
02-22-2010 11:43 AM
i looked at the hex code for the good case and the bad case. i cannot really tell the difference between the two.
if the issue is really being caused by the buffer size of the target then this would not be good. and if the only resolution is to send char by char then i will have to modify all the 20 or so vi's being used.
02-22-2010 12:10 PM
USar wrote:i looked at the hex code for the good case and the bad case. i cannot really tell the difference between the two.
if the issue is really being caused by the buffer size of the target then this would not be good. and if the only resolution is to send char by char then i will have to modify all the 20 or so vi's being used.
It would not be fun to have to modify all of your code however this does illustrate the importance of creating modular and reuasable code. If all of your communications used a common set of subVIs the only code you would need to modify would be the read/write subVIs. All of your high level code should remain intact and unaffected. If you do need to modify your code keep this is mind for future maintainability.