CODESYS - the IEC 61131-3 automation software

Welcome to the official CODESYS Forum
Deutsche Version English version russian version 
It is currently Sat May 26, 2018 6:41 pm

All times are UTC+01:00




Post new topic  Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Fri Dec 08, 2017 9:54 pm 
Offline

Joined: Fri Nov 23, 2012 11:42 am
Posts: 54
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
Attachment:
onewire_master.png


Attachment:
Screen Shot 2017-12-08 at 20.46.11.png


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.

Attachment:
Screen Shot 2017-12-08 at 20.48.03.png


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.


You do not have the required permissions to view the files attached to this post.


Top
   
PostPosted: Fri Dec 08, 2017 9:59 pm 
Offline
Site Admin

Joined: Mon Sep 05, 2005 9:42 am
Posts: 2671
Hi,
please use the improved onewire example here:
viewtopic.php?f=23&t=6247&p=16920#p16920

BR
Edwin


Top
   
PostPosted: Sat Dec 09, 2017 7:21 pm 
Offline

Joined: Fri Nov 23, 2012 11:42 am
Posts: 54
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
Attachment:
Screen Shot 2017-12-09 at 17.37.30.png


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.


You do not have the required permissions to view the files attached to this post.


Top
   
PostPosted: Mon Dec 11, 2017 7:03 am 
Offline
Site Admin

Joined: Mon Sep 05, 2005 9:42 am
Posts: 2671
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?

Quote:
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


Top
   
PostPosted: Mon Dec 11, 2017 8:50 pm 
Offline

Joined: Fri Nov 23, 2012 11:42 am
Posts: 54
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


Top
   
PostPosted: Sun Dec 17, 2017 9:14 am 
Offline

Joined: Mon Dec 13, 2010 3:02 pm
Posts: 27
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 6 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited