By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,896 Members | 1,728 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,896 IT Pros & Developers. It's quick & easy.

SerialPort CDHolding, Works only during Debug

P: 7
Delving into SCPI commands and DTR/DSR communications. I have worked my problem down to some nuance. I am using C# Express 08 on Win XPSP2. My code does this:

create, set, and open serialport; // nothing fancy

SP.DtrEnable = true;
somestring = SP.ReadExisting();

EDIT: there are supposed to be ~19 bytes sent back from the APPL? command.

Now this works when I put a debug break on the Write but not when the break is on DtrEnable or just letting it run. The only parameter that changes with the break point placement is SP.CDHolding. This turns and stays 0 with the break at the write but is 1 when break is at DTR.

I tried both types of handshaking and spent an hour learning how to enumerate and the differences in handshaking. I also tried putting Thread.Sleep(1000) before and after everything.

Any holes to chase or new approaches would be helpful.
Feb 4 '09 #1
Share this Question
Share on Google+
2 Replies

Expert 100+
P: 229
You should implement some sort of a state-machine when doing this type of communication.

The problem is that you cannot know if your data will already be sent in the moment when you manually enable DTR. After that, you immediately start reading, without knowing if your previous data has been sent, and without allowing your other device to reply.

You can either handle the SerialPort.DataReceived event and have a FIFO input buffer which you can then parse to change states in your program, or have a separate thread which polls the SerialPort with some thread sleeping between reads, which also fills the input buffer for later processing.
Feb 4 '09 #2

P: 7
Why would putting a manual sleep into the code not fix this problem? Even in debugging I am breaking before manually setting the DTR, ensuring the output buffer is empty, and the device does not send me anything after setting DTR high. 0.5 seconds will not kill me and will gladly pay that price to avoid a full on state machine (had to wiki this morning). Something is futzing with my serial port and in the debugging environment it does not happen.

I will start moving toward a FSM but do not like spaghetti. Thanks for the reply vekipeki!
Feb 4 '09 #3

Post your reply

Sign in to post your reply or Sign up for a free account.