|
In which line of your code does the error occur?
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
It happens in this line:
string line = serialPort1.ReadLine(); ;
|
|
|
|
|
Hi,
serial ports are tricky; and SerialPort documentation is missing a lot of info. I have lots of experience with SerialPort, and I happen to have read four articles about them just yesterday (more later).
I don't know for sure what is wrong in your situation, however I'll give you some pointers to critical aspects. I do expect you have two different issues, a receive issue and a close issue, and they are probably linked.
1. Encoding: as long as everything is ASCII (i.e. bit7 is zero in every byte), all is well. Whenever you need 8-bit (or 16-bit or 32-bit) characters, make sure SerialPort.Encoding is set correctly, it is used in Read() and Write(), unless you use the byte[] ones. Do not trust the default encoding.
You can use ISO 8859-1 for pass-thru:
port.Encoding=Encoding.GetEncoding(28591);
2. EndLine: you don't use WriteLine() yet you use ReadLine()? That is odd. And may well indicative to the cause of your receiver problem: whatever SerialPort.EndLine is set to will be sent as terminator in WriteLine(), and will be looked for in the incoming data to determine when ReadLine() gets satisfied.
Since you did not use WriteLine() I am guessing you didn't like the endline terminator, but yet you are waiting for it to be sent in DataReceived???
It is very well possible tht your peripheral uses ASCII CR (you send it explicitly!) but never sends ASCII LF, and if the default EndLine is set to CR-LF, ReadLine will never return a thing...
Remember, a terminal emulator isn't very good at reporting non-printable characters such as CR and LF
3. The DataReceived event: this is the most misunderstood event I ever saw; people seem to think it will fire on every incoming byte. It won't. People like to think it will fire after every incoming message (whatever that means), it doesn't. Here is the one correct statement: provided some data got received (any number of bytes), it will fire at least once; everything else is speculation.
As a result, when your peripheral sends three bytes ("5" "2" CR) you might get two DataReceived events, one with data "5", the other with "2" CR.
4. the DataReceived handler should not be blocking; most examples correctly consume "whatever is available" and make sure the handler is done right away, so the thread gets freed, and a new DataReceived event can be processed. (Behind the scenes, SerialPort made sure no two handlers can be active at the same time, someting they fail to tell explicitly).
Your handler does the opposite: it contains a blocking ReadLine().
There is another weakness: as you display the datain a TextBox, you'll see at most one line, so if [5 2 CR LF CR LF] were to be received, you would see nothing, the empty line would overwrite the 52 right away.
The correct way to handle DataReceived in general is like so:
- create a buffering scheme (it will need a lock!)
- add incoming data to the buffer; this should be the only data manipulation inside the DataReceived handler;
- make sure the lock is mostly free, if not your handler becomes blocking which it shouldn't!
- create a way to process the buffer, do this outside the DataReceived handler (in a background thread), possibly signalled by the DataReceived handler.
In specific cases, a much simpler approach can work just fine. A simple case would be: only short messages (with known upperbound lenght) and a guaranteed gap in between messages. If so, I would create a DataReceived handler that is very blocking: it starts with a Thread.Sleep to make sure the message is completely received, then process it right away (preferrably with Read, not ReadLine, as that may block forever).
5. Closing the port. Quite often one has a permanent receiver, your program wants to catch whatever comes in, whenever it does. That makes it harder to close the port, as you cannot perform a Close() while a Read or Write is in progress. That would throw the exception you are getting. Quite often the solution is not to close the port at all. Or set a timeout on the port so a Read doesn't block forever, and wait for at least that time just before closing the port (don't expect the timeout to work accurately though, it can be of a lot). Of course, a receiver with a timeout, will detect a "no data" situation and may be inclined to launch another Read, a boolean should prevent that when you intend to close the port. I also have seen, but never felt the need for, code that created a background thread just to close the serial port (catching and ignoring any exception when that fails).
6. Thread safety: the doc is a joke; statics are thread safe, and the other methods aren't. If true, SerialPort would be useless, e.g. Read and ReadLine would not be allowed in the DataReceived handler!!!
In summary: it is my guess your ReadLine fails on a mismatched EndLine situation, and your program bombs on closing the port while a read is in progress.
What I tend to do except for the simplest cases (this was true long before .NET, the native serial port has similar pitfalls):
- use binary port operations (i.e. byte[]) rather than text as much as possible;
- use an explicit endline, i.e. avoid using ReadLine and WriteLine;
- use a dedicated background thread to periodically consume (i.e. move to my buffer) incoming data, foregoing DataReceived alltogether.
Two extra suggestions:
- it doesn't hurt putting difficult code inside a try-catch construct, and reporting any exception that might occur.
- I tend to always log exceptions to a text file, saves lots of time while developing a program, and helps in diagnosing a problem later on too.
Hope this helps.
Additional reading:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/e36193cd-a708-42b3-86b7-adff82b19e5e/how-does-serialport-handle-datareceived?forum=netfxbcl
https://blogs.msdn.microsoft.com/bclteam/2006/10/10/top-5-serialport-tips-kim-hamilton/
https://blogs.msdn.microsoft.com/bclteam/2006/05/26/serialport-encoding-ryan-byington/
https://blogs.msdn.microsoft.com/bclteam/2006/05/15/serialport-and-datareceived-event-ryan-byington/
modified 12-Jan-18 11:33am.
|
|
|
|
|
Luc,
Thanks for the help, it start working when I used
WriteLine
|
|
|
|
|
So that tells me:
1. the peripheral is doing something similar to ReadLine and never received a complete command!
2. your terminal emulator, which worked well with your peripheral, must be sending CR LF upon hitting Enter; that too isn't always true for terminal emulators! It probably is a program's setting.
Glad you got it solved.
Mind you, you still could get into trouble with the Close issue, e.g. when something goes wrong (e.g. the peripheral misbehaves or a cable insertion/removal) a character might be received without a full message, hence DataReceived fired and ReadLine() waiting forever, hence Close throwing.
General advice:
- increase observability by adding LEDs to external hardware, and logging to code in general;
you then might have noticed the command never got accepted;
- code defensively, with try-catch, timeout, etc.
- don't assume anything that isn't documented.
Have fun
|
|
|
|
|
How can I center the PictureBox (or other control) to the parent (or form) direct from the code? I've tried so much, but I'm not successful, I hope someone can help, grateful 
modified 11-Jan-18 18:33pm.
|
|
|
|
|
WPF or Windows Forms?
This space for rent
|
|
|
|
|
|
You could start by NOT SHOUTING AT US.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Sorry for that, my native language is not english, so my writing could look a bit rude 
|
|
|
|
|
With thanks to Pete O'Hanlon and OriginalGriff:
You can use this method to center a control in its parent control:
private void CenterControl(Control control)
{
control.Left = (control.Parent.ClientRectangle.Width - control.Width) / 2;
control.Top = (control.Parent.ClientRectangle.Height - control.Height) / 2;
}
example use:
CenterControl(pictureBox1);
|
|
|
|
|
I will test it on my project, my thanks to you and Pete O'Hanlon and OriginalGriff
|
|
|
|
|
New to C#,
The plan:
1. Parse a log file of over 250,000 records daily.
2. Storage the outcome of the file parsing somewhere (file, Array, DB, other), the average # of records is about 20,000.
3. Use a DataGrid to bind the result of the parsing and present to user.
I will like some suggestion on #2 (Pros/Cont, performance, etc.), the temporary storage to be bind to the Datagrid. Keep in mind the number of records could be 25K or more.
Thanks in advance.
|
|
|
|
|
I'd probably use a DataTable - they are designed for exactly that - or a List of a custom class.
But I wouldn't present 25,000 rows of anything directly to a user: that's just silly. Page it, filter it, search it: but just showing him the data and letting him pick the bones out is a recipe for unhappy users...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
What kind of datagrid? If in WinForms, I'd recommend virtualizing the DGV.
Why should the user look at 20k worth of data? For validation? How about only showing the stuff where there were import-errors? It's not like anyone is going to read a few pages worth of phone-book material, they'll simply click "accept" 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I've been using Basic since the beginning and VB since version 1. At an advanced age I am learning c#.
Is there a good site which explains the big picture?
I mean things like classes, methods, components, resources, how it all fits together.
I know how to write Hello World, I've written a few apps now but keep bumping into my own ignorance.
Most sites seem to start off too simple and then jump in the deep end.
Any help appreciated.
|
|
|
|
|
Generally, I'd say ignore websites - and particularly ignore Youtube tutorials - and get yourself a book (or better a course).
Both tend to be a lot better structured, introducing each subject in a streamlined way rather than dropping you in the deep end while covering all the material - a course is better because if you don't understand something you can talk to the tutor and he can explain it in different ways until you do.
Wrox, Addison Wesley, and Microsoft Press do some good ones - just start at the beginning and work your way through doing all the exercises. All of them should explain classes, methods, evente, and so on and why they are used.
But if you are proficient in VB versions above VB6, then the transition to C# shouldn't be too complicated: they both use the same .NET framework which you should be familiar with, and that means the learning curve is vastly reduced. And VB uses classes, methods, events - it's just the syntax which is rather better in C#! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thank you, much appreciated.
|
|
|
|
|
You're welcome!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
.NET Book Zero[^] is a great starting point, especially if you have some programming knowledge.
|
|
|
|
|
|
just tell me when we compare two string by == operation then does it compare by value or ref?
i read it https://stackoverflow.com/a/3678923
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/statements-expressions-operators/how-to-test-for-reference-equality-identity
but not very clear.
how to compare by ref and by value ?
i heard string intern. say if we have two string variable having same data then one string object is created and two string variable point to same memory address.
string strA = "Hello world!";
string strB = "Hello world!";
Console.WriteLine("ReferenceEquals(strA, strB) = {0}",
Object.ReferenceEquals(strA, strB));
when we check like this below way
if(strA==strB) then the comparision happen by value or by ref?
please guide me right info. thanks
|
|
|
|
|
Strings are reference types, but string comparisons are made as value types:
string a = "Hello World";
string b = "Hello";
string c = " World";
string d = b + c;
Console.WriteLine("{0}:{1}:{2}:{3}", a == d, a.Equals(d), (object)a == (object) d, object.ReferenceEquals(a, d));
Will give you:
True:True:False:False Because the first two tests use the string specific comparison, and the other two specifically do reference comparisons.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
With strings, there is another fact to consider. When the compiler can detect that they have the same value, the compiler will make sure that they have the same reference also. It can do that optimization because strings are immutable.
In the example given by OriginalGriff, the compiler did not detect that and thus the compiler created two different references.
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
That's where it gets complicated (and why I didn't mention it - he is a beginner, after all).
The compiler can detect and intern strings, but the runtime doesn't unless you specifically ask it to:
string a = "Hello World";
string b = "Hello";
string c = " World";
string d = b + c;
Console.WriteLine("{0}:{1}:{2}:{3}", a == d, a.Equals(d), (object)a == (object)d, object.ReferenceEquals(a, d));
d = string.Intern(d);
Console.WriteLine("{0}:{1}:{2}:{3}", a == d, a.Equals(d), (object)a == (object)d, object.ReferenceEquals(a, d));
Will give you:
True:True:False:False
True:True:True:True As the "new" string is now in the Intern pool.
However ... in the release version of my original code you will probably get different results, as the optimiser will likely compact that code and intern the strings anyway!
There is a good description of the intern pool here: Understanding C#: String.Intern makes strings interesting - O'Reilly Broadcast[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
