PLX-DAQ version 2 - now with 64 bit support! (and further new features)

Projects Interfacing w/ Software on the Computer
61

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:

42.00
Test print is 53.90
42.42
DONE

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

16 out of the 20 answers were:

42.00
Test print is 0.00
53.90
DONE

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

  1. 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

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

  2. 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

42.00
Test print is 53.00
942.42
DONE

  1. 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

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

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

REVISED CONCLUSION
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.

62

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 :wink:

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 :slight_smile:

63

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

64

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.

// 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) {
  Serial.begin(baudr);
  Serial.println("ClearRange,A,1,F,100");
  Serial.println("ClearRange,J,7,J,11");
  delay(tdelay);
  delay(tdelay);
  // 1st test of CELL,SET
  float Ans = 42;
  delay(tdelay);
  Serial.print("CELL,SET,J7,"); 
  Serial.println(Ans);
  delay(tdelay);
  // 2nd test of CELL,SET
  Serial.print("CELL,SET,J8,"); 
  Serial.println(F("Test print is "));
  // Test of CELL,GET
  delay(tdelay);
  Serial.println("CELL,GET,J3");
  float NotAns = Serial.parseFloat();
  delay(tdelay);
  Serial.print("CELL,SET,J9,"); 
  Serial.println(NotAns);
  // Test of GET FROMSHEET (thanks NetDevil)
  delay(tdelay);
  Serial.println("CELL,GET,FROMSHEET,Further sheet,F,6");
  float AnsAns = Serial.parseFloat();
  delay(tdelay);
  Serial.print("CELL,SET,J10,"); 
  Serial.println(AnsAns);
  // Final printout
  delay(tdelay);
  Serial.print("CELL,SET,J11,");
  Serial.println("DONE");
}

void loop(void) {;}

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

CONCLUSIONS

  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
65

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.

Greetings

PLX-DAQ-Cellvalue-Manipulator-Test-v4.zip (139 KB)

66

=============================================================
This version is already outdated !! Link to always most recent version of PLX DAQ v2 here:
==> PLX-DAQ version 2 - now with 64 bit support! (and further new features) - Interfacing w/ Software on the Computer - Arduino Forum <==
=============================================================

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 :slight_smile:

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 :wink: )
    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 :wink:

  • 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)

1162×761 103 KB

=============================================================
This version is already outdated !! Link to always most recent version of PLX DAQ v2 here:
==> PLX-DAQ version 2 - now with 64 bit support! (and further new features) - Interfacing w/ Software on the Computer - Arduino Forum <==
=============================================================

Beginners Guide to PLX DAQ v2.doc (168 KB)

PLX-DAQ-v2.10.zip (284 KB)

PLX-DAQ-v2-DefaultSketch.ino (2.97 KB)

PLX_DAQ_v2.10.png
PLX_DAQ_v2.10.png1162×761 140 KB

67

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.

68

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:

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.

69

Hi SASv,

thanks once more for the intensive testing you have done :slight_smile: 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 :slight_smile: ).

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 :smiley:

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

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 :wink:

[ code]put code here[/ code]

and remove blanks

Greetings!

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

70

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 :slight_smile: .

71

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

1 Like
72

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 :wink: 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.
    Please note: AUTOSCROLL feature is available only in Office 2013 and newer. In older versions the command will be ignored by PLX DAQ.
  • 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)

1326×762 111 KB

PLX-DAQ-v2.11.zip (502 KB)

PLX_DAQ_v2.11.png
PLX_DAQ_v2.11.png1326×762 136 KB

PLX-DAQ-v2-PowerDemos-v01.zip (193 KB)

Beginners Guide to PLX DAQ v2 (rev1).doc (188 KB)

__Old-Versions-changelog.doc (44.5 KB)

PLX-DAQ-v2-DefaultSketch.ino (3.94 KB)

73

@NetDevil

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:

[Album] imgur.com

I modified the code a bit but left pretty much everything intact. /* * Demo sketch for new "PLX DAQ v2" * including most all common commands t - Pastebin.com

74

Hi scardu,

thanks a lot :slight_smile: 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 :wink: 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 Serial.println("LABEL,Temp1,Temp2,Temp3,Temp4"); however when passing data from Arduino to PLX DAQ you send him 9 information

Serial.print("DATA,Temp1,Temp2,Temp3,Temp4");
Serial.print(sensors.getTempC(Probe01));
Serial.print(",");
Serial.print(sensors.getTempC(Probe02));
Serial.print(",");
Serial.print(sensors.getTempC(Probe03));
Serial.print(",");
Serial.print(sensors.getTempC(Probe04));
Serial.print(",");
Serial.println("SCROLLDATA_20");

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:

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 :slight_smile:

Your full code is sufficient with:

#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.begin(9600);

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

}
 
void loop() {

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

  sensors.requestTemperatures();
  getTemp(Probe01);
  getTemp(Probe02);
  getTemp(Probe03);
  getTemp(Probe04);

  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 :slight_smile:

75

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 !

76

Hi John,

thanks a lot for your feedback :slight_smile: great to hear the software is in use and people get along with it.

Regarding your question you are right with the reference to DataReady on page 9, but the real reference on that page is the "CustomDevPoints". DataReady is called for each new line read by Arduino and is then checking for the common standard commands (such as DATA, BEEP, LABEL among others).

The custom DevPoints however are triggered in parallel and allow for any user desired action without effecting the standard code.

In your case, take a look at the following code in "cmdConnect_Click" routine.

'## Pass data to CustomDevPoint - if function returns "true" pass to DataReady
If (CustomDevPointLineRead(Target)) Then
   Call DataReady(Target)
End If

This code is executed every time a new line is read - and before the read information is passed to DataReady to check for the common standard codes the custom DevPoint "CustomDevPointLineRead" is called with the same information read (stored in "Target").

In "CustomDevPointLineRead" you could do something like this:

Private Function CustomDevPointLineRead(newLine As String) As Boolean

   CustomDevPointLineRead = True

   if ( newLine = "YourCommandToStopAutoCalcing" ) then
      Application.Calculation = xlManual 
      CustomDevPointLineRead = False
   end if

   if ( newLine = "YourCommandToStartAutoCalcing" ) then
      Application.Calculation = xlAutomatic
      CustomDevPointLineRead = False
   end if

End Function

Setting CustomDevPointLineRead = True in the beginning will result in the function to be true and thus the data will be passed to DataReader. In case one of your commands is recognized (e.g., "YourCommandToStopAutoCalcing" or "YourCommandToStartAutoCalcing") the Excel-VBA codes are executed. Afterwards CustomDevPointLineRead is set to False because well, the data read does not need to be passed to DataReady because your code won't be recognized by DataReady anyways.

In you Arduino code you can then use:

Serial.println( (String) "YourCommandToStopAutoCalcing" );

or

Serial.println( (String) "YourCommandToStartAutoCalcing" );

The question wasn't asked yet so no worries. CustomDevPoints weren't used much until now and the chapter in the Beginners Guide isn't very complex yet. Also because using custom DevPoints isn't much of a beginners part but more rather an advanced thing :wink:

In case you have any further questions just ask, I'll be there!

Greetings

Net^Devil

77

Thanks for the very unexpectedly fast reply, Net Devil !

I understand the route you've outlined, and I'll will try to implement it. That will be a much better solution than the one I was contemplating.

It turns out that my failure to locate the critical portions of the code was due to my unfamiliarity with VBA -- I was simply double-clicking to access object code, and when I did that for frmStampDAQ, all I got was the ActiveX graphic. I just now tried right-clicking and selecting "view code", and as you might imagine, there it was all along ! :slight_smile:

I'd been limited to using PLX-DAQ on an old netbook that has XP on it as all my other boxes run 64bit Win10 now. So what you've done breathes new life into this unique software, and your inclusion of capability for users to further modify your version to accommodate nuances of their projects makes it even better.

Thanks again, and if you don't hear further from me, it means I was successful in implementing your suggested path.

I elected to add two Cases to the list, CALCON and CALCOFF with auto calculate normally off. After transfer of 1200 data sets in 60 seconds, I send the "on" command, wait 3 seconds and then turn it off again to wait for the next trigger event. Works perfect ! Your work opens up a wide range of possibilities for Arduino to effect execution of VBA code within the rich Excel environment.

78

Hello !! i need help with my code....you did really great job but i don't understand how to merge this with my code...my code is simple so please if you can help me i need to put Voltage and sensorvalue in excel file

void setup() {
Serial.begin(9600);
}

void loop() {
int sensorValue = analogRead(A0);
float SensorVoltagedc = sensorValue * (5.0 / 1023.0);
float Voltage = SensorVoltagedc * 200;

Serial.print("DC NAPON= ");
Serial.println(Voltage);

Serial.print("Napon na ulazu= ");
Serial.println(SensorVoltagedc);

Serial.print("Biti= ");
Serial.println(sensorValue);

}

79

Hi Moki995,

a simlar question has been answered by me here ==> PLX-DAQ version 2 - now with 64 bit support! (and further new features) - #74 by NetDevil - Interfacing w/ Software on the Computer - Arduino Forum.
Please take a look there as well as the Beginners Guide I wrote and attached to the most recent version 2.11.

In general you are still using you Arduino IDE SerialMonitor print and println commands. For PLX DAQ you must define your LABELs first, followed by each new data set having a DATA command at the beginning. It is really easy to use once you get the syntax :slight_smile:

Greetings

Net^Devil

80

Serial.println("CELL,SET,G2,lvdtmin") is putting "lvdtmin" at G2, not the value stored in lvdtmin. This syntax comes from the Beginners' Guide section 6a.

Variants that place the value of the variable in the specified cell (as indicated earlier in the Guide):

Serial.println((String)"CELL,SET,G2," + lvdtmin);

Serial.println("CELL,SET,G2," + (String) lvdtmin)

Serial.print("CELL,SET,G2,");
Serial.println(lvdtmin);