Serial communication result depends on COM ports

[max-privato]

I have a simple model that uses serial communication.

To perform this communication I use two different ports. In reality, I use a USB cable emulating via hardware a serial board. So the COM ports I see in my Device Manager depend on where (which USB port) I connect the cable. In one case I have COM4 and COM 7. In another COM9 and COM10.

In both cases I can exchange characters from a port to another using a terminal application (I tried with RealTerm).

Consider the mo file, which below. When I use it when the PC has as Com ports COM4 and COM7, the communication is correct. When I use it when the ports are COM9 and COM10 the simulation fails.

In particular:

• with Dymola 2020x, I get the following message: MDDSerialPort.h: CreateFileA of serial port COM10 failed with error code: 2

  with OpenModelica I get the following message

  Simulation process failed. 
  Exited with code 0xffffffffffffffff.
  MDDSerialPort.h: CreateFileA of serial port COM10 failed with error code: 2
  simulation terminated by an assertion at initialization

Maybe there is just a trivial error when COM with large numbers are involved? (maybe when they have more than one digit?)

Thank you.

Here's the model (change "txt" into "mo" before using): IntegerSendReceive.txt

EDIT After further checks, it seems to me that coms 1 to 7 are working from 8 onwards cause an error message.

[tbeu]

Citing this Stack Overflow post:

If you want to use a COM port above 9 you have to use the Win32 device path syntax:

Instead of "COM10" you need to specify "\\\\.\\COM10".

[max-privato]

Nice suggestion. I tried it, but insofar I had only a partial result: now the program runs, but no data is received. Tomorrow I'll check again, and I'll post info on the outcome, and possibly a simple example showing the remaining issue.

[max-privato]

I made further tests. Using the recommendation from @tbeu , I don't have the error message anymore, but I don't receive the numbers.

Plots with COM6 sending and COM7 receiving:

Plots with COM6 sending and COM9 (\\.\COM9) receiving:

So, the issue should be a different one. Note that I found the issue from COM equal to eight and above, not above 9 as in the stack overflow post mentioned by @tbeu .

[bernhard-thiele]

Hm, no idea why this is like that.

You could give the C test program test_MDDSerialPort.c a try and set the COM ports there directly (requires to generate the VS project for the external C sources). My (very small) hope is, that this might give some warnings/errors which can be interpreted.

[max-privato]

I found a good workaround on this issue. I recently discovered that WIndows allows (from Device managers com ports advanced settings) changing the COM number assigned to ports. Using this, on all my PCs I was able to choose COM numbers below 6 for my tasks. Obviously, this workaround works only on systems with not more than 6 COM ports active, which nowadays is the vast majority, I suppose.

[bernhard-thiele]

Okay, thanks for sharing the workaround.