Mega 2560 - 5002 error

[Kristoff2]

Hey,

Can you both make sure that the baud rate set in Windows, LabVIEW and in the Arduino firmware all match.  If that does not work try increasing the timeout shown below inside the Init VI:

Please let us know if this helps.

[Joan_Ballart]

Thank you Sammy

Increasing the time out, I resolved the problem

[Kristoff2]

Espavi,

I'm glad to hear that.  I've not run into this issue myself with the 2560 but I know at least one other user has.  When I get a chance I'll look into this and see why this is the case.  For now we will just add this info to the documentation.  Thanks for helping us iron this out.

-Sam

LIFA Developer

[The_Big_Pill]

Iam having the same problem, but I believe the problem starts at the installation of the usb drivers. I am using a KTA-223(Relayduino USB/RS485 IO Module 12VDC).

Which is an Arduino board from Ocean Controls that is using a ATMega 328.When installing the driver, my com port never shows up as Arduino and Vist 64 bit will

not allow me to change the driver(} Vista has determined that the best drivers are installed"). During the initalze function the vi is expecting the Arduino identifier.

Does anyone know how to over ride changing the usb drivers in Vista 64.

[Kristoff2]

TheBigPill,

You can specify the COM port by creating a constant on the VISA Resource input of the Init VI.  If you specify the COM port manually the arduino does not need to show up with 'Arduino' in its name in your OS.

-Sam

LIFA Developer

[Mirash]

Hello All,

I am also facing a similiar issue.

When I am running the Init VI, its sending the the vi is sending the Sync Characters as  "FF00 0000 0000 0000 0000 0000 0000 FF"  Iunderstand each two digit corresponds to one byte. And with this I was running into Timeout Error 5002.

When I later investigated with some Serial.Print commad to probout I found that the program reads only the first fifteen characters. i.e  " FF00 0000 0000

This screws all the checksum and initial character calculations.

I am notsure how to proceed from this.

Any help towards this will be highly appreciated.

The modified Checkcommand code is given below.

int checkForCommand(void)

{

  int bufferBytes = Serial.available();

  if(bufferBytes >= COMMANDLENGTH)

  {

    // New Command Ready, Process It 

    // Build Command From Serial Buffer

    for(int i=0; i<COMMANDLENGTH; i++)

    {

      currentCommand = Serial.read();      

    }    

    processCommand(currentCommand);    

     Serial.print("Data Received 1");

     for(int i=0; i<COMMANDLENGTH; i++)

    {

      Serial.print(currentCommand,BYTE);    

    }   

     return 1;

  }

  else

  {

     Serial.print("Data Received 2\n");

     delay(5000);

    return 0;

  }

}

Regards,

Mirash

[Kristoff2]

Mirash,

The sync packet that you are referring to is correct as sent (0x FF00 0000 0000 0000 0000 0000 0000 FF).  This packet is 15 bytes long with a header (0xFF) a command byte (0x00) 12 argument bytes (all 0x00) and a checksum (0xFF).  This is all correct and expected.  The original Arduino firmware buffers the serial input and waits for 15 bytes to be recieved.  Once 15 bytes are recieved and buffered it checks to see if the bytes form a valid packet.  If you are connected to your arduino via USB the arduino is reset by the VISA open vi so the first 15 bytes should be synchronize correctly and form a valid packet.  If you are connected via RS232 or wirelessly we have no idea what is already in the serial buffer or what state the arduino is in.  In this case the firmware will check to see if the 15 byte packet matches the expected format.  If it does LV and the Arduino have succesfully synchronized and your program can continue. If not the Arduino clears its serial buffer and tells LabVIEW to try again.  This continues until LabVIEW and the Arduino have synchronized correctly or a timeout occurs.

I have an Arduino Mega 2560 here and have never had any trouble connecting to it via USB with the 'out of the box' firmware.  I know some users are having trouble connecting to the MEGA 2560, and typically increasing the timeout in the intit VI solves this issue.

I hope this helps.  Let us know if you still have trouble connecting and we will see what we can do to sort it out.

Thanks,

-Sam

LIFA Developer

[Mirash]

Hi Sam,

Thank you...

Actually.. I followed a wrong procedure.

Initially, I couldnt get my arduino establish communication. So What I did like, copied the Hex Packet to Arduino Serial Monitior or Basic Serial Read write example and tried to sent it and Arduino read only the first 15 characters. This made all the confusion.

Actually the packet were sent as ASCII characters from the serial monitor. That made all the trouble.

After some series of troubleshooting I found the actual problem is the boot up time.

When I modified this delay... all the problems got sorted out..!!

Now I am able to use the toolkit.

Thank you for the support.

Mirash

[Ambient_Temp]

I feel your pain with the 5200 error now    I've been using a Deumilanove for a while now with no problems, but yesterday I upgraded to a Mega 2560 and cannot get it to work with any of my VI's, i get a 5002 error in the Init VI.  I changed the timeout to 3000, then 5000 and i still get the 5002 error.  Once i plug my Deumilanove back in, everything works.

*edit a few days later*

I rebuilt my VI from scratch with the same layout except i set the USB delay in the "INIT.VI" to 10000ms and i'm still getting the 5002 error, but now after i click ok/continue on the 5002 Error windows that pop up my VI starts to run just fine  and does not get any 5002 errors again until i hit stop and restart the VI.

[Mad_Mattho]

I get the same error, fixed it by setting my baud rate back to 9600 in Labview VI, in arduino code and in windows com port settings and now works fine, none of the fixes mentioned above made any difference for me, I was waiting 20 sec for timeout in init VI but still just timed out.

Not real cool for out of the box installation to glitch like this for so many of us, seems like a serial sync issue needs to be ironed out...

Apart from that, this is cool - now we just need to create a "compile for arduino target" function and get some cheap embedded functionality from labview, the price of deployment options has always been an issue for me choosing to use labview for basic embedded tasks (that an arduino can handle if programmed properly).