Hi,
The PLC is able to upgrade / downgrade firmware of hardware modules like the CPU itself, X2X modules and so on, to the dedicated firmware version that is defined in the project. It is checked at every boot if the firmware of hardware modules found are the same firmware versions as defined in the project, and if there’s a mismatch, a firmware exchange on the hardware module is done automatically by the system.
The warning 30027 means, a firmware file / the dedicated firmware file defined in the project is not found in the PLCs storage. Normally, the slot id of the module is named in the “<>” brackets in the logger entry.
As there’s no slot id mentioned, honestly spoken I’m not sure if it’s the PLCs firmware file itself that is missing, or if it’s a file of an optional hardware module defined in the project but not found at boot (for example some X20 module that’s configured with module ok = false and that’s not plugged right now).
Additionally, as far as I remember this warning can happen when using dynamic hardware configuration: for example if you build the hardware tree dynamically by software instead of a fixed configuration in the project, then Automation Studio does not know which hardware modules will be present at runtime and therefore will not load the corresponding firmware files to the PLC (to add firmware files in such configurations, there’s a CPU property setting “additional supported hardware”).
About your boot issue:
I’ve never heard that a PLC does not boot at all because of a missing firmware, but I can’t swear if this never could happen honestly spoken.
As firmware is installed in the hardware itself, sich a message just points out that a firmware upgrade/downgrade to the defined project version isn’t possible, but the hardware nevertheless should work… but as I said, I can’t guarantee to 100% that it’s really impossible as cause, maybe some very rare dependencies between “frontend project settings” and “missing support of a function in the firmware backend” could lead to issues. But even then I would expect more a SERV or DIAG boot then an unresponsive hardware.
“R/E” static read on indicates normally a BOOT or SERV mode, but under normal conditions also something should happen on the “RDY/F” and/or “S/E” LED - I don’t know any status of the PLC, where just “R/E” is on, without any reaction on other LEDs latest after some seconds after power on.
“DC” read means that there’s no backup battery installed in the PLC (which means that SRAM isn’t non-volatile and RTC date time is not buffered).
Best regards!
Thank you for your fast replay and detailed information.
I will take this information to find a solution for this warning.
Ps. when it happens DC and R/E led are Both on. If I then make an online connection with the PLC, it is in BOOT phase with IP 0.0.0.0.
Power down/up again and the system runs.
In general it happens when I send a project update where the system tells me " have to reboot" .
After sending the file then sometimes the system doesn’t restart. Power up/down solves the problem.
Hi
Okay, thats weird.
I don’t have a CP168x available right now, but I checked my CP1586 (which I think behaves similar regarding the LED states):
when my PLC is in BOOT mode, I see the state “R/E = solid red” and “RDY/F = solid yellow” (and “DC = solid red” but this is just because of the battery, no operation mode is signaled by “DC”).
So it looks like really strange to me, as I can’t explain in what state the PLC is if just “R/E” is solid red and “RDY/F” is off.
What I’ve also seen is, that when the system boots normal from the CF, before “R/E” is switched on (independent of the color), I see some activity on the “CF” LED which means, that the CF card is accessed.
So it would be interesting if you see any activity on the “CF” LED (even if it’s just a short flash) before “R/E” shows any activity… because from my feeling, it sounds like something happens in a very early stage of (re)boot.
Do you have a second CF card available (I assume it’s a B&R CF right?) just to test if the behavior changes?
Best regards!
Just fyi, 0.0.0.0 in BOOT mode is okay, as in that mode the onboard AR is booted and the ETH interface in BOOT mode is DHCP client (the onboard AR is not installed on the CF but in the hardware, providing a minimal set of functionality to commission a PLC).
Hello,
just to add some information to the previous comment. The X20CP1684 has the switch to select either an integrated flash drive or removable CompactFlash card as the application memory
Good morning,
I made a video yesterday afternoon; First DC and R/C led’s are on (red) then cf is started and DC is colored yellow.
Everything runs normal without problems so I couldn’t make a video of the startup problem.
The days before, it was the same startup: but before the startup was ready, all leds are going off and the DC and R/E led becomes red again.
Then the system was trying to start again, mostly ok, but somethimes not (DC and R/E leds stay static with the red status)
One of the updates I did yesterday is made a changement in the memory dividing (user ram/remanent memory).
I noticed that the usage of the remanent/memory was about 99,6%. Now it is 85%. It should not cause that problem, but hopefully it did because then
the startup problem is solved for now.
Yes I know, but the selector is set on the external CF card.
Hi @Harry_Schutte , what is status of your issue, can you update us and Help Us Keep the Community Organized?
