Just a wild guess... (anything else is hard without seeing the code :): your script might be trying to write to a closed socket (closed by the device). This generates a SIGPIPE signal, whose default handler action is to abort the program (assuming you're on Unix).

Consider this example

#!/usr/bin/perl
use strict;
use warnings;
use IPC::Open3;

# uncomment to handle SIGPIPE yourself
# $SIG{PIPE} = sub { warn "Broken pipe\n" };

open3(my $wh, my $rh, undef, qw'echo foo');

# tiny delay, so the command _has_ closed its stdin in the meantime
select undef,undef,undef, 0.2;

print $wh "foo\n";  # expected to fail in this case
close $wh;

print "done.\n";    # not reached, except when handling SIGPIPE yourse
+lf
[download]

When you run this as is, it quits without printing "done.", because it's being terminated before. When you setup your own SIGPIPE handler, OTOH, you'd get your (self-generated) "Broken pipe" warning message, followed by "done."

(Note that this sample snippet would not exit with $? being zero (so this simple theory doesn't quite fit your case), but there are other circumstances conceivable where it might...)

How to debug?  You could run your script under strace (a tool I tend to recommend at least twice a week here :) in order to figure out what your script is doing last... This would likely prove helpful anyway, even if my above theory is wrong.

E.g. in the above sample case, you'd see something like this at the end of the trace

$ strace ./747486.pl
(...)
select(0, NULL, NULL, NULL, {0, 200000}) = ? ERESTARTNOHAND (To be res
+tarted)
--- SIGCHLD (Child exited) @ 0 (0) ---
select(0, NULL, NULL, NULL, {0, 200000}) = 0 (Timeout)
write(8, "foo\n", 4)                    = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
[download]

(notice the write(8, "foo\n",... line which returns with EPIPE)