DIO Module unstable behaviour
Hello,
I'm currently working on a project with a revpi.
In this project we would like to drive a stepper motor via serial communication and use a DIO module for setting some pins.
I started the project with making the serial driver, because the rest looked very easy.
After the driver was ready I extended the main application with some code from the piTest.c.
I just commented out the main entry point, made a header file so that I could use it as a base of my application.
Now we come to the frustrating part: the pibridge.
At the moment I'm unable to write or read to the DIO module.
Things I checked and checked ...:
* connections of x4 and x2 connectors = fine.
* the pictory configuration is fine and I can use it in the piTest: eg. piTest -r I_1, piTest -w O_1,1, but of course although it is reading values and setting values the physical values are not there :/.
Always 0v input and output is never set. I checked the supply voltages over and over so I'm desperate.
* rebooted the system (the DIO gets recognized for 30% of the time) -> the revpi makes huge log files under: /var/log/kern.log: RevPi9202 kernel: [ 101.852318] piControl: too many communication errors -> set inputs to default 0 255 0 0 0 0 0 0
* Check if the firmware of the module is up to date: DIO V1.4 and revpi V1.2
* sudo apt update/upgrade
I tired what I could, but now I do not know how to proceed.
Does anyone have other ideas, what I can check/do?
Kind regards,
Lode
I'm currently working on a project with a revpi.
In this project we would like to drive a stepper motor via serial communication and use a DIO module for setting some pins.
I started the project with making the serial driver, because the rest looked very easy.
After the driver was ready I extended the main application with some code from the piTest.c.
I just commented out the main entry point, made a header file so that I could use it as a base of my application.
Now we come to the frustrating part: the pibridge.
At the moment I'm unable to write or read to the DIO module.
Things I checked and checked ...:
* connections of x4 and x2 connectors = fine.
* the pictory configuration is fine and I can use it in the piTest: eg. piTest -r I_1, piTest -w O_1,1, but of course although it is reading values and setting values the physical values are not there :/.
Always 0v input and output is never set. I checked the supply voltages over and over so I'm desperate.
* rebooted the system (the DIO gets recognized for 30% of the time) -> the revpi makes huge log files under: /var/log/kern.log: RevPi9202 kernel: [ 101.852318] piControl: too many communication errors -> set inputs to default 0 255 0 0 0 0 0 0
* Check if the firmware of the module is up to date: DIO V1.4 and revpi V1.2
* sudo apt update/upgrade
I tired what I could, but now I do not know how to proceed.
Does anyone have other ideas, what I can check/do?
Kind regards,
Lode
Re: DIO Module unstable behaviour
Hi Lode,
the error message "too many communication errors" is shown, if a lot of errors occur in the communication between the RevPi and DIO.
RS485 signals are used on the piBridge. The data is only disturbed if there are strong electromagnetic interferences. Do you have motors or relays mounted nearby?
Are the piBridge plugs firmly plugged in? Do you use the same ground and functional earth for all modules?
Do you access /dev/ttyAMA0?
Please send me the complete kern.log file.
Mathias
the error message "too many communication errors" is shown, if a lot of errors occur in the communication between the RevPi and DIO.
RS485 signals are used on the piBridge. The data is only disturbed if there are strong electromagnetic interferences. Do you have motors or relays mounted nearby?
Are the piBridge plugs firmly plugged in? Do you use the same ground and functional earth for all modules?
Do you access /dev/ttyAMA0?
Please send me the complete kern.log file.
Mathias
Re: DIO Module unstable behaviour
Where can I fiend the password for the system image on the website (jessie)?
Re: DIO Module unstable behaviour
What do you mean with "system image"?
When you log in the first time on the console (with USB keyboard and HDMI monitor) after you flashed the image with the mirco usb connector,
the user is 'pi' and password is 'raspberry' (with german keyboard layout, so maybe you have to type 'raspberrz')
Then you are asked for the serial number and mac address from the orange cap. Now the default password is active. It is printed on the sticker on the side of the RevPi.
When you log in the first time on the console (with USB keyboard and HDMI monitor) after you flashed the image with the mirco usb connector,
the user is 'pi' and password is 'raspberry' (with german keyboard layout, so maybe you have to type 'raspberrz')
Then you are asked for the serial number and mac address from the orange cap. Now the default password is active. It is printed on the sticker on the side of the RevPi.
Re: DIO Module unstable behaviour
Hello,
Indeed sorry for the confusion.
I will first update/upgrade and see what happens.
I can confirm that all the connections are fine and correct.
For some reason the communication is very unstable.
One thing I'm a bit annoyed from is the kern.log.
Fine that you want miss communication erros to be logged, but they are logged every x ms and are under the root file system (same partition).
Within a few hours it will eat up all the free space on the system and the os crashes. That can not be the goal of logging?
Indeed sorry for the confusion.
I will first update/upgrade and see what happens.
I can confirm that all the connections are fine and correct.
For some reason the communication is very unstable.
One thing I'm a bit annoyed from is the kern.log.
Fine that you want miss communication erros to be logged, but they are logged every x ms and are under the root file system (same partition).
Within a few hours it will eat up all the free space on the system and the os crashes. That can not be the goal of logging?
Re: DIO Module unstable behaviour
Hi,
you are right. With stretch there are much less messages.
On the other hand, there's a problem with your system. If you solve that, you will not have a problem with the messages anymore.
Mathias
you are right. With stretch there are much less messages.
On the other hand, there's a problem with your system. If you solve that, you will not have a problem with the messages anymore.
Mathias
Re: DIO Module unstable behaviour
Reflashed the emmc with the jessie image and everything works fine.
Something was wrong with the OS delivered on the revpi.
Strange that the os still worked, but the rs485 communication not?
Did other people had the same issues or am I the only one?
kind regards,
Lode
Something was wrong with the OS delivered on the revpi.
Strange that the os still worked, but the rs485 communication not?
Did other people had the same issues or am I the only one?
kind regards,
Lode
Re: DIO Module unstable behaviour
Hi,
yes I do have the same issue, it does not happen constantly but every 10 days or so with no hardware changes.
The system seems to be unstable in my case too for no apparent reason.
A to restart piControl fixes the issue temporarily and then after some days it happens again.
I have noticed that just some inputs show an incorrect state but others seem to work fine, the modbusrtu master ones for instance.
If it really depends on some electromagnic noise is it possible to know on which module and on which inputs in case?
I updated the system to stretch, should I revert it back to jessie?
Thanks
Enrico
Attached the kern.log first 1000 lines and the kern.log last 1000 lines showing a piControl reboot at the end, in the middle there is always the same line:
Other details:
piTest -d:
system details:
yes I do have the same issue, it does not happen constantly but every 10 days or so with no hardware changes.
The system seems to be unstable in my case too for no apparent reason.
A
Code: Select all
piTest -x
I have noticed that just some inputs show an incorrect state but others seem to work fine, the modbusrtu master ones for instance.
If it really depends on some electromagnic noise is it possible to know on which module and on which inputs in case?
I updated the system to stretch, should I revert it back to jessie?
Thanks
Enrico
Attached the kern.log first 1000 lines and the kern.log last 1000 lines showing a piControl reboot at the end, in the middle there is always the same line:
Code: Select all
piControl: too many communication errors -> set inputs to default 0 255 255 0 0 0 0 0
piTest -d:
Code: Select all
piTest -d
Found 5 devices:
Address: 0 module type: 95 (0x5f) RevPi Core V1.2
Module is present
input offset: 0 length: 6
output offset: 6 length: 5
Address: 32 module type: 96 (0x60) RevPi DIO V1.3
Module is present
input offset: 11 length: 70
output offset: 81 length: 18
Address: 33 module type: 96 (0x60) RevPi DIO V1.3
Module is present
input offset: 124 length: 70
output offset: 194 length: 18
Address: 64 module type: 24580 (0x6004) ModbusRTU Master Adapter V0.0
Module is present
input offset: 237 length: 101
output offset: 341 length: 75
Address: 65 module type: 24580 (0x6004) ModbusRTU Master Adapter V0.0
Module is present
input offset: 452 length: 101
output offset: 556 length: 75
The firmware of some I/O modules must be updated.
Please connect only one module to the RevPi and call 'piTest -f'
Code: Select all
sudo lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
uname -a
Linux RevPi6733 4.9.76-rt60-v7+ #1 SMP PREEMPT RT Tue, 17 Jul 2018 14:20:12 +0200 armv7l GNU/Linux
- Attachments
-
- kern.log.last.1000.lines.2018.09.20.tar.gz
- (5.96 KiB) Downloaded 994 times
-
- kern.log.first.1000.lines.2018.09.20.tar.gz
- (6.54 KiB) Downloaded 916 times
Re: DIO Module unstable behaviour
Hi,
piControl started flooding the logs with the same error early this morning:
The system is in a house and there was not much activity on a Sunday morning at about 6 am.
Attached all the kernel log files displaying the log sequence since the last piControl reset.
As said a piTest -x (piControl reset) makes the piControl go back to normal.
Question then:
Thank you, regards
Enrico
piControl started flooding the logs with the same error early this morning:
Code: Select all
piControl: too many communication errors -> set inputs to default 0 255 0 0 0 0 0 0
Attached all the kernel log files displaying the log sequence since the last piControl reset.
As said a piTest -x (piControl reset) makes the piControl go back to normal.
Question then:
- Why is the system going back to normal after a piControl reset? If there was a permanet fault/noise this should not make the driver output error logs continuously
- The first error logs start with progressive numbers until 255 is reached
is there a way of determining the origin of the error?
Code: Select all
Sep 23 06:18:32 RevPi6733 kernel: [1187098.248947] piControl: too many communication errors -> set inputs to default 0 11 0 0 0 0 0 0 Sep 23 06:18:32 RevPi6733 kernel: [1187098.268950] piControl: too many communication errors -> set inputs to default 0 12 0 0 0 0 0 0 Sep 23 06:18:32 RevPi6733 kernel: [1187098.289023] piControl: too many communication errors -> set inputs to default 0 13 0 0 0 0 0 0 Sep 23 06:18:32 RevPi6733 kernel: [1187098.308947] piControl: too many communication errors -> set inputs to default 0 14 0 0 0 0 0 0 ... Sep 23 07:17:01 RevPi6733 kernel: [1190606.811833] piControl: too many communication errors -> set inputs to default 0 255 0 0 0 0 0 0 ...
- Should I tree to downgrade the system to jessie instead of using stretch?
Thank you, regards
Enrico
- Attachments
-
- kern.log.3_last.1000.lines_20180923.tar.gz
- (6.08 KiB) Downloaded 1009 times
-
- kern.log.2_first.1000.lines_20180923.tar.gz
- (6.29 KiB) Downloaded 915 times
-
- kern.log_20180923.tar.gz
- (1.18 KiB) Downloaded 970 times
Re: DIO Module unstable behaviour
Hi,
an extra post just to add the missing log file which for some reason the website would not let me add to the previous message.
Cheers,
Enrico
an extra post just to add the missing log file which for some reason the website would not let me add to the previous message.
Cheers,
Enrico
- Attachments
-
- kern.log.1_first.1000.lines_20180923.tar.gz
- (5.49 KiB) Downloaded 1023 times