Hi there guys,
sorry for posting late, it will always be a bit more time before I can reply nowadays. Anyways, let's get to the issues:
@TonyParakka:
thanks buddy, it is always good to know the software can help people with their ideas 
Using the Autoplotter is fantastic. Very few people seemed to have used that yet.
The way I use the Autoplotter in my example is to move the data set of the graph around to only display the latest values. I never thought about a way before to move the data like a LIFO system around. I can think of several ideas now, some being more complex or less performant then others. The "best" one (although not the prettiest one) would be to use the CustomDevPoint to check if more then 240 data rows are already receiverd, and in case yes, put the new data to row #242 and delete row #2. That way you would have just the correct amount of data. Might be that the graph's data set will not cope well with rows being deleted, therefore I guess it would be best to rewrite the data set anew every iteration as well (to use e.g. B2 to B242).
I hope this will work for you as an entry point to coding things for the time being.
Your second question regarding WPS Office I have no idea. Never used that software. Does it run on Windows? PLX DAQ highly makes use of Windows API calls and therefore has a huge dependency on the platform...
@jdechow:
Hi Hannes, and thanks for the feedback, much appreciated
You are right with what you figured out: too much data is not being supported by the current version of PLX DAQ. Every ms will flood the inbound API call. Are you really sure you need that much data? I mean .... can you even handle that on the human side 
?
Maybe you could collect the data in Arduino every ms, make a meridian / middle value of it every 50ms and send that to Excel?
To reduce overhead you could also collect e.g. 10 data in an array and send array to Excel every 10ms (thus the amount of communication gets reduced). But you have to parse the array on Excel side and split the values one by one yourself (although the PC is generally capable of processing that little bit of operation).
Last idea would be to get back to the original Serial.print without using the (String)-converter. This will mainly save ressources on the Arduino side but could maybe improve stability as well since communication might be smoother (because Arduino is quicker in responding / acknowledging to send data).
Please revert back in case you have any problems.
Kind regards
Jonathan