mqi2r

Hi, yes I am aware these are mismatched versions to what Kunbus recommend. We have also tried the latest official combination of software versions with still the same issue. Software Combination 1 Codesys Development System 3.5.17 SP4 Codesys Control for Raspberry Pi 4.5.0.0 * Revolution Pi Bridge driver 1.2.1.0 Software Combination 2 Codesys Development System 3.5.18 SP4 Codesys Control for Raspberry Pi 4.6.0.0 * Revolution Pi Bridge driver 1.3.0.0 From what we can tell, the issue for us manifests...

Yes the element seems to call the handler a number of times but it seems to work fine (when I use a global variable for the DT). Yes still no luck for me. The event is called and the trend updates but it just shows the last X minutes rather than from what I select in the picker. I'm currently using CODESYS Control Win 3 x64 3.5.18.40 and CODESYS Visualisation 4.3.0.0 although my project/development environment is 3.5.19 My complete method is below along with some screenshots: METHOD ValueChanged...

This is excellent. Thank you. I have been able to implement it (I modified it from Date to DT as I wish to be able to select the start date and time) except for the part where the pbNewValue is cast into the pDate (pDT in my case) and dereferenced. I seem to only get the element in the DT that has changed (so pbNewValue is a pointer to the byte which has changed, if I set the minutes to 45 in the Date/Time Picker I get 45 as the pbNewValue). I have had success with having the Date/Time Picker writing...

I too have the same issue. After 1 or 2 days Codesys appears to lock up or freeze. I was able to SSH into the RevPi but no matter what I did I could not stop/kill the codesyscontrol.bin process. I had to reboot the device and it was operational again. Codesys Control for Raspberry Pi 4.5 CDS 3.5.17 Patch 4 RevPi Bridge Library 1.2.1.0

I too wish to know a way to do this. There is frustratingly no information on setting sane defaults for the date/time range.

Hi, a watchdog exception is usually that your task took too long to execute and tripped some watchdog timeout. You should review your Task Configuration for the task called "Task" in your case and see if a watchdog has been enabled and if so, ensure the time is long enough for the task to execute. During development or troubleshooting you may wish to disable the watchdog.

I know on the pi-based systems you need to be editing /etc/dhcpcd.conf to configure the network correctly. Editing resolv.conf manually and trying to keep it from changing is not worth the hassle anymore. I do miss it though.

Double post sorry.