I never managed to grow long hair, or play the guitar well. So I turned my attention to important life skills such as smoking and drinking. Now as I approach my 74th (a couple of weeks hence) I try to spend more time learning useful stuff that I missed in my younger days.
As to wisdom, thanks for the vote of confidence, but I know I am far from wise.
We all (or most of us) contribute what we can here, and no one person's worth is greater than another's, apart of course, from @OriginalGriff, who knows everything there is to know.
I didn't start programming until I brought a TRS-80 computer apart from usign programmable calculators around the early 1980's.
My first introduction to assembly language was to write the letter 'A' in the middle of the screen.
I had fun with disassemblers in finding out how computer programs worked and learn a few secrets of arcade games.
There were some great games in those days and you had to be skillful to fit you game in a 16k memory space for you had a large market to sell your game.
Typing in computer code from a computer magazine started to be a hobby of mine.
There would not be a lot around in 1966 to program on. It must have been a very large mainframe computers and maybe you used hole punch cards in those days.
If your approx 70yrs old then you must have been started learning at about 17yrs old in 1966 and maybe learning C in 1988.
I'm just starting to learn C# so I have a lot of catching up to do; but in knowing the basics of computers such as loops, logic etc helps.
Yes, punched cards, paper tape, and programming by buttons on the front panel of the processor. I knew nothing about computers when I started my first job, but worked with a guy who taught me the basics. I only learned C# and .NET after I had retired, and there is still much I don't know about it.
I use to save things as bookmarks to my browser but then had a few problems and lost valuable bookmarks so I don't trust browser bookmarks. These days I tend to create shortcuts to a link and store them into a folder that I can backup. In doing this I can arrange the links into sub folders and give easy to identify names.
So start from the beginning and work out where the problem is.
Start by disabling the serial port, and adding random values in your tick handler. Does that do what you wanted - does the graph change each tick?
If it does, then start looking at the serial port.
If it doesn't, then look at the timer, and prove that's working at the interval you expect.
If it is, then look at your graphing package and work out why it's not updating.
If it isn't, then look at why.
Reduce the problem to smaller and smaller areas - it's one of the key parts of both design and debugging!
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
You need to confirm that you can RECEIVE independently of any charting; and that you can CHART, independent of any receiving. You have done neither. Charting depends (eventually) on receiving. Where to start?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
as other have said already, you should divide and conquer; do not write all the code and then come to the conclusion it doesn't work. Instead chop the task into many smaller tasks and solve them one by one.
NEVER use an empty catch; when an exception occurs, it does so because something is wrong; catching the exception and looking at it will tell you more. It is there to help you. You could display the Exception.Message with a MessageBox. It is better to display the entire Exception.ToString() result as that includes exact line numbers. And I prefer to log all exceptions to a text file, which doesn't disturb the timing aspects as much as interactive debugging. See A simple logging scheme[^]
The DataReceived event fires when one of a few bytes got received, it does not care about lines of text, or whatever constitutes a "message". And (nowhere documented) as long as one DatReceived handler is running, no more such events will happen. Now what happens when you receive a few bytes not including a NewLine? The event may fire, get to your SerialPort.ReadLine() and wait there forever.
The solution here depends very much on the specifics of your peripheral. If data throughput is low and some delay is acceptable, a work-around might be to put some delay (say Thread.Sleep(100)) just before the call to ReadLine(). And yes, that is an ugly hack, but it sometimes suffices.
You should take care of all of the above and then you may be successful!
I agree that the problem should be split into small pieces and that verifying the serial side of things would be a good place to begin.
Can we see the instructions from the arduino that actually transmit the data, the fact you are using a micro controller gives you a certain degree of control over the serial protocol.
I assume the data is being transmitted in a loop, how fast is the controller repeating the transmission loop and at what baud rate.
If the transmission is too fast then it might not be possible to process the incoming and update a chart at the same time without buffer over run, which would be pointless anyway because you would be unable to read the chart as it updated at those speeds, this can be overcome by storing the data in memory and displaying it at a slower rate but this also has its limitations.