I have a problem with the CD_Transfer_50936 from the PC to the control panel (power panel).
The situation is as follows:
The panel is currently running only the operating system without a project. This project is now to be uploaded using a CD transfer. For this purpose, I have connected the panel (communication port) and the PC (COM 1 port) with an RS232 cable in series.
The cable has the following configurations:
1 to 4; 2 to 3; 3 to 2; 4 to 1; 5 to 5; 7 to 8; 8 to 7; 9 to 9; (6 is not connected).
When the transfer file is opened, the transfer starts immediately.
Error # 4024 occurs twice:
7: DeleteMemory FIXRAM
PVI Error # 4024: Memory type does not exist or cannot be deleted (_CPclearMem)
and:
9: DeleteMemory MEMCARD
PVI Error # 4024: Memory type does not exist or cannot be deleted (_CPclearMem)
Subsequently, the transfer continues until these error messages appear.
Error # 4808 occurs multiple times (exactly 15 times): 54: Download: “.\init_all.br”,“ROM”
PVI Error # 4808: No connection to RPS available
In the following error messages, the bold marked text differs, but the error # 4808 is always the same.
After the last error
(69: Download: “.\exbedien.br”,“ROM”
PVI Error # 4808: No connection to RPS available),
the transfer ends and shows the status FAILED.
Is there any way to eliminate these errors and complete the CD transfer?
Thank you very much
the cableing looks good, in most cases you need at least 2 → 3, 3 → 2, 5 → 5 for a serial connection.
I think, the named “CD_Transfer_50936” is a Runtime Utility Center “PLC setup batch” that was prepared by the developer of the PLC project - what is done there inside is very user project specific and most of the modules (the “.br” files) are also developer specific.
So it’s hard to say what’s exactly going wrong:
error 4808 means “no connection to the PLC”. So I assume the “batch” looses the connection “somewhere on the run”, maybe because of a (error) reboot of the system? → does anything happen with the RUN LED of the Power Panel while transferring, for example does it turn “from green to red” (which could be a indicator for a error stop)?
error 4024 could be normal / clear: if your system for example is a PP15/PP35, there’s no MEMCARD slot on this devices. Also about the FIXRAM error, if no FIXRAM is configured in the project, it can’t be deleted → what type of Power Panel do you have exactly?
Could you please post the complete text output of the transfer run? Maybe that gives us an impression if it “fails from the beginning” or later “somewhen in the batch process”.
The status message works on the panel via separate RUN and ERR LEDs. The error LED lights up for error # 4024 (numbering in the screenshots: 7 and 9), during both cold and warm starts (numbering in the screenshots: 12, 22, 34), as well as from the first Error # 4808 message.
Hardware: PP41, QVGA
Firmware (if important): 01.33
Additionally, the panel has this number: 4P3040.00-K45
Here is the complete text output of the transfer run:
Since it’s a PP41, I think the both errors 4024 can be ignored - I asume those memory types aren’t configured / used, so it’s okay that they can’t be deleted.
It looks like that all system modules, libraries, and visualization parts are transferred (until line 53 “visu.br”). Line 54 seems to be the first user task that has to be transferred, and then the communication breaks.
At least now we know, that the initial settings of the serial interface are right, because many modules are already transferred. Unfortunately it’s not possible for me to say exactly, why the transferring breaks, most often (but not always) the reasons are:
the program that is transferred accesses a hardware module which is not connected to the PLC → the PLC stops and boots into service mode.
the program changes the serial interface settings by code → the PLC stays in RUN, but the serial connection settings aren’t no longer valid.
In both cases, it could be possible to transfer the rest of the modules when PLC is in service mode (because then the user code is not executed).
The “problem” is, that your instruction list starts always with “delete memory → transfer operating system (PP00_V23.br) → transfer system configuration (sysconf.br)” Because of that we can’t force the PLC to stay in service mode trying to transfer the rest of the code (at least I don’t how this could be managed without editing the transfer list instructions)…
… do you have still contact to the developer / the company who prepared the project (and hopefully also this transfer instructions list), to dig a bit more into deep what the root cause could be?
I am in contact with the company, in whose system this panel is to be installed, because the old one is defective.
The story of the “new” panel suggests, that it is a hardware or a memory error:
The “new” panel was already sent in to have the program for our system loaded onto it (they used B&R AS2.4). That worked, but after the panel arrived back, only the operating system was running on the power panel again.
The backup battery is not new with 3V (it’s a 3V battery) (new it would be about 3.2V at idle), but it’s not bad either (that would be about under 2.7V).
So in search for the error, a CD transfer was created and provided to me to check, if the program is lost again when the power is turned off. But this CD transfer doesn’t work.
For this reason, I would like to send in the panel to have it checked by B&R.
Who do I have to contact for this?
Is there a special address for such cases?
about the battery: what I can see in the transfer history is, that every program should be transferred to User ROM - so the programs itself should be stored into the flash memory of the device, and this memory does not need the battery at all.
Of course data will be lost if battery is empty, for example the values of variables inside the programs, but not the programs themself should get lost.
What I wonder about is, that the conncetion loss is happening exactly when the first program (task) is transferred. The modules that are transferred before this program are transferred to the same memory (also UserROM which is the flash memory of the target), but those transfers work… that not “feels” like a typical hardware issue, but yes, maybe it’s one, hard to say.
To check hardware, you have to send it directly to the repair department in our headquarter in Austria (including a detailed issue description).
Please find the address here (screenshot from the website):
If possible, I would at least suggest to try two more things if possible:
loading back the logbook of the PLC to see what error entries are in there
before transferring the user tasks (so before line 54) switching the PP to service mode, wait some seconds for reconnection, and try to transfer the rest of the software in that mode
Of course, for both actions changes in the download script or additional new scripts are needed to be done/prepared by the manufacturer.
