C# SerialPort - not in a console application like every example...

[gumbald]

Trying and succeeding to communicate with a device by serial when using a simple console application and the SerialPort is instantiated in the code as follows. There's a DataReceived event handler that's also working fine, I know the device and the code works.

  class Program
  {
    static SerialPort sp = new SerialPort("COM8", 9600, Parity.None, 8, StopBits.One);
    static bool _continue = true;
    public static string serialBuffer;

    static void Main(string[] args)
    {

I now want to build up methods and therefore put them in their own class for calling from another source, but I'm having a little difficulty in that it when I do this, it doesn't seem to want to send or receive data. So, my new console code looks like:

    static void Main(string[] args)
    {
      string result;
      DevControl GEN = new DevControl("COM8", 9600, 6);

      result = GEN.TestConnect();
      Console.WriteLine(result);
      Console.ReadLine();
    }

The corresponding DevControl class looks like this:

  public class DevControl
  {
    private static SerialPort Lambda;
    private static string serialBuffer = "";

    public DevControl(string COMport, int BaudRate, int Address)
    {
      Lambda = new SerialPort(COMport, BaudRate, Parity.None, 8, StopBits.One);
      Lambda.DataReceived += new SerialDataReceivedEventHandler(port_DataReceived);
    }

    public static void port_DataReceived(object sender, SerialDataReceivedEventArgs e)
    {
      serialBuffer = Lambda.ReadExisting();
      serialBuffer = serialBuffer.Replace("\0", "\n");
    }

    public string TestConnect()
    {
      Lambda.Open();

      Lambda.WriteLine("OUT ON");

      while (!serialBuffer.Contains("\n"))
      {
        Thread.Sleep(50);
      }

      string returnValue = serialBuffer;
      serialBuffer = "";

      return returnValue;
    }
  }

Am I missing something glaringly obvious? The sent command should cause an action on the device, which it isn't. The IsOpen value of Lambda just before that call is set to true, so it's made the connection though it would seem.

Other places mention DtsControl and such properties, but it was working in the pure console app code without altering anything like this.

 

[Darg]

It probably doesn't affect anything but do you have a reason for declaring the SerialPort and string as static in your DevControl class?

I'm afraid I don't know much about serial port data transfer. From what I can see your code seems fine though, assuming it's not getting stuck in that while loop? You should probably have a timeout for that so it doesn't wait for longer then 10 seconds for example.

 

[gumbald]

The reason for the while loop was to exit once it had got the acknowledgement back, which it's not getting. I'm discombobulated.

 

[Darg]

I would have a time out on that loop so that you can atleast check if you've got anything in the serial buffer and it won't freeze your program.

Something like this:

      Lambda.WriteLine("OUT ON");
      float timeOut = 0.0f;
      while (!serialBuffer.Contains("\n"))
      {
          Thread.Sleep(50);
          timeOut += 50.0f;
          if(timeOut > 1000.0f)
            break;
      }

      string returnValue = serialBuffer;

 

[gumbald]

How bizarre, turns out it was DTR and RTS that needed enabling else the serial port was putting spurious data out. Not sure what changes when it's separated out into another class and instantiated rather than running in the main method. Oh well.

I've also changed to polling for the data with a timeout as above rather than event driven methods - this suits my needs better I think.

 

[RobH]

I had a similar issue with the RXTX serial library under Java with the Arduino microcontroller. Every time I tried to send a command it would reboot the Arduino, setting the DTR and RTS to enable fixed the problem. A serial loopback can be handy when programming this sort of thing as you can hook up a terminal app such as PuTTY to the serial port on the end of the loop and watch the communications.