When I use the FUNCTION_BLOCK ModbusChannel I have to sepcify the integer iChannelIndex It can easily go wrong if one has many channels. It would be better if one could use the name. Is that possible? Attached a snippet of the channel name and the channel index to the left.
CODESYS Control for Raspberry Pi MC SL v4.4.0.0 CANopen_Manager 4.2.0.0 I did not call rm directly from my TASK-i2c, it was trough the attached python script. It is not always a problem happens, but sometimes a rm takes a long time. I reduced the amount of calls to logi2c.py but I don't understand why TASK-i2c sometimes can cause problems for TASK-CAN
CODESYS Control for Raspberry Pi MC SL v4.4.0.0 CANopen_Manager 4.2.0.0 I did not call rm directly from my TASK-i2c, it was trough the attached python script. It is not always a problem happens, but sometimes a rm takes a long time. I reduced the amount of calls to logi2c.py but I don't understand why TASK-i2c sometimes can cause problems for TASK-CAN
3.5 18 SP2 I think the control is 4.2.0.0. I am not in the office before on Wednesday.
I have noticed that a rm file1.txt command on a shell has an impact on the cycle time for a TASK writing to file2.txt. Seen in the Monitor fane of the Task configuration Furthermore if a TASK makes a system call like rm, its cycle time increases of course but it seems to have an invisible impact on other TASKs too. I have a TASK for handling communication over the CANbus (SPI) where it stops sending "Heartbeats" for many seconds when another TASK does a system rm. Why is that not seen on the Monitor...
I try with BYTE_TO_HEXinASCII but I cant get it right. How do I convert a word value like 15432 to the HEX text string '3C48'
CODESYS Control for Raspberry Pi MC Does CODESYS use its own native driver for I2c? I have a python script communicating with a device simultaneously with a CODESYS doing the same. The bus is not saturated. But I get many read errors
If my application does some kind of violation which makes it cast an exception it will trigger my real watchdog which results in a reboot. Unfortunately the log it seems only shows the boot sequence. Is it possible to see what happen before reboot?