in reply to Cannot write to, or read from, the SerialPort

01. Simply put - Thank you haukex and Marshall.

02. Yes, adding a 'sleep()' Command below each '$port->write*()' solved my Dilemma. However, I used 'Time::HiRes' - usec() Function for delays less than 1 Second.

I also see the usefulness of the ''IO::Termios' Module' Functions.

Below is a complete Code Example:
#!/usr/bin/perl #use strict; #use warnings; use Device::SerialPort; use Time::HiRes qw(usleep); sub Handle_FTdx1200{ my $delayValue=100000; my $port = Device::SerialPort->new("/dev/cu.usbserial"); $port->databits(8); $port->baudrate(4800); $port->handshake("rts"); $port->parity("none"); $port->stopbits(1); $port->write_settings || undef $port; $port->write("FA;"); usleep($delayValue); my $VFOA=$port->read(11); $port->write("MD0;"); usleep($delayValue); my $Mode=$port->read(5); $port->write("PC;"); usleep($delayValue); my $Pwr=$port->read(6); $port->close(); $VFOA=substr($VFOA, 2, 8); $Mode=substr($Mode, 3, 1); $Pwr=substr($Pwr, 2, 3); $Pwr=int($Pwr); $Pwr="$Pwr"; return($VFOA, $Mode, $Pwr); } my ($tFreq, $tMode, $tPower)=Handle_FTdx1200(); print($tFreq); print("\n"); print($tMode); print("\n"); print($tPower); print("\n");
03. Apparently, in my initial Perl Code, I did not try the 'sleep()' Function.
It is in AppleScript that a delay Function, after any 'serialport Function, is required.

Below is AppleScript Code to set the Keyer Speed to 38 Words per Minute.
set desiredPort to "/dev/cu.usbserial" set tSpeed to "38" try set tPort to serialport open desiredPort bps rate 4800 data bits 8 + parity 0 stop bits 1 handshake 3 delay 0.1 serialport write ("KS;") to tPort delay 0.1 set originalSpeed to serialport read tPort delay 0.1 set originalSpeed to (get (characters 4 through 5 of originalSpeed +) as string) as integer serialport write ("KS0" & tSpeed & ";") to tPort delay 0.1 serialport write ("KS;") to tPort delay 0.1 set currentSpeed to serialport read tPort delay 0.1 set currentSpeed to (get (characters 4 through 5 of currentSpeed) +as string) as integer display dialog "Original Speed: " & originalSpeed & return & "Curr +ent Speed: " & currentSpeed giving up after 5 buttons ("OK") default +button "OK" serialport close tPort on error serialport close tPort end try
In conclusion - again, thank you - to the both of you.

Replies are listed 'Best First'.
Re^2: Cannot write to, or read from, the SerialPort
by haukex (Archbishop) on Jun 18, 2022 at 04:11 UTC
Re^2: Cannot write to, or read from, the SerialPort
by Marshall (Canon) on Jun 20, 2022 at 22:01 UTC
    I am also glad that you got this thing working to your satisfaction! Normally, I would think that these extra delays would not be necessary. I suggested that to simplify the situation (which is always a good idea for debugging). The delay that you have gives enough time for the command to be sent and for the radio to have already decided on its response. I suspect that there is something wrong with the hardware flow control handshake. What exactly is wrong is very configuration specific - could even be a hardware defect in your USB-Serial adaptor gizmo.

    I run the CAT I/F at 38400 baud to talk to a K3. A normal contest logger will keep a steady stream of commands: what freq and mode are you on? to the radio - multiple times per second. This is "background polling noise" that is continuous. When I have the spectrum display attached, I get what is called a "waterfall" display of signal strengths over a range of frequencies. With one logger, I have macros like "100" or "20" that I type in. The logger sequences my macro's radio commands in between the normal polling so that there are not conflicts. With say the "100" command, normally the frequency display will be set up with my current frequency in the middle and I will see 50 KHz on either side. However, if say I am near the lower band edge, the display will show the lower band edge on the left and show 100 KHz up from that edge with my frequency shown wherever it happens to be. Some loggers do not allow me to write my own radio macros and those commands would come from a distinct, separate application. Therefore the need for this "man-in-the-middle" box to do the command sequencing to the radio. If my friend really wants this, I may have to write it in C. Or I suppose I could build a separate hardware box with an Arduino processor as a hardware solution.

    In general, using fixed delays after some hardware (or software) command is a bad idea. However, your situation is simple enough that I wouldn't worry about it.