Invalid code ("Illegal function") about arduinomodbusslave

[raffaeler]

The reason why I started poking at the library is because it doesn't work anymore (arduino pro mini at 9600 baud):

[RTU]>Tx > 14:22:18:203 - 06  01  00  02  00  01  5D  BD  
[RTU]>Rx > 14:22:21:942 - 06  81  01  30  51  
Sys > 14:22:21:942 - Error : Illegal function
[RTU]>Tx > 14:33:29:785 - 06  01  00  02  00  01  5D  BD  
[RTU]>Rx > 14:33:33:267 - 06  81  01  30  51  
Sys > 14:33:33:267 - Error : Illegal function
[RTU]>Tx > 14:34:08:339 - 06  01  00  02  00  01  5D  BD  
[RTU]>Rx > 14:34:12:132 - 06  81  01  30  51  
Sys > 14:34:12:132 - Error : Illegal function
[RTU]>Tx > 14:35:04:658 - 06  01  00  00  00  01  FC  7D  
[RTU]>Rx > 14:35:08:526 - 06  81  01  30  51  
Sys > 14:35:08:526 - Error : Illegal function
[RTU]>Tx > 14:35:15:936 - 06  01  00  01  00  01  AD  BD  
[RTU]>Rx > 14:35:19:435 - 06  81  01  30  51  
Sys > 14:35:19:435 - Error : Illegal function
[RTU]>Tx > 14:50:15:597 - 06  02  00  01  00  01  E9  BD  
[RTU]>Rx > 14:50:17:888 - 06  82  02  70  A0  
Sys > 14:50:17:888 - Error : Illegal data address
[RTU]>Tx > 14:50:52:471 - 06  03  00  01  00  01  D4  7D  
[RTU]>Rx > 14:50:55:171 - 06  83  03  B0  F0  
Sys > 14:50:55:171 - Error : Illegal data value

The log is done from QModMaster who has the "monitor" function, and verified by another reader using a serial monitor who print hex codes.

As you can see there are many "8x" codes for all the responses which means error.
I am still investigating what the reason could be ....

[raffaeler]

I suspect the problem is due to timing problems.
In my loop function, I poll the modbus, read some sensors and write on the SPI screen.
Both the sensors and the SPI screen are slow.
By adding other two slave.poll() between the sensor read and the SPI writing, the problems go away.
I suspect the logic around the 'time of the last communication' is wrong. It shouldn't really relevant whether the last poll was done a long time ago or not.

[yaacov]

@raffaeler Hi, thank you for noticing that ! ❤️

can you make a pull request that fixes the issue ?

[raffaeler]

I can, but I am not sure that is the only problem.
Is the current master tested with some hardware? This version is preventing me to use the library even with the provided samples, as the library is responding with code "0x8x" (error) for any request.

[yaacov]

Is the current master tested with some hardware?

last time I tested it was a long time ago.

This version is preventing me to use the library even with the provided samples, as the library is responding with code "0x8x" (error) for any request.

hmm, AFAIK it should work,
what hardware are you using ?
can you debug what you are sending the device ( e.g. loop-backing to the client ) ?

p.s.
my 2 cents here are - if you know what the problem, and understand what is the cause, ( e.g. it's not a problem specific to your usage ) than it's safe to fix it.

[ysmilda]

I'm currently using the master in production and it works as it is supposed.

[yaacov]

@raffaeler can you try older version and find the PR that starts this problem ?
We may get a clue as of why it affects your build, and not @proace ...

[raffaeler]

@proace interesting (I am using the version in master which is different than the one in /releases
Also, I don't see errors in the requests that could justify those errors. And the previous release
The logs show very simple requests which should be straightforward

[raffaeler]

@yaacov I was tempted to test 2.0.0 but I notice a huge difference:

• master version is 30K
• 2.0.0 (in releases) is 11K

How old is the one is releases?

[yaacov]

How old is the one is releases?

2 was released on: Nov 14, 2017 (26 commits ago) , and have API changes ...

[yaacov]

@raffaeler hi, can we close this ?

[raffaeler]

Hi @yaacov, I confirm there is a bug in the timing calculation, but I am not sure why it was put there and if it is safe to modify it.
The test I made was too wait for a long time between poll calls. This compromised the whole communication (no message could be transmitted at all).
In my case it happened because of the TFT screen which is very slow to update at 8MHz.

You can close it, but I believe there is a bug. Sorry

[yaacov]

You can close it, but I believe there is a bug. Sorry

np :-) I'm closing for now (we can always reopen).

If / When you find more data about the problem, please reopen with more data ( or with a pull request :-) )

[falahati]

I was just casually browsing the issues that I saw this and since I am the one that wrote the timing calculations, I feel obligated to clarify the reasoning behind it.

The idea behind the timings and the rejection of requests or responses that are slow or too fast is based on the Modbus standard and therefore I don't think removing them is a good idea.
The reason why you don't have any problem with the old master is that it was in blocking mode, therefore, the whole operation of reading from serial, responding, and writing to it happened when still being in the first poll. It is a more forgiving approach; however, this makes the library buggy when used in noisy environments and since the operation might take a while also makes your code unresponsive while the Modbus is busy.

What I tried to do was to make the read and write operations asynchronous (non-blocking) so that it can happen in more than one cycle. This allows you to do other things while waiting for the serial buffer to clear up and make your code more responsive especially when the baud rate is low. In other words, the idea was that the poll function should return as soon as possible allowing the main code to continue to work. It is also more interrupt friendly.

However, this behavior also expects your code to be fast with giving the control back to the library at a later time so that it can continue its work. In your case, it seems that you take too much time to do other stuff and therefore pushing the library outside of the Modbus accepted time delay between chunks of the same message. This allows the receiving library to reject the incoming message since its too slow.

This may make some special cases harder, like when having some other methods that are slow, but in overall allows for more flexibility when used correctly. It also makes sure that you don't get unexpected requests or responses when the bus is noisy. I used it with two dozen sensors all reporting status without a problem. The older version didn't work due to abandoned buffer, overlapped messages, etc, etc. It also made other parts of my code super slow.

At the end of the day, you should remember that the hardware has only one thread and therefore the job of process management is unfortunately on the developer's shoulders unlike when writing a program for modern operating systems. Therefore the aim should be to end a cycle as soon as possible and not necessarily do everything in each cycle since the processing power is limited.

In your example, it can be solved simply by not reading the sensors and updating the screen on every cycle simply by alternating the methods that are slow between cycles. Or refactor the slow methods to be more responsive. If you can't do it just decrease the baud rate since the timeouts are based on the baud rate as with the Modbus standard. If that's not an option, you can still force the library to do everything in one cycle by doing something similar to this:

while (true) {
   if (slave.poll() == 0) {
      break;
   }
   delay(50);
}

This should do the whole write in one go. Like the old master. I personally don't recommend it tho.

[raffaeler]

@falahati sorry but I realized only now you posted on this thread.
When I found the problem I tried to query one sensor at a time and update the screen after some time but the DHT11 and the screen are terribly slow for a 8MHz Pro Mini.
I also tried to poll the modbus in multiple parts of my code, but every attempt failed.

From your words, I may have more hope with your latest changes.
I was wondering whether you can add #define to disable the timing check when you have to use in slow devices with slow sensors.
I totally understand that this goes out of the specs, but I have tons of famous brands sensors (Shneider is an example) that are using modbus out of the specs :)

Thanks