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
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_remove: write device id xx-xxxxxxxxxxxx to remove slave
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.