Today I was testing the RoboPro I2C elements with a simple test program:
- RoboPro I2C test program
- bug(main).png (44.81 KiB) 1823 mal betrachtet
Sometimes it was working but also it was generating errors.
The source of the problem is the same as I already had seen with my SLI experiments:
the 5 sec SLI bug.
In the console log the line "ERROR calling read" is an indication for that problem.
Code: Alles auswählen
IOs/s DL=98 OL=98, Cam DL=0 OL=0, I2C tr=0 by=0
IOs/s DL=99 OL=99, Cam DL=0 OL=0, I2C tr=0 by=0
IOs/s DL=99 OL=99, Cam DL=0 OL=0, I2C tr=0 by=0
ERROR calling read
Closing I2C server connection from 192.168.10.136
I2C Server Thread terminated
IOs/s DL=97 OL=97, Cam DL=0 OL=0, I2C tr=0 by=0
In case a RoboPro is not using one of his I2C element (or SLI) during the first +/- 5 sec, the TXT runtime is losing the connection with these function.
It can't allocate all these functions any more.
Are there workarounds for this bug?
Yes there are:
1)
For the SLI I already publish a workaround, add a very simple KeepAwake function to the SLI,
call this function at least every 4.5 sec:
- KeepAwake SLI
- bug(workaround1).png (16.07 KiB) 1823 mal betrachtet
2)
When you working with only RoboPro basic elements, then there exists also a workaround.
A I2C dummy read or write to a fake I2C address. In this case the element error output workflow needs be connected with the main workflow.
The dummy I2C element is producing an error all the time.
The I2C element error handleing property is set on "Abort immediately"
- KeepAwake with I2C dummy element
- bug(workaround2).png (14.59 KiB) 1823 mal betrachtet