Possible bug in the RevolutionPi Data IO driver

[energiemanagement]

We are having an emergency stop button connected to an input of the Kunbus Digital IO Module connected to a Kunbus RevPi Connect+. Due to its usage the input signal of the Digital IO Module is constantly set to "1". We are cyclically reading the input (from within our C-program). Sporadically we get an "0" instead of an "1". The behaviour can be reproduced on other hardware too, and it can be reproduced on other inputs also (it doesn't matter if we use I_0 or any other input I_x). So it looks that there is a bug in the Data IO driver!

Attached is a little test script. Here is what it puts out:

Code: Select all

$ ./checkIO-2.py
emergency stop pressed at 2020-12-01T12:36:11.539731
emergency stop pressed at 2020-12-01T13:07:29.836058
emergency stop pressed at 2020-12-01T14:00:38.832124
emergency stop pressed at 2020-12-01T14:39:26.019836

Version information:

Code: Select all

# uname -a
Linux emibox0001 4.19.95-rt38-v7+ #1 SMP PREEMPT RT Tue, 16 Jun 2020 13:25:43 +0200 armv7l GNU/Linux

# piTest -d
Found 3 devices:

Address: 0 module type: 105 (0x69) RevPi Connect V1.0
Module is present
     input offset: 113 length: 6
    output offset: 119 length: 5

Address: 31 module type: 96 (0x60) RevPi DIO V1.4
Module is present
     input offset: 0 length: 70
    output offset: 70 length: 18

Address: 32 module type: 109 (0x6d) RevPi CON CAN V0.0
Module is present
     input offset: 0 length: 0
    output offset: 0 length: 0

Below you find the test script, which produces the error:

Code: Select all

#!/usr/bin/env python3

import time
import subprocess
from datetime import datetime


def read_output(address) -> int:
    pitest_output = subprocess.run(['piTest', '-q', '-1', '-r', address], stdout=subprocess.PIPE)
    return int(pitest_output.stdout)


while True:
    if (read_output("I_2") != 1):
        dt=datetime.now()
        print("emergency stop pressed at " + datetime.utcnow().isoformat())
    time.sleep(0.001)

[dirk]

Hi, can you please run "uname -a" and post the output here?

Code: Select all

pi@RevPi40302:~ $ uname -a
Linux RevPi40302 4.19.95-rt38-v7+ #1 SMP PREEMPT RT Tue, 16 Jun 2020 13:25:43 +0200 armv7l GNU/Linux

In case you have a lower kernel version please update your system as follows:
How to Update Your System

Just an idea by looking at the code - maybe you should give the RevPiModIO2 Python library a try.

[energiemanagement]

Hello Dirk, you find my uname output in my first post in the second code block in line 2. It looks like we are using the same kernel version. Note that we cyclically update/ugrade our system. So it should be up to date.

The python code is just for testing purpose. In our real world application we access the data input module via the following code:
https://github.com/clehne/librevpi-dio- ... vpidio.cpp

But it doesn't make a difference. Both our library and the piTest programm sporadically return wrong values.

Thanks and regards,
Chris

[c.baumann]

Hello Chris,
is the input pulled high by the supply or is it pulled high by a digital output?

[LuukvanLoon]

Hello Dirk, you find my uname output in my first post in the second code block in line 2. It looks like we are using the same kernel version. Note that we cyclically update/ugrade our system. So it should be up to date.

The python code is just for testing purpose. In our real world application we access the data input module via the following code:
https://github.com/clehne/librevpi-dio- ... vpidio.cpp

But it doesn't make a difference. Both our library and the piTest programm sporadically return wrong values.

Thanks and regards,
Chris

I have got excact the same problem.

The problem occurs in the DI, DO and AO. I have tried to use only one DIO or AIO card but this also is not the problem.

This seems to be a bug in the firmware. KUNBUS says that they are working on a new firmware version without the bug over here.

[energiemanagement]

Hello Chris,
is the input pulled high by the supply or is it pulled high by a digital output?

Hello Mr. Baumann,
this is really an interesting question! I thought, the emergency stop was constantly connected to power supply, but I had heard now, that it is connected to a digital output. My test on another hardware is also connected to a digital output. Both run completely different software configurations. But I understand the idea behind your question. I will change my configuration, so that the input signal is put directly to the power supply (with a resistor).
I will put the results in here...
Thanks,
Chris

[energiemanagement]

Just to let you know:
I physically rewired the data input to the power supply. I have restarted my testcase. But the result is the same:

Code: Select all

$ ./checkIO-2.py
emergency stop pressed at 2020-12-03T15:59:15.128044
emergency stop pressed at 2020-12-03T15:59:21.138075
emergency stop pressed at 2020-12-03T16:01:42.133784
emergency stop pressed at 2020-12-03T16:03:55.193856
emergency stop pressed at 2020-12-03T16:04:05.177568
emergency stop pressed at 2020-12-03T16:05:40.194518
emergency stop pressed at 2020-12-03T16:06:22.190407
emergency stop pressed at 2020-12-03T16:07:05.207881
emergency stop pressed at 2020-12-03T16:07:06.303026

So I assume, that the kunbus data IO Input driver has a small synchronisation problem or so.

[c.baumann]

I had your python script running over the weekend on a connect+ and a dio. One input was pulled high with a 4.7k resistor to Vsupply (24V).
There was no "emergency stop" reported in this period.
Can you check your wiring again since the error seems to appear more often in your last setup.

[energiemanagement]

Hello Mr. Baumann,
I double checked my environment. To be safe, I also rewired my wirings. I am really sure that there is a permanent connection from the power supply (24V) to the resistor (10k) to the data input signal. I got the same results as in my last test.

But I should note, that we may have different situation than in your testcase. We have attached a CAN HW module. Also we have

• some load on the CAN bus.
• some load on the Modbus RS-485 interface
• a java process to evaluate the CAN and modbus data
• sporadic write access to the filesystem (database write)
• sporadic phases of high cpu load

Also you are right. I think, I now know, why the message appears more often in my last post. It happens, if the java process accesses the DIO module in parallel to the python test case. Note that the java process cyclically writes some data out values. If I disable data io module within java the error happens only very seldom.
So could it be, that there is an interference between two processes reading from data in, while one of those processes is writing to data out?
Or, could it be that a process writing to data out, influences reading data in behavior?
I am pretty sure, that none of my processes is writing to data in.
Regards and thanks for your help,
Chris

[dirk]

Hi Chris,
just download the latest piControl and try it out as there were some fixes.
Use the kernelbaker GitHub repository. We would be pleased to receive feedback.