PilotinControl:

Sorry I've not gotten back to you earlier. Anyway, let's take a look at a few things:

• You don't need the "-w" since we're doing "use warnings":
  #!/usr/bin/perl -w
• If you'd keep your code nicely indented, you wouldn't need lines like:
  } # END SUB
  because everything would be nicely aligned so you can see it.
  I typically don't add comments to the end of blocks like this. When I do, it's because the block is too long to see both the top and the bottom on the screen. Keeping your functions short and nicely indented is better.
• I put the setup_serial_interface(), is_serial_data_ready() and handle_serial_data() routines there to give you nice places to hook in your code. The code in those routines that I provided was just faked to give you an idea of how it works.
  In any case, it looks like your problem is how you're using these routines:
  • is_serial_data_ready() - should return a true value if there's some serial data that's ready for you to handle. Since you're not using the @serial_data array to hold incoming commands, it's never ready, so it'll never call the handle_serial_data() function.
    It looks like you only want to process completed lines from the serial port, so I rearranged some of your code and tried to build an appropriate function for you: It stores partial command lines in $serial_input, and when it finds an end-of-line character, it moves the completed command to @serial_data.
  • handle_serial_data() - should process the completed commands that are ready (in @serial_data).

So, when I made appropriate edits, I get something as shown below in the "read more" tag. Note: I don't have many of the packages installed, so I can't actually test the code, so there may be a few bits you'll need to look over:

Update: I see after I posted the node that dasgar has already suggested the notion that you have a buffering problem.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Ok the good news is your revised code works the same...however the data coming from the arduino isnt getting displayed....and normally the: Incoming Data: line gets displayed when its polling for data...that doesnt happen...I must point out this is Windows 10 on an Asus Touchscreen tablet with Keyboard....I am not sure if that makes a difference...I do get the incoming data when I connect Putty to the arduino and I push the button.

PilotinControl:

I don't know anything about Win32::Serial, nor how it may interact with Windows 10. I'd suggest sprinkling a few print statements in locations to see what the code is doing.

The first one I'd suggest is to put a print statement immediately inside the while loop:

my $are_we_done_yet = 0;
while (!$are_we_done_yet) {

    print "loop\n";

    # Check for console activity
    my $con_key = ReadKey(-1);
[download]

This way, we can see if the loop is operating correctly. However, it'll quickly fill your screen up. So if that's working OK, you'll want to take it out again after checking.

Next, we can add a couple print statements to is_serial_data_ready, to see what it's doing:

sub is_serial_data_ready {
    print "is_serial_data_ready: enter\n";

    # Non-blocking read: otherwise, we'll hang up here!
    my $c = $port->input;

    print "is_serial_data_ready: got <$c>\n";

    # Process the incoming characters
    for my $char (split '', $c) {
        print "is_serial_data_ready: char '$char'\n";
        if ($char eq "\n" or $char eq "\r") {
            print "is_serial_data_ready: end-of-line found\n";
            # End of line found, add current line to buffer
            # (unless it's empty)
            if ($serial_input ne '') {
                push @serial_data, $serial_input;
                # start a new blank line
                $serial_input = "";
            }
        }
        else {
            # Just a normal character, add to the input
            $serial_input .= $char;
        }
    }

    # Returns true if there are any completed lines to handle
    print "is_serial_data_ready: ", join(" // ", @serial_data), ".\n";

    return scalar @serial_data;
}
[download]

This way, you can see if it's actually entering the is_serial_data_ready function. If so, you can see if there's any time lag on the input statement, and whether anything ever shows up in $c. It'll also show if the characters are building up into statements or not.

The idea is to put some print statements in various locations to verify that the program is operating as you expect it to. Normally, I'd suggest using the perl debugger, but this trick should help you get started along finding the problem.

Since you say it operates differently between Windows 10 and Windows 7, I'd try to first concentrate on finding out just what the difference is. From there, it may give a clue on what to research to find the problem.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

Is vista 32bit and win7 64bit? if so see here Win32::SerialPort finally fixed for 64 bit Perl

Windows 7 and 10 are 32-bit OS operating on a x64 system.

My first thought on debugging would be to log all of the incoming/outcoming communication and check the logs as a way to verify what is actually being sent and received. I didn't see anything in Win32::SerialPort's documentation or the documentation for Win32API::CommPort (which Win32::SerialPort is based on). The logging options are clearly documented for Control::CLI, which uses Win32::SerialPort on Windows for serial port communications. If you don't want to switch over to use Control::CLI, you can check out its source code to see how its doing the logging.

My next thought would be to look at timeouts and buffering. For the timeouts aspect, check out the last portion of the Configuration and Capability Methods section of the Win32::SerialPort documentation. It's been a long time since I worked on code using Win32::SerialPort, but I remember having issues related to timeouts.

I downloaded a serial monitoring program and I can see the packets coming and going to the Arduino when I run my script....the sending is fine....the receiving is not being acknowledged...I tried changing the timing to read the data coming it...that did not help any.

I downloaded a serial monitoring program and I can see the packets coming and going to the Arduino when I run my script

Based on that description, you have confirmed that "something" is being sent from both sides. If you can get logging going from your Perl code, that would help you to verify that your code is actually sending what you think it is sending and verify exactly what it is receiving. This will help you to catch issues such as extra/missing white space characters (like carriage returns and line feeds) in what you send. By verifying what your code actually receives, you can debug the portions of your code that is reading the data sent from the device by seeing if it is processing the incoming data properly.

Another debugging method would be to use something like putty to manually connect to the device to try to interact with it manually. If that's not working, then there might be other issues that need to be addressed first.

I tried changing the timing to read the data coming it

Have you looked into the buffering aspect of things?

Another thing you can check is to see if you're using the same versions of Perl and the Win32::SerialPort module on both systems.

Crossposted to StackOverflow. Crossposting is acceptable, but it is considered polite to inform about it so that efforts are not duplicated.