Dear Community,
We are experiencing a problem with the C80 PLC, going to Service mode randomly and the logger displays - Cyclic operation: Incorrect checksum of B & R module. We are using the DatObjCreate function block to retain memory in the C80. It seems like something related to memory retaining.
Please help me to understand cause of this issue and finding a solution for it?
Hello
have you already tried to set the Option Input of the FUB to doNO_CS? If I understand it correctly, this should disable the checksum check.
Detailed information in the help:
https://help.br-automation.com/#/en/4/libraries%2Fdataobj%2Ffbks%2Fdatobjcreate.html
Cheers
Christoph
Hi,
like Christoph already mentioned, the option doNO_CS disables the checksum of a data module . But this option can only be used when the data module is in RAM (DRAM or USERRAM).
If using a ROM target memory, typically the USERROM, then the option is ignored, and the module will always have a checksum.
The checksum of a module is checked while booting, and also “from time to time” when the PLC is in run.
And: every BR module has a checksum, also for example a task. The checksum is used to ensure the module integrity in the memory.
Hope that information helps a bit.
Best regards!
Hi Alexander,
Firstly, Thank you for the valuable information.
We are using C80(4PPC80_0156_13B) PLC. In the logic it’s given DatObjCreate.0ption := 0 and the MemType is doUSRROM.
For retaining an encoder position you will need a single or multiturn absolute encoder.
In the mappMotion mpAxisBasic fub there already possibilities to backup this position to a remanent (retain) variable.
See homing mode : mcHOMING_RESTORE_POSITION
https://help.br-automation.com/#/en/4/motion/mapp_motion/programmierung/bibliotheken/technologie/axis/datentypen_und_konstanten/mpaxishomingoptionstype.html
Hi,
like Corne already mentioned, for axes the’re already prepared functions for storing encoder positions.
For the sake of completeness, I want to anwer your general question about data modules:
the code snippet looks okay assuming that “pData” contains the address to the variable / memory area to store, and “sizeData” the length in byte of this variable / memory.
From the screenshot, I can’t see if the DatObjCreate_0() is called continuously until it returns a status other than ERR_FUB_BUSY (65535), which is neccessary since this function block works asynchronous.
So after this call has finished, the data module should be initially created containing the data where “pData” points to (additional info: a data module has always the fixed size that was configured while creation von “.len” parameter - it’s not possible to change this size, if you need to change you have to delete a module and create a new one).
What I also can’t see in the snippet is changing / writing the module content:
I assume you have to write data also after creation of the module, and since the module is stored in USRROM it needs a checksum, so the write access is only allowed to be done by DatObjWrite - a write access by pointer would lead to checksum error.
And, last but not least: please be aware, a data module that is stored in USRROM in the end is a file (BR module). In case of power fail, it’s not guaranteed that this module really contains the latest data you wrote into (this is technically not possible) → for example, if you write cyclically (very) fast changed data to the data module, and a powerfail happens, it could happen that the data module contains “older data”.
If such a use-case " write cyclically (very) fast changed data" exists, and the amount of data is not too big, the I recommend using USRRAM as target memory for the data module (availiability and size of USRRAM, which technically is a PLC built-in SRAM or FRAM, depends on the target system).
Best regards!
Hi Christoph,
Thank you for valuable information
@alexander.hefner , We have a C80 controller, and it does not have permanent variables.
Previously with CP1685, we configured permanent variables to restore the position of the multi-turn encoder and some machine parameters that need to be retained on power on-off cycles or program downloads or warm restarts.
What is the best option to retain the memory for encoder and some variables in C80.
I have a concern on writing data to ROM using Dataobj function. EEPROM memory will have some limitation of write cycles rite.
Will be helpful if have some references to example programs.
Hi @subin ,
I don’t have a hardware here, but as I know you have some SRAM/FRAM also on the PPC80 systems… at least, it looks like in Automation Studio, where 64k of it is available in the configuration.
The default configuration uses the whole 64k for remanent variables, but you can change this configuration (right-click “PPC80…” in hardware tree → configuration → memory configuration).
This is the default setup:
And here an example config using 12k UserRAM (if you need UserRAM), and the rest 48k for variables, 1024 Byte out of the variables for global remanent ones.
Finally, a global remanent variable can then declared to a permanent one like it’s done in X20 PLC.
Best regards!
… some hours later, I mentioned that my 2nd sample screenshot uses only 60k in sum instead of 64k … of course all the 64k can be configured and used like needed, so don’t be confused only because of I’m not able to use 2 numbers where the sum result is the same then before 
