NetDCUA5 Serielle Schnittstelle, byte im Rx Puffer kann nicht gelesen werden

  • Hallo


    Beim pollen der serielle Schnittstelle habe ich das Problem, das nach einiger Zeit ein empfangenes byte im Puffer zurückgehalten wird und nicht ausgelesen werden kann.

    Erst nachdem ich ein weiteres byte nachschicke, reagiert ReadFile() wieder und ich kann dann 2 bytes sehen, also auch das erwartete welches fehlt. Ich habe das auch schon als event basierende

    Lösung programmiert, dort tritt das Problem eher auf.


    Hier die Polling Routine, das geht ne Stunde gut, und dann tritt der Fehler auf. Es ist also nicht so dass irgendwas verloren geht, sonder es ist im Puffer drin, nur kann ich es nicht lesen.

    Rx und Tx DMA habe ich in der registry eingeschaltet.


    public void Poll_Read(ref Queue myQueue)

    {

    byte[] readbuffer = new Byte[rxBufferSize];

    int bytesread = 0;

    do

    {

    // make sure the port handle is valid

    if (hPort == (IntPtr)CommAPI.INVALID_HANDLE_VALUE)

    {

    bytesread = 0;

    break;

    }

    if (!m_CommAPI.ReadFile(hPort, readbuffer, rxBufferSize, ref bytesread, IntPtr.Zero))

    {

    throw new CommPortException("Serial port -> " + Marshal.GetLastWin32Error());

    }


    if (bytesread >= 1)

    {

    lock (myQueue.SyncRoot)

    {

    for (int b = 0; b < bytesread; b++)

    myQueue.Enqueue(readbuffer[b]);

    }

    }

    // Re-specify the set of events to be monitored for the port.

    if (CommAPI.FullFramework)

    {

    m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLPC);

    }

    else

    {

    m_CommAPI.SetCommMask(hPort, CommEventFlags.ALLCE);

    }

    Thread.Sleep(1);

    } while (bytesread > 0);

    }

  • I did another trial. I use event based communication instead of the above polling.

    I set the receiver thread priority to 100, and there is a difference now. It takes much longer until the problem occurs, about 3 Mb I could transmit. The error happens then again, but with the difference that when communication stops, and I send an additional byte, there are now 2 events, the missing byte and the additional byte. In former trials there was only 1 event.


    Any ideas now ?

  • Hello,


    just for my Information.

    You do nothing else than "read" in your test above, no other threads or applications active?

    Baudrate, parity,databits, stopbits?

    How may bytes do you approximately receive per second?

    And which size have the packets you send?

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • I have a NdcuA5 on one and a Picocom4 on the other side.


    Only one application per device, but also other threads (see example attach). We transmit about say 2000 bytes/ sec in my test, in reality it is less but may increase to such. A Telegram is about 50-60 bytes long, 4 byte overhead the other is data, variable lentgh.

    Baudrate 115200, Data 8, Stop 1, parity none.


    Both sides may transmit a Telegram any time, but it´s defined that there is a Master and a Slave, so one of both needs to wait in case of collision.

    It´s the so called 3964R Protokoll, I think invented from Siemens but am not sure.


    The PicoCom side hasn´t these Problems, and the NDCU8 that I used some years long also didn´t do this trouble to me.




    Edit: I completely forgot to say, there is also a 2. Application, (in fact the main application...), that also runs on netcdua5, see picture.

  • Hello,


    we have optimized the driver several years ago and had have no open issues in the meanwhile. When it works with NetDCU8 and PicoCOM4 you should think about use of NetDCUA9 for your application!


    One last try from my side:

    Use the attached driver (copy it to ffsdisk and change correponding registry value for "DLL" to "ffsdisk\<drivername>"). This Driver has a larger SW buffer.

    Set registry value for "Priority256" to 99.

    Set priority of your read-thread to 100.

    Files

    • fs_serial.zip

      (26.37 kB, downloaded 295 times, last: )

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • Hello,


    i saw no thread with priority 100 in your SSMStandardCtrl.exe.

    At least he read-thread should have the lowest value (104?).

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.

  • This SSMStandardCtrl.exe application is the machine program, acting as a PLC, and it is connected via shared memory to the server.exe application, where the serial and some other stuff for data exchange is running. The priority 100 needs to be there (server.exe).

  • Ok, you didn´t confirm but assuming my driver adjustment was ok, now with your new driver I could transmit nearly 5Mb, new record. But now the behaviour is completely different, the communication stopped because the sender just did not send all bytes he should.


    So not the receiving but the sending is not doing what it should. May be you have a 2. idea also for this ?

  • Hello,


    >>May be you have a 2. idea also for this ?

    << disable TXD DMA if this not helps use NetDCUA9

    F&S Elektronik Systeme GmbH
    As this is an international forum, please try to post in English.
    Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.