Hi Dirk,
thank you for your reply, I have been struggling with this issue for a couple of weeks now and made some troubleshooting progress today. I would like to carry out one more test at this stage before saying something but maybe you can help me with the troubleshooting, I suspect the problem is related to the power supply, below is my configuration, perhaps you can confirm my suspicion.
Attached is the kern.log from today.
I have two issues actually:
1- the input pins of the DIO flicker from a high state 1 to 0 and back to 1 within milliseconds, this affects all the input pins of the DIO module in high state at the same time
2- upon restart the modbus master is not always refreshing the registers of 2 Arduinos connected via a USB hub, this happens say every third reboot of the RevPi Core 3. The serial devices are correctly mapped and I can look up the USB device details correctly, so it seems a missing connection between the Modbus Master of the piControl and the system devices.
But the nagging problem is 1 at present, 2 could be a subject for a different topic unless you would like to reply here as well.
Problem 1 is somehow related to this post:
viewtopic.php?f=3&t=909&p=3825&hilit=di ... e%2A#p3825
My system uses:
- RevPi Core 3, the operating system is Stretch
- 2 DIO modules
- USB hub:
https://revolution.kunbus.de/shop/de/in ... hub-4-port
- 60W power supply:
https://revolution.kunbus.de/shop/de/ne ... -mdr-60-24
- the whole system power is supported by a UPS:
https://www.apc.com/shop/bg/en/products ... BX1400U-GR
problem 1: the input pins of the DIO modules when they are in a high state (1) for days (short circuited) every 3-4 hours suddenly go to 0 and then back to 1 within milliseconds. This is detected via a software loop checking the input variables every 50ms. The same software system has been running with a RevPi Core 1 and 5 DIO modules for months in another place with no issues.
The DIO modules had firmware version 1.3 initially and the errors I was seeing in the kernel logs were:
Code: Select all
........
Sep 27 14:07:07 RevPi6733 kernel: [ 14.856405] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Sep 27 14:07:09 RevPi6733 kernel: [ 16.475928] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Sep 28 23:40:11 RevPi6733 kernel: [26944.648122] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [29059.219880] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [34798.775392] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [39330.000907] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [45371.633423] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [63798.620850] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [74975.638637] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [78902.707030] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [90381.806193] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [93704.707449] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [120799.562166] piControl: too many communication errors -> set inputs to default 0 0 11 0 0 0 0 0
Sep 28 23:40:11 RevPi6733 kernel: [120799.582178] piControl: too many communication errors -> set inputs to default 0 0 12 0 0 0 0 0
Sep 28 23:40:11 RevPi6733 kernel: [120799.602220] piControl: too many communication errors -> set inputs to default 0 0 13 0 0 0 0 0
............
After an upgrade to firmware version 1.4 the logs have disappeared but I have started seeing this random signal flickering reading the DIO input variables.
Now I am tracking the changes via logs and this is an example, the "v:1" actually means that the DIO input pin is not short circuited, the logic is inverted because it is a door alarm signal.
The first lines are wrong readings of 1-wire sensors connected to the Arduinos (2 Modbus Masters in piControl).
This shows that within a second there is a signal degrade, probably voltage, and this affects both the Arduino readings and the DIO input pins.
Code: Select all
ERROR: 2018/10/24 21:37:52.386519 switchedmapper.go:79: error reading pin temp_3, continue to next, error: invalid temperature read 508.453125, temperature above DS18B20 maximum 125.000000, check the wiring
ERROR: 2018/10/24 21:37:52.386695 switchedmapper.go:79: error reading pin temp_4, continue to next, error: invalid temperature read 414.992188, temperature above DS18B20 maximum 125.000000, check the wiring
ERROR: 2018/10/24 21:37:52.386934 switchedmapper.go:79: error reading pin temp_4_split, continue to next, error: invalid temperature read 414.992188, temperature above DS18B20 maximum 125.000000, check the wiring
INFO: 2018/10/24 21:38:04.335064 trigger.go:79: IO activity, pin={props},...:
I_1_i05={"v":1},I_2_i05={"v":1},I_4_i05={"v":1},I_5_i05={"v":1},I_6_i05={"v":1},I_7_i05={"v":1},I_8_i05={"v":1},I_9_i05={"v":1},I_10_i05={"v":1},I_11_i05={"v":1},I_12_i05={"v":1},I_13_i05={"v":1},I_14_i05={"v":1}
INFO: 2018/10/24 21:38:04.534765 trigger.go:79: IO activity, pin={props},...:
I_1_i05={"v":0},I_2_i05={"v":0},I_4_i05={"v":0},I_5_i05={"v":0},I_6_i05={"v":0},I_7_i05={"v":0},I_8_i05={"v":0},I_9_i05={"v":0},I_10_i05={"v":0},I_11_i05={"v":0},I_12_i05={"v":0},I_13_i05={"v":0},I_14_i05={"v":0}
My suspicion is that there is a faulty power supply but correct me if I am wrong, I have tried replacing different parts of the system so far with no luck:
- 24V power supply
- cables, which have been tested separately on another RevPi with 40m of Cat5 ethernet cable and displayed no corrupt behaviour
- removed all door sensors and short circuited the cables
- replaced the DIO modules
- checked all the wirings
- measured the voltage input at the DIO input pin, it was 24,2 V with the long cable connected. The current was about 2,46 mA
The only two tests I am left with:
- replace the UPS
- replace stretch with Jessie
My questions to get some troubleshooting help please:
- if it lies on the UPS why is the RevPi Core 3 up an running all the time and there are no kernel errors? Just the DIO inputs seem to fail
- could it be that the voltage of the main input power of the DIO drops at so low a value that the input chip of the DIO undergoes a fault state? I think this is the chip you are using:
https://datasheets.maximintegrated.com/ ... X31913.pdf
So this could be the reason why all the input pins in a high state go to 0 altogether at the same time.
-
if I downgraded the system to Jessie would firmware 1.4 be supported at all on Jessie, which according to my investigation supports 1.3 at maximum?
As for problem 2, the missing modbus master resync on reboot is less troublesome but still nagging because I need to tell the customer to try to shut down and switch on the system with "brute force" being not physically there.
I suspect both issues are my bad be the way but I am making little progress and debugging takes up plenty of time.
Thank you indeed
Enrico