Hi all!

I have inherited an application made in Gambas and I am getting into the world.
this application communicates with various peripherals through RS-485. In PC it has an RS-485 to RS-232 converter (it does not go via USB). Peripherals act as slaves (they only answer questions from the PC). The thing is that between one frame and another, I have a delay of 50ms. If I put traces in the code, I see that in the same millisecond that I receive the response of a frame, the next one is sent, but if I connect the oscilloscope, between the response frame and the next question I have a sleep time of 50ms.

That is, according to traces in the code I have the following times:
000ms: request frame is sent
055ms: the request frame was just sent
110ms: first bytes of response frame begin to be received
150ms: reply frame just received
150ms: question frame 2 is sent

According to the oscilloscope the times are:
000ms: start request frame
040ms: end the request frame
050ms: start of response frame
090ms: reply frame ends
150ms: start question frame

In sending, there is already a difference of 15ms between what it takes to send and the actual transmission time of the frame, but between the end of the response frame and the next question begins, there is a gap of approx. 50ms.

To send I do it like this:
To receive, I have tried by polling or by interrupt and times are the same.

The application runs on Debian 9.

Any idea where I may be missing this 50ms and how to correct it?

Thank you.

Kalay said

…The application runs on Debian 9.

Any idea where I may be missing this 50ms and how to correct it?

Thank you.

Hi, I don't know the answer to your problem, or fully understand the issue. But Debian 9 is a multitasking operating system, so I wonder whether you are just looking at a time-slice issue.
A real time OS may minimise your problem, but is this issue actually causing problems to your application? I would have thought that your comms protocol would be able to manage/identify messages and data ok on your RS485 multidrop system.

 Happy new year!

50ms for an actual PC is a life… I know I can not control a real time application, considering real time < 1ms, but 50 ms…

I've done an application in Wt, running on Windows, and I can send a frame every 95ms, not 150ms. I will compile it for Debian, but I don't think Debian will get worts performance.

 Is it possible that your hardware is buffering the data?  I've got two computers that are dedicated to serial transmissions.  One is an old 486 DOS based machine, and the other is a Windows 10 on modern hardware with on board RS-232.  Both of them are used to talk to the same machine on my shop floor.  The DOS machine reports character by character what's been sent, yet the Windows machine tends to report a few dozen lines sent when actually nothing has been sent as the Windows machine's serial port is waiting for an XON from the machine prior to it actually sending anything.

Now this might just be a quark of the Windows software I'm running, or it might be the hardware and/or OS buffering a bit of data.  I know you said you had this working properly in Windows.  So by any chance were you able to use the same hardware as well?  I also know I had to be careful if I tried a USB to RS-232 adaptor.  Some makes had odd quirks that could cause communication issues with some industrial equipment, where others would work fine.  The advice I always got  from equipment vendors was to use onboard serial ports instead.

I might be barking up the wrong tree here, but this might be something to look at.

 Hi.

I've tested the same application on a virtual machine, and it doesn't delays 50ms, so it's a machine issue.
The CPU is an Intel Celeron N3350 64bits, it should be more than enough to send and receive frames over a serial port witout this delay.

 So it probably is the actual serial port its self that's causing the delay.  That may be why I liked the old 80's/90's serial cards.  They weren't fancy, but seemed to obey strict communication standards.

Unfortunately I can not advise on what would be a good replacement that would work in modern equipment.