Go Down

Topic: PLX-DAQ version 2 - now with 64 bit support! (and further new features) (Read 55215 times) previous topic - next topic


UPDATED - Further Investigation on the delay GET/SET workaround - UPDATED

I investigated which delays are really needed in the above code using an Adafruit CP2102 cable.  My starting point was 38400 baud with 3 msec delays, which had successes in 30 out of 30 previous trials.  This time I used a Windows 8.1 computer.

1. 20 new trials at 38400 baud with all delays active at 3 msec: 20 complete successes

As I had the number 53.90 in "SimpleData"!J3 and 42.42 in "Further sheet"!F6, the correct result is to print on the Arduino monitor:

Test print is 53.90

2. 20 new trials at 38400 baud with all delays commented out: 0 complete successes

16 out of the 20 answers were:

Test print is 0.00

which pointed out that a delay may be necessary before the CELL,GET command

3. 20 new trials at 38400 baud activating the delay before the CELL,GET,J3 command: 19 complete successes

The only failure was the first test

4. 20 trials at 115200 baud with 3 msec delays before the CELL,GET and CELL,GET,FROMSHEET commands: 15 complete successes. 

5. 20 trials at 115200 baud with 10 msec delays before the CELL,GET and CELL,GET,FROMSHEET commands: only 5 complete successes!

The majority of failures printed 

Test print is 53.00

6. 10 trials at 115200 baud with 100 msec delays before the CELL,GET and CELL,GET,FROMSHEET commands: 0 complete successes!

Update: If tdelay is changed from byte to integer
Result: 10/10 complete successes

7.  20 trials at 57600 baud with 3 msec delays before the CELL,GET and CELL,GET,FROMSHEET commands: 20 complete successes.

8.  20 trials at 74880 baud with 3 msec delays before the CELL,GET and CELL,GET,FROMSHEET commands: 20 complete successes.

Placing delays before CELL,GET and CELL,GET,FROMSHEET commands seems to be completely effective for rates <= 74880 baud.

Delays of 3 msec were successful for the above test, but larger delays are needed if the Excel cells read from involve lengthy calculations.

I am not sure what is happening at 115200 baud.  Perhaps it is an issue of the software serial port.  Even though the current documentation states that it works up to 115200 baud, older documentation indicated issues at that rate.


Hi SASv,

thank you very very much for all the effort you put in researching the issue and the posts you've made !! I still owe you an email as well  ;)

I will try to reproduce your results over the weekend and try to verify them. Also I might publish a demo sheet for general testing purposes thus everyone can participate. It seems to be coming down to a general Arduino issue and maybe not Excel / PLX DAQ which would be kind of hard to fix other then to use your mentioned delays.

Thanks again and I'll get back to you :)


sir, where should placed this zip code..i am not understand ?? please give steps to use it?


On the delay workaround for the CELL, GET and CELL, GET,FROMSHEET commands for 115200 baud

As indicated in the earlier post, I started suspecting that the issue at 115200 baud may be related to the software serial port I have been using.  The code below has removed it and gave the correct result (in cells J7-J11) in 18 out of 20 trials.

Code: [Select]

// 1. Open NetDevil's Excel file PLX-DAQ-v2.9.xlsm but do not connect PLX-DAQ
// (https://forum.arduino.cc/index.php?topic=437398.msg3160058#msg3160058)
// Enter a numerical value in cell J3 of sheet Simple Data
// Enter a numerical value in cell F6 of sheet Further sheet
// 2. Setting the port for the Arduino USB (in Tools), upload the sketch
// 3. With the Arduino serial monitor CLOSED connect PLX-DAQ at the same port
// 4. For repeating trials disconnect and reconnect PLX-DAQ

unsigned long baudr = 115200;  //Do not forget to change the baud rate in PLX-DAQ
int tdelay = 100;

void setup(void) {
  // 1st test of CELL,SET
  float Ans = 42;
  // 2nd test of CELL,SET
  Serial.println(F("Test print is "));
  // Test of CELL,GET
  float NotAns = Serial.parseFloat();
  // Test of GET FROMSHEET (thanks NetDevil)
  Serial.println("CELL,GET,FROMSHEET,Further sheet,F,6");
  float AnsAns = Serial.parseFloat();
  // Final printout

void loop(void) {;}

Testing results:
delay = 0 :  completely correct 0/10
delay =10 : completely correct 19/20
delay = 100: completely correct 18/20

1. Delays help but do not guarantee success at 115200
2. Failures do not seem to be an issue with the previously used software serial port


Hi SASv,

I tried to reproduce your findings but somehow I wasn't successful ... I used one and two flushs before and after each Serial.parseInt(); and also delays before and after Serial.parseInt(); But still I got mix-ups even at 30.000 baud.

Attached you can find a ZIP file which contains a sketch and an Excel sheet. In this Excel sheet there are 4 test case scenarios and the sketch will cover those scenarios. In the sketch you can set whether you want to use one or two flushs before or after Serial.parseInt(); as well as if you want to use a delay before and after Serial.parseInt(); and which amount if milliseconds it should wait.

May I ask you to try to verify your experiences with it? In the end, only 100% accuracy is acceptable. That's why I appreciate you running like 20 tries of the same text case and get 18 of 20 or so. This shows that there is no 100% accuracy yet and I have to work on improving the program.

As I am a bit short on time lately I will have to cover all the other open issues some time soon.



This version is already outdated !! Link to always most recent version of PLX DAQ v2 here:

==> https://forum.arduino.cc/index.php?topic=437398.msg3013761#msg3013761 <==

Anyways I created a new version today and even created a Beginner Guide for people to get a better understanding of how PLX DAQ v2 works and how they can start using it. It also lists all commands that are available for Arduino thus even the more experienced users might benefit from that guide :)

What's new in "Version 2.10" aka Change log:
  • I wrote a 9 pages long Beginners Guide to PLX DAQ v2 for newbies to get started with the tool.
  • Extended the CELL,SET command to be able to set cells on other sheets as well (after CELL,GET with version 2.9 ;) )
    Syntax is Serial.println("CELL,SET,ONSHEET,SheetName,Column,Row,Value"); ==> e.g., Serial.println("CELL,SET,ONSHEET,Simple Data,E,4,My Test String");
  • Modified CLEARSHEET command. It will now clear data starting at row 1. So it will clear the whole sheet as its name suggests. To clear only the data I added a new command CLEARDATA. I think the names are less ambiguous now ;)
  • Updated the default sketch to include the new commands

Backlog for next version(s):
  • find a solution for Excel crashing when moving the window around while logging. Priority: low ; Workaround: don't move window while logging ; Status: clueless...
  • solve get cell / set cell mix up reported by jl1cny here. Priority: medium; Workaround: use baud rates smaller 25.000; Status: in contact with Sam SASv directly via email to identify issue. Best guess is an issue in Arduino code with Serial.ParseInt not getting values out of buffer correctly
  • Double check if both issues above existed in PLX DAQ v1 as well. In case yes => we are screwed

Image-Link: http://www.freebie-base.de/Pics/PLX_DAQ_v2.10.png
(hosted on my server, no traffic hijack)

Quote from: Older changelogs
What's new in "version 2.9" aka Change log:
  • Extended the CELL,GET command to read cells from other sheets as well.
    Syntax is Serial.println("CELL,GET,FROMSHEET,SheetName,Column,Row"); ==> e.g., Serial.println("CELL,GET,FROMSHEET,Simple Data,E,4");
  • Updated the default sketch to include the new command

What's new in "version 2.8" aka Change log:
  • fixed an issue with the LABEL command. Columns that should labeled either TIME, TIMER or DATE where translated as well thus the column was not labeled with e.g., DATE but accidentally resolved to current system date (e.g., 21.02.2017)
  • fixed in issue with 32 bit Office versions and sleep function. Should be working on 64 bit and 32 bit versions again. Issue was reported by ankoo here
  • removed two deprecated commands from PLX DAQ v1 (RESET and CMD?) as they were of no use anymore
  • realigned source code for better readability, reused functions more often to reduce redundancy, commented out old checkbox calls from PLX DAQ v1 that are deprecated within commands
  • corrected a mistake in the comments of the default sketch (column naming)

What's new in "version 2.7" aka Change log:
  • Added a new command: ClearRange that allows for a range to be cleared in the sheet.
    Syntax is Serial.println("ClearRange,StartColumn,StartRow,EndColumn,EndRow"); ==> e.g., Serial.println("ClearRange,B,2,D,50");
  • fixed a bug when closing the form while still logging. The macro was not paused correctly but will do so now

What's new in "version 2.6" aka Change log:
  • Fixed the reset timer button (there was a useless message box implemented somehow)
  • Formatted the timer to always have 6 trailing digits
  • removed the old fashioned limit to 27 columns - now supports the thousands of columns that Excel supports (although it is getting pretty slow with too many columns)
  • Set the columns all to be aligned centrally on default and column captions to be written in bold by default
  • and well yeah - added the warning remark not to play around too much with the window during logging

What's new in "version 2.5" aka Change log:
  • Added a "Pause logging" / "Resume logging" button that can (well no surprise) stop the logging of the data without disconnecting the Arduino. The Button is enabled when connected
  • Removed the old 4 checkboxes as the functions are useless without Stamp nowadays and replaced with 3 custom checkboxes. As with old PLX DAQ v1 these checkboxes can be controlled by Arduino code: change text, check/uncheck box, read status of boxed (if checked or not). Codes changed from "DOWNLOAD" / "STORED" / "USER1" to CUSTOMBOX1 / CUSTOMBOX2 / CUSTOMBOX3. "USER2" was removed completely.
  • Moved "Reset on Connect" around a bit for better UI layout
  • Re-implemented the code for "Reset Timer" button. I don't know why I removed that anyways in version 2.1 ....
  • I added a new example sketch that demonstrates the new functions and how one can use them
  • I also rework the example codes in the custom dev points for not crashing Excel anymore - hopefully ;)
  • Added new functions to call in Excel by Arduino:
    • Beep : makes a simple beep
    • Pauselogging : stops printing logged data to the Excel sheet
    • Resumelogging: continues pasting data again
    • Stoplogging : disconnects the Arduino
    • Saveworkbook : simply saves the workbook
    • SaveworkbookAs,Filename : saves the workbook as a new copy in the same folder by the name Filename.xlsm
    • ForcequitExcel: forces Excel to close. Note: the workbook will not be saved by this!

What's new in "version 2.4" aka Change log:
  • Fixed a UI problem with Office 365
  • Implemented 2 "custom dev points" ("new line was read" and "new data row recognized") which get called by the system automatically and where custom code can be pasted and used (example included in code)

What's new in "version 2.3" aka Change log:
  • Port and baud rate not drop down box anymore but free text fields
  • Port number bug fixed thus ports > 10 can be used (max set to 256 as of modern Windows OS limit)

What's new in "version 2.2" aka Change log:
  • Enhanced 64 bit support (even better stability now)
  • Added a dropdown box to select with sheet to post to (got rid of the radio buttons)
  • Minor adjustment for faster startup of logging

What's new in "version 2":
  • Support for both Office versions 64 bit as well as Office 32 bit
  • No more installation needed! All within the workbook
  • I got rid of the selmaDAQ_Ver2.ocx and use API calls now
  • Fully compatible to all previous PLX-DAQ commands in your code!
  • Got rid of some old stuff like "Max row size of 65000" (Office limit is 1048576 rows with 64 bit) or Baud rate only up to 128000 (now supports 230400 and 250000 as well)
  • Added a direct debugging window for better testing as well as a VBA code module for testing and debugging
  • Setting for selecting where to post data (first most left sheet or currently active sheet)
  • Disabled the control boxes as Stamp object is no more in use

This version is already outdated !! Link to always most recent version of PLX DAQ v2 here:

==> https://forum.arduino.cc/index.php?topic=437398.msg3013761#msg3013761 <==


Hi NetDevil

The PLX-DAQ-Cellvalue-Manipulator-Test-v4 is impressive.  And unfortunately, what had worked best in my tests, putting delays before GET and SET commands, did not work.  (I had also tried flushes previously with mixed results, worse than adding the delays).  So, I hope your much more capable hands will come up with a solution.
CORRECTION:  See post below

And thanks for the new SET command.


Hi again NetDevil

I spoke too soon.  It seems the more involved the test the longer the delays needed before GET and SET commands. 

I used your test with the flags set:
Code: [Select]

bool useFlushPriorToRead = 0;
bool useDoubleFlushPriorToRead = 0;
bool useFlushAfterRead = 0;
bool useDoubleFlushAfterRead = 0;

bool useDelayPriorToRead = 0;
int delayPriorToRead = 500;
bool useDelayAfterRead = 0;
int delayAfterRead = 1000;
int tGETSET = 500; //place before every GET and SET

In other words, I replaced the test delays and flushes with a large delay before every GET and SET command (what had worked in my tests).

Here are the results:

38400 baud:  100% success for all tests (if I understood tests 03 and 04 correctly).
57600 baud:  100% success for all tests
74880 baud:  mostly correct but no longer 100%

Increasing the delays to 1000 did not help at 74880 baud, but the slower scroll rate helped me verify continual success at 57600 baud.

In my own program I had failure of a SET command at 9600 baud (it did not show up in the raw data logger).  It required a 500 msec delay (200 did not work) in the line above it to work.

UPDATE: Further testing showed that placing a 30 msec delay before each of the 8 GETs and SETs of the test gave continual success at 38500 and 57600 baud.  However, even increasing the delays to 10000 msec did not make the test continually successful at 74880 baud.

Finally, another clue to the puzzle might be what I observed in a program I am developing.  The code involves 9600 baud communication and has several GETs and SETs in the infinite loop.  After several iterations there is a final GET and SET (the infinite loop "ends" with a very long delay).  The last SET failed until I increased the delay before it to 500 msec.  At that time some of the loop GETs and SETs had 100 msec delays.  However, when I decreased them to 3 msec, the final SET again failed.  To return to success I had to increase its delay to 800 msec.  So there seems to be a cummulative effect from prior GETs and SETs.   

FURTHER UPDATE: Increasing the stop bits to 2 (Serial.begin(baudRate,SERIAL_8N2); ) might help a bit.  It is no solution, but it seems to increase the frequency of correct results.


Hi SASv,

thanks once more for the intensive testing you have done :) I implemented your suggestion into the cellvalue manipulator (500ms delay for every GET and SET) and it did indeed do the trick for higher baud rates (I had some successful test runs with 60.000 baud :) ).

I am still kind of clueless why it is working this way though. Having a delay before GET/SET shouldn't hamper the read later on .... I mean, why pause, then send a GET, then read directly and it is ok? I would understand if we need a delay between the GET and the read to get the buffer free. Or use a flush on Arduino side or Excel side before the read / send ... crazy ....

Its sad to see such large delays are needed since they really slow down the overall performance. However using "only" standard DATA,Value1,Value2,Value3 commands never produced any issues even at highest baud rates so far and I guess thats the most important part.
I will add a note to my Beginners Guide to be careful with CELL,GET and CELL,SET and using at least some delays prio to it (between 100 ms and 500 ms) thus everyone should at least be aware of the issue. I need to update that guide anyways to format chapter headings and include a table of contents.

That adding up of needed delays based on the number of prio GETs/SETs is crazy and confusing as well. One could write a bachelor thesis I guess in order to figure out what the exact needed value for your final GET/SET must be based on how many prior GETs/SETs were used with which delay :D

You definitely earned yourself some Karma points (at least that is all I can offer right now over the internet :) )

I might try some times querying the checkbox values to see if it is the same behavior (well I guess it will be). 

One more thing I wanted to ask you about: when posting code please use the code tags for better readability. It helps a lot especially with the long code statements ;)

Code: [Select]
[ code]put code here[/ code]

and remove blanks


P.S.: I will try to give you an answer to your email within the next days as well! I promise.


Hi NetDevil:

I will corroborate your statement "However using "only" standard DATA,Value1,Value2,Value3 commands never produced any issues even at highest baud rates so far and I guess thats the most important part."  Also the ClearRange command has never failed me.  And a lot of programs do not require high baud rates.  Furthermore, in most cases 500 ms delays are overkill.  I run successfully your test with delays as low as 30 ms at 57600 baud.  My recommendation to users is to start with a small delay, test it, and increase it only if it proves unsuccessful.  I also recommend increasing the stop bits to 2 (Serial.begin(baudRate,SERIAL_8N2); ).

The class I am designing has benefited tremendously from PLX-DAQ version 2.  I am very grateful to you.

P.S.  And thanks for the information about code tags.  I will be using them from now on :) .


hey, thank you for all the work, I will test it later for my project


Hey guys. Well it's been a while - nearly 2 months! But there is a new version available now! I did some groundwork and tried to tidy up a lot of code but in the end I'm just half done ... that's why I thought I might release the updates I already have and keep the rest for later ;-) And well there are quite a few new features!

What's new in "Version 2.11" aka Change log:

  • Extended DATA command by the parameter AUTOSCROLL_XY. Autoscroll will automatically scroll your Excel sheet along with each new row of data which is read and posted. XY can be replaced by any number (e.g., 20) to control how many additional lines should be shown above as well during scrolling.
  • Added a new function: GetRandom(min,max). It basically just returns a random number between min and max. Very useful if you need a random number for Arduino's randomSeed() to be initialized
  • Added several features to the direct debug window. The size can now be increased or decreased (to a certain extend), content can be cleared and you can decide what you want to log: incoming data, outgoing data, system data. Also a time stamp can be added if wanted.
  • Added a default line break after all data send to the Arduino. Thus no more delays are necessary before or after get/set calls. In order to read incoming data one should use either Serial.readStringUntil(10); or Serial.readStringUntil(10).toInt(); or Serial.readStringUntil(10).toFloat(); from now on
  • Optimized the way Excel processes multiple incoming lines of data for better performance
  • There are some new parameters which can be changed on the (hidden) settings sheet in Excel. Those "Expert Configs" should be handled with care. They are about the buffer sizes for your COM port. In case you decide to spam massive amount of data to Excel and increase the baud rate you might experience data loss. Try increasing the buffer sizes then.
  • Added a "PowerDemos" directory with some nice (at least I think so) demos. First demo is a moving self updating graph visualizing data from the Arduino.
  • Updated the Beginners Guide to reflect all new commands - and optimized the formatting as well
  • Updated the default sketch to include the new commands

Backlog for next version(s):
  • find a solution for Excel crashing when moving the window around while logging. Priority: low ; Workaround: don't move window while logging ; Status: clueless...
  • Double check if issue above existed in PLX DAQ v1 as well. In case yes => we are screwed
  • Rework API calls and general COM port communication handling for better stability. Very promising example to be found here. Works with up to 2.000.000 baud

Guideline to migrate from old version to new one ==> see Beginners Guide attached

Image-Link: http://www.freebie-base.de/Pics/PLX_DAQ_v2.11.png
(hosted on my server, no traffic hijack)

Quote from: Older changelogs
Changelogs of older versions can be found in the attached document "__Old-Versions-changelog.doc"



Thanks a lot for the PLX_DAQ updates, it's working like a charm. You'll probably be able to tell I'm a newbie by the nature of my question, but where in the demo code exactly does it get the data for Date, Time, Timer, and milli? I'm trying to modify your demo to print temperature, however I get this:


I modified the code a bit but left pretty much everything intact. https://pastebin.com/dNMuHbvQ


Hi scardu,

thanks a lot :) No problem answering your questions.

1. The buzzwords "Date, Time, Timer" are switched to actual date, time and runtime in the Excel on your PC - simply because Arduino does not know the current date and time ;) Timer is just a counter for how long PLX DAQ is already receiving data.

2. On the other hand "millis()" is an Arduino function counting how long the Arduino is already running. That is done before sending the information to PLX DAQ.

3. You defined four columns by using
Code: [Select]
Serial.println("LABEL,Temp1,Temp2,Temp3,Temp4"); however when passing data from Arduino to PLX DAQ you send him 9 information
Code: [Select]

String transferred is (concatenated): "DATA,Temp1,Temp2,Temp3,Temp4Probe01,Probe02,Probe03,Probe04,SCROLLDATA_20"

Split by each comma (",") that is:

  • DATA = buzzword an correct
  • Temp1 = fix string instead of value
  • Temp2 = fix string  instead of value
  • Temp3 = fix string  instead of value
  • Temp4Probe01 = fix string  instead of value, missing "," and directly followed by measured value
  • Probe02 = measured value
  • Probe03 = measured value
  • Probe04 = measured value
  • SCROLLDATA_20 = wrong buzzword for scrolling. My bad, was a leftover in my demo sketch. AUTOSCROLL_20 is correct. It is a buzzword and therefore won't be printed to the sheet by PLX DAQ

You should use the following string:

Code: [Select]
Serial.println( (String) "DATA," + sensors.getTempC(Probe01) + "," + sensors.getTempC(Probe02) + "," + sensors.getTempC(Probe03) + "," + sensors.getTempC(Probe04) + ",SCROLLDATA_20");

Thus you only transfer 6 information. Therefore 2 are buzzwords (DATA and AUTOSCROLL) and the other 4 are exactly what you defined as columns in the first place :-)

Your full code is sufficient with:

Code: [Select]

#include <OneWire.h>
#include <DallasTemperature.h>
#define ONE_WIRE_BUS_PIN 2

OneWire oneWire(ONE_WIRE_BUS_PIN);
DallasTemperature sensors(&oneWire);
DeviceAddress Probe01 = { 0x28, 0xFF, 0x73, 0x01, 0xA2, 0x16, 0x05, 0x24 }; // 1
DeviceAddress Probe02 = { 0x28, 0xFF, 0xA4, 0xF0, 0xA1, 0x16, 0x05, 0x31 }; // 2
DeviceAddress Probe03 = { 0x28, 0xFF, 0x99, 0x10, 0xA2, 0x16, 0x05, 0xF4 }; // 3
DeviceAddress Probe04 = { 0x28, 0xFF, 0x4A, 0x0A, 0xA2, 0x16, 0x05, 0xC7 }; // 4
void setup() {
  // open serial connection

  Serial.println("CLEARSHEET"); // clears sheet starting at row 1
  // define columns
  /*-----( Temp Probe Setup )-----*/
  sensors.setResolution(Probe01, 10);
  sensors.setResolution(Probe02, 10);
  sensors.setResolution(Probe03, 10);
  sensors.setResolution(Probe04, 10);

void loop() {

  /*-----( Temp Probe Loop )-----*/


  Serial.println( (String) "DATA," + sensors.getTempC(Probe01) + "," + sensors.getTempC(Probe02) + "," + sensors.getTempC(Probe03) + "," + sensors.getTempC(Probe04) + ",SCROLLDATA_20");
void getTemp(DeviceAddress deviceAddress)
  float tempC = sensors.getTempC(deviceAddress);

If you have any other questions please feel free to ask :-)


First, thank you so much for providing this upgrade for PLX-DAQ, software I've been using in it's original form.  Now I can use it with WIN10 and 64 bit. 

On page 9 of your guide, you reference the Sub "DataReady".  I'm a novice to VBA (but trying to learn), and having gone through all of the code I am able to see in the VBA Editor for V2.11, I cannot find this subroutine.

I am creating an application involving rapid DAQ data transfer from Arduino to Excel, and I've found it necessary to disable Excel auto-calculate during data transfer to avoid crashing Excel.  So I want to add the capacity to disable it from Arduino during data transfer and then re-enable it after completion using Application Calculation = xlManual / xlAutomatic in VBA, and that is why I was searching for the sub you referenced as a place users can add commands.

As a workaround, I am thinking about designating a criterion worksheet cell which Arduino will control the value of and add VBA code in the subject worksheet to switch autocalculate contingent upon that value. 

I have not carefully read all other entries in the thread and apologize if this has already been covered. Thanks again, NetDevil, for this awesome contribution !

Go Up