I have used SdpoSerial as the RS232 handler in a class which is used in a test application.
In this I create the SdpoSerial component in code in the constructor of my class like this:

  FComm := TSdpoSerial.Create(NIL);
  case Baud of
    1200: FComm.BaudRate := br__1200;
    2400: FComm.BaudRate := br__2400;
    4800: FComm.BaudRate := br__4800;
    9600: FComm.BaudRate := br__9600;
    19200: FComm.BaudRate := br_19200;
    38400: FComm.BaudRate := br_38400;
    else
      FComm.BaudRate := br_38400;
  end;
  FComm.DataBits := db8bits;
  FComm.Parity := pNone;
  FComm.StopBits := sbOne;
  FComm.FlowControl := fcNone;
  {$IFDEF LINUX}
  FComm.Device:= '/dev/ttyS' + IntToStr(Port-1);
  {$ELSE}
  FComm.Device:= 'COM' + IntToStr(Port);
  {$ENDIF}
  FComm.OnRxData := @OnRxComm;
  FComm.SynSer.Purge;
  FCommTimeout := COMTIMEOUT;

Then I open the port like this:

function TSSComm.Connect: boolean;
begin
  if not FComm.Active then
    FComm.Open;
  if FComm.Active then <== Always true even for bogus port!
    FCommState := csOpen
  else
  begin
    FCommState := csClosed;
    Result := false;
    exit;
  end;
  Result := FCommState = csOpen;
end;

I keep track of various communication states in the FCommState variable (it is indicating the state in a state machine).

The problem I have is that even though I open a non-existing port the SdpoSerial does not indicate this. Following the Open method Active is true even though a completely bogus port number has been given!

Why is this and how can I fix it?
I need to know if the port is actually working or not....

Hi,

Two things:

a) if possible post a compilable (even better runnable) example. There are some detail missing that could hold the reason for your trouble. What leads me to...

b) have you redefined "Active" in your class and it is hiding the TSdpoSerial active property?

Paulo Costa

The application is quite extensive now because it holds the complete syntax of the data acquisition equipment I woark towards. So it is not really realistic to post it all....
But it does work, it is just that the user gets no indication whatever if he selects a port that either does not exist or is already used by another application.
In all of my RS232 experience in Delphi (been at it since 1996) it was always the case that the serial component barfed if one tried to open a non-existing or already open port. I have used several different ones and they all had a property similar to Active or Open, which showed the actual state even if they did not throw an exception on opening an erroneous port.
Not so with SdpoSerial (or I have yet to find it).

No, as I showed I only create the FComm object as a TSdpoSerial instance, then set its properties including Active.

I have tested the program now in the original development PC (a VMWare virtual XP-Pro machine) and my Win7X64 laptop and as long as I use a physical com port all seems to work OK. In the virtual machine it means mapping the laptop docking station COM1 into the VM. THen it works just fine.

But when I involve a USB connected serial port (which I have to do if I undock my laptop) I get all kinds of strange errors, basically no communications at all! I have two different ones but both are problematic (ATEN RS232USB and SUNIX 4-port ComHub).

Do you know of any problems related to SynaSer via USB connected RS232 adapters on Windows7 or WindowsXP?

Right now I am moving the Lazarus application around to different computers (real and virtual) and different COM ports (real or USB connected) to try to figure out why it is so hard making it always work. And this is when I found that I tried ports that were already reserved for the virtual machine or actually unplugged without SdpoSerial saying anything about it....

Well, I use AsyncPro 4.07 on Delphi (Windows) in a lot of programs, so I know about it.
But there are a few things that keeps me off AsyncPro for this project:

1) AP is very big and has way too many bells and whistles for me. I just want the RS232 communications running without any extras like TAPI, BBS:es etc...
A simple component like SdpoSerial looked OK to my needs.

2) The final target for the program I am developing is an embedded ARM system running Embedded Debian. I think I should be better off using what comes with FPC/Lazarus than a port of a product like AP to the FPC environment.

I may be wrong, but those were my criteria for selecting SdpoSerial plus advice obtained here.

Please test your ports with:

http://paginas.fe.up.pt/~paco//AVR-IO-M16/M16_PC.zip

and see if the problem also appears with this application.

Paulo Costa

Some questions:

1) How do I set the baudrate with this application?

2) What means "Server" and "Client" in the RS232 context?

3) Is there some form of use instruction too?

I don't really understand it....

Bo Berglund wrote

In all of my RS232 experience in Delphi ,,,

AFAIK, Delphi does not have any serial port support. We successfully used the 3rd party component "AsyncPro" (now open source, available on SourceForge) for this. AFAIK, it not (yet) has been ported to FPC/Lazarus and platform independence.

-Michael

Bo Berglund wrote

1) AP is very big and has way too many bells and whistles for me. I just want the RS232 communications running without any extras like TAPI, BBS:es etc...

So just extract the code you need and make it run with Lazarus. This really would be great to have and on the long run could be distributed with Lazarus as a viable extension of the library.

Let me know if I can be helpful with testing it.

-Michael

On Linux, the CPU architecture should be completely irrelevant for the source code of a decently ported AP package,

-Michael

Dont know if its any help at all, but I am also having serial port problems using USB adaptors.

I am developing under Ubuntu using synaser and have found that I can only connect to the port about once every 5 or so trys.

Cant say if it is directly related SynaSer/ USB adaptor though, as I dont have an onboard one to test against.

side notes -
if I use 'serial port terminal' it connects every time. if I use 'cat /dev/ttyUSB0 > /tmp/test.txt' it tends to not connect more than it connects (similar to synaser)

Suggests it may be necessary to 'reset' the port somehow before using I have a small sample program for testing if anybody wants it

SteveG

Thata was only to see what happens when you try to open a "bad" COM port. This application also uses the SdpoSerial component. So, I wanted to know it it also exhibits the problem that you described.

Paulo Costa

Concerning AsyncPro extraction:
I once (4-5 years ago) tried to isolate the files needed by the serial port component by copying file after file to a directory included in the library path of Delphi from the AsyncPro source dir, which I removed from library path. Then I made a syntax check to see what was missing etc.

After a while I gave up because it looked like I would need more than 50% of the original files or maybe even all of them... :-(

So it is not really possible to isolate just the port.

Oh, I see! After I was having the problems with the long list of errors I now see only some maybe "normal" messages when I am trying com ports that are already in use.
The dialog offers to "kill" the application, which I think is a bit on the extreme side for entering a wrong number. But it appears to be inside the SdpoSerial component because I get the same dialog if I try with my program.

I have not been able to again trigger the strange window I saw the other day, though...

It is very strange how Windows handles the com ports... Somehow there seems to be some hidden deeper issues that makes some components not work in some situations. Examples:

We used a 3rd party serial component in Delphi for many years without real problems (WinNT4, Win95, Win2000 and now XP).

But then we encountered a case where the component simply would not trigger any reception events. This happened on a Panasonic wireless gadget that was an extension of a WinXP PC with a touch screen and a few extras like a serial port. We used the serial port for an RFID reader and it simply would not read. If I added a timer and let it poll the component for data then I could make it work for this simple case, but that was a real kludge..
So then I modified the program to use AsyncPro instead and it started working. Don't know why the difference.

Later, around 2008, I had another problem with an automation program communicating with a machine tool via RS232. At that time I *was* using AsyncPro, and it worked just fine on my laptop when connected to the machine. But the same software running on the customer's PC:s refused to communicate. These PC:s had *real* com ports and were running XP. So as a test I switched this program over to using the old serial component we used before, and amazingly then it worked just fine!

Now I have problems with USB attached serial ports and lazarus programs using SdpoSerial as described in this thread. In this case the comm works fine as long as I use the *real* com port in my docking station. But won't work if I use one of the 4 com ports in my newly bought SUNIX ComHub UTS2009P4 or for that matter if I use a USB single channel com port adapter from ATEN. But the latter can be used if it is not transferred to the virtual machine where I develop the software.

Really very confusing, and I was not planning on doing research into this. I was programming a comm application for data collection....

Do you think there is any chance of using my old serial component (housed in a single pas file) with lazarus?
It is a Delphi component and I don't know what you need to do in order to use it with lazarus. I realize that it would not work as a cross-platform unit but could be interesting for testing.

In the end of course what I need to do is to get it working on the embedded ARM system with Linux.

Of course this is not doable just on a file base. But I suppose you can delete some 90% of the code lines to get a working basic package.

I would do that with Delphi:

- create a simple working example
- so you know which files are necessary (you say some 50%)
- look what active code gets actually lines get compiled in and "ifdef out" the code sequences that are not compiled.
- locate the header definitions that are not necessary and "ifdef out"
- locate the unit definitions that are not necessary and "ifdef out"
- now supposedly you can remove some files
- now there might be stuff that gets compiled because the code "might" use it, but from your project you do know that it will not happen. This can be "ifdef out" with a little bit more effort.

-Michael

Bo Berglund wrote

>Dont know if its any help at all, but I am also having serial port >problems using USB adaptors. >

...

UPDATE:
Now I think I have solved the connectivity issue via the USB-Serial converter so I can move on with the lazarus software development!

I suspected the Windows driver for the ComHub so I downloaded the latest one from SUNIX, but that did not solve the problem. In Device manager I let Windows 7 try to update the driver from the web, but it told me that the driver was up-to-date at version 3.3.5.something

Then I tried googling on "prolific usb-to-rs232" which shows up in device manager as the driver used by the ports. And I found a number of hits that led to a website at Prolific itself (the chip manufacturer) and there it was possible to download a driver with version 3.3.11.152.
After installing this and rebooting the laptop it now seems like the ports are working as intended!

So the fact that the hardware supplier does not have the latest driver and Windows Update does not know of a later one seems not to mean that one does not exist. In this case it is a revision step from 5 to 11 no less and this did the trick. On Windows7X64 that is...

Bo Berglund