I have a Raspberry Pi with a ds2482 i2c onewire bus master connected. The driver has been added to raspbian (2017-11-29-raspbian-stretch-lite.img) and the device is enabled by adding this at the end of /etc/rc.local
If I then create a CODESYS program for the Raspberry Pi and add a DS18B20 device beneath the Onewire master everything appears to work. If I issue a reset of any type from codesys and start the program everything on the 1-wire bus works.
If I set the project as a bootproject and reboot the raspberry pi then the Onewire_master shows a fault
As you can see the DS18B20 is functioning, but the Onewire master has a fault that I cannot clear and it has not scanned the bus successfully.
I am using CODESYS for Raspberry Pi 3.5.11.20.
The important part of the issue is that I cannot provide a solution where the bus us scanned successfully at power on. I presume that if the bus scanned successfully the driver would show as running.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for the tip - unfortunately it hasn't solved this problem.
First I ran some experiments:
I added this program to my application and ran it on the 1-wire task
Having download it to a Raspberry Pi with two 1-wire devices connected, two devices were detected by the scan as the application started.
I then connected a third device, set xScanNow to TRUE in the debugger and the additional device was found.
So calling the scan will find devices that have been added after the raspberry Pi was booted (it doesn't remove devices from the list that I have unplugged - not a real problem).
I then rebooted the raspberry Pi (Used ssh and typed "sudo reboot"), when I logged in again the Onewire master was showing an error as before, no devices were found. I set xScanNow, it took a couple of seconds to complete, but the result was FALSE and no devices were found.
I can confirm that the DS18B20 not only shows as green while the master has failed, it is operational, I can see the temperature being measured.
As before if I issue a reset Warm everything springs into life.
While in the failed state I looked on the Raspberry pi in /sys/devices/w1_bus_master1 to see if I could identify any faults. The content of the w1_ files is shown below and all looks correct to me
w1_master_add: write device id xx-xxxxxxxxxxxx to add slave
w1_master_attempts: 34
w1_master:_max_slave_count: 64
w1_master_name: w1_bus_master1
w1_master_pointer: 0xd9099e08
w1_master_pullup: 1
w1_master_remove: write device id xx-xxxxxxxxxxxx to remove slave
w1_master_search: -1
w1_master_slave_count: 3
w1_master_slaves:
28-000007648922
29-0000001863e6
29-0000001ac513
w1_master_timeout: 10
w1_master_timeout_us: 0
From my point of view there are two problems (bugs?), firstly why does the master end up in this state following a reboot? Secondly why can I not recover from the state.
To look at the first issue, at an educated guess, the problem could be caused by CODESYS starting before the 1-Wire kernal system in raspbian has finished initialising. Is it possible to delay the CODESYS runtime from starting for a few seconds - at least as an experiment?
As far as the second issue goes. It appears that the kernal driver is working perfectly, so I do not understand why the driver will not recover.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
i have reproduced it, for my 2 connected onewire temp devices this works.
What is the difference between the onwire for UniPi
and the Standard CODESYS onewire solution?
Zitat:
The driver has been added to raspbian (2017-11-29-raspbian-stretch-lite.img) and the device is enabled by adding this at the end of /etc/rc.local
echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-1/new_device
Why you need this?
guess the runtime is allreaedy started way before rc.local is called... with this.
Even after reboot it works with my two onewire readings.
BR
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is nothing special about the UniPi 1-wire solution as far as CODESYS is concerned. The UniPi 1.1 add-on board uses a ds2482 i2c one wire master device. There is a kernel driver for this that can be used in place of the w1-gpio and creates the /sys/devices/w1_bus_master1 device.
I believe that the issue is that rc.local is executed after the codesys runtime has started, and so on the current configuration I have w1_bus_master1 does not exist when the codesys runtime starts, then when rc.local is executed the device appears, but the CODESYS Onewire_master refuses to recognise it and stays in an error state (despite the individual devices functioning).
I have done some experiments with an overlay as a different way of enabling the kernel driver for the ds2482, and I seem to be able to enable the kernel driver earlier, then CODESYS doesn't show a problem.
I guess as a general issue this should be ignored. If you want to make the CODESYS driver robust to late starting of the kernel driver please email me and I will help create a test case for you. But I think I can avoid the problem.
regards David
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ingo Hornberger hat geschrieben:
Thanks David for the offer to reproduce it. In fact this is a general problem for many CODESYS drivers. Most of them need to be ready at start up.
Our current recommendation is to put those modules to /etc/modules or /etc/modules.d/. I expect that this would have solved your problem, too.
Gesendet von meinem LG-H870 mit Tapatalk
Hi Ingo
Is it possible to put modules in /etc/modules or /etc/modules.d/ and does that solve the problem? Verified?
I would be grateful for instructions. Witch files do i put there?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a Raspberry Pi with a ds2482 i2c onewire bus master connected. The driver has been added to raspbian (2017-11-29-raspbian-stretch-lite.img) and the device is enabled by adding this at the end of /etc/rc.local
echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-1/new_device
If I then create a CODESYS program for the Raspberry Pi and add a DS18B20 device beneath the Onewire master everything appears to work. If I issue a reset of any type from codesys and start the program everything on the 1-wire bus works.
If I set the project as a bootproject and reboot the raspberry pi then the Onewire_master shows a fault
As you can see the DS18B20 is functioning, but the Onewire master has a fault that I cannot clear and it has not scanned the bus successfully.
I am using CODESYS for Raspberry Pi 3.5.11.20.
The important part of the issue is that I cannot provide a solution where the bus us scanned successfully at power on. I presume that if the bus scanned successfully the driver would show as running.
Hi,
please use the improved onewire example here:
l viewtopic.php?f=23&t=6247&p=16920#p16920 l
BR
Edwin
Hi Edwin,
Thank you for the tip - unfortunately it hasn't solved this problem.
First I ran some experiments:
I added this program to my application and ran it on the 1-wire task
Having download it to a Raspberry Pi with two 1-wire devices connected, two devices were detected by the scan as the application started.
I then connected a third device, set xScanNow to TRUE in the debugger and the additional device was found.
So calling the scan will find devices that have been added after the raspberry Pi was booted (it doesn't remove devices from the list that I have unplugged - not a real problem).
I then rebooted the raspberry Pi (Used ssh and typed "sudo reboot"), when I logged in again the Onewire master was showing an error as before, no devices were found. I set xScanNow, it took a couple of seconds to complete, but the result was FALSE and no devices were found.
I can confirm that the DS18B20 not only shows as green while the master has failed, it is operational, I can see the temperature being measured.
As before if I issue a reset Warm everything springs into life.
While in the failed state I looked on the Raspberry pi in /sys/devices/w1_bus_master1 to see if I could identify any faults. The content of the w1_ files is shown below and all looks correct to me
w1_master_add: write device id xx-xxxxxxxxxxxx to add slave
w1_master_attempts: 34
w1_master:_max_slave_count: 64
w1_master_name: w1_bus_master1
w1_master_pointer: 0xd9099e08
w1_master_pullup: 1
w1_master_remove: write device id xx-xxxxxxxxxxxx to remove slave
w1_master_search: -1
w1_master_slave_count: 3
w1_master_slaves:
28-000007648922
29-0000001863e6
29-0000001ac513
w1_master_timeout: 10
w1_master_timeout_us: 0
From my point of view there are two problems (bugs?), firstly why does the master end up in this state following a reboot? Secondly why can I not recover from the state.
To look at the first issue, at an educated guess, the problem could be caused by CODESYS starting before the 1-Wire kernal system in raspbian has finished initialising. Is it possible to delay the CODESYS runtime from starting for a few seconds - at least as an experiment?
As far as the second issue goes. It appears that the kernal driver is working perfectly, so I do not understand why the driver will not recover.
Hello,
i have reproduced it, for my 2 connected onewire temp devices this works.
What is the difference between the onwire for UniPi
and the Standard CODESYS onewire solution?
Why you need this?
guess the runtime is allreaedy started way before rc.local is called... with this.
Even after reboot it works with my two onewire readings.
BR
Edwin
Hi Edwin,
There is nothing special about the UniPi 1-wire solution as far as CODESYS is concerned. The UniPi 1.1 add-on board uses a ds2482 i2c one wire master device. There is a kernel driver for this that can be used in place of the w1-gpio and creates the /sys/devices/w1_bus_master1 device.
I believe that the issue is that rc.local is executed after the codesys runtime has started, and so on the current configuration I have w1_bus_master1 does not exist when the codesys runtime starts, then when rc.local is executed the device appears, but the CODESYS Onewire_master refuses to recognise it and stays in an error state (despite the individual devices functioning).
I have done some experiments with an overlay as a different way of enabling the kernel driver for the ds2482, and I seem to be able to enable the kernel driver earlier, then CODESYS doesn't show a problem.
I guess as a general issue this should be ignored. If you want to make the CODESYS driver robust to late starting of the kernel driver please email me and I will help create a test case for you. But I think I can avoid the problem.
regards David
Thanks David for the offer to reproduce it. In fact this is a general problem for many CODESYS drivers. Most of them need to be ready at start up.
Our current recommendation is to put those modules to /etc/modules or /etc/modules.d/. I expect that this would have solved your problem, too.
Gesendet von meinem LG-H870 mit Tapatalk
I have the same problem using the latest version. It here any solution i can apply?
Hi Ingo
Is it possible to put modules in /etc/modules or /etc/modules.d/ and does that solve the problem? Verified?
I would be grateful for instructions. Witch files do i put there?
It should, but it's not verified, as I don't have the exact same module here.
Gesendet von meinem LG-H870 mit Tapatalk