PP220.1043-75 test CF image or Automation Studio 3.0.90

I have a 4PP220.1043-75 that is rebooting at startup (no more support from industrial machine manufacturer where it is installed)

I would like to exclude corruption of CF , so I would like to create a “void” program, but I think I need automation studio 3.0.90 … or an image of a “blank test” CF.

Can someone help me?
How can I get Automation Studio 3.0.90?

BTW: VCBOOT.VR file is loading, CF files are visible on PC

Thank you
Roberto Dario

If it is an hw issue, you can try out the test where you start PP without CF. It should boot up and show you a message like “CF not found” or something similar. If it is rebooting even without CF, then it will be, from my perspective, evidence of an hw failure, short circuit, or something similar. AS 3.0 is available on request. How to Obtain Older Versions of Automation Studio [ AS2 | AS2.7 | AS3.0 | AS4.x ]

Thank you, I will try to ask AS3.0.

If I boot without CF I get a message that “VCBOOT.VR” is missing and panel stops there (no reboot).
With CF inserted, it loads, then blank screen and reboot.

Hi @robyd,

just as a side note: you wrote that the files of the CF card are accessible on the PC.
So you could have a look for a file called “arlogsys.br”, which is the main logger module of the PLC.
The location depends on how the system was setup: either in a own partition named “DATA1”, subfolder “RPSHD/SYSROM”, or if the CF just have 1 partition the in the “DATA1” folder + subfolders as before.
Here’s a screenshot as example how it could look like:

The content of a logger file can be displayed with Automation Studio → Logger, so maybe we can gather some more information about the the root cause.
But to be honest: it’s also possible thatwe get “nothing new” out of it, that depends on when the boot process is interrupted by the reboot … nevertheless it’s worth a try.

If you don’t have Automation Studio (yet): if you want you can upload the file here and we’ll have a look into (of course, only if possible / allowed by your side → your data = your decision :wink: ).

Best regards!

img.zip (3.7 MB)

Thank you Alexander,
I can’t find the file “arlogsys.br”.. In attachment I uploaded all I can see.. I don’t know if you have time to take a look!

In the meanwhile I requested old AS to local office (waiting for reply.)

Best Regards,
Roberto

Hi,

thanks for the data.
This is quite interesting! I don’t know enough about the project age and with what version it was created (It seems that the project was created with AR2.67 and therefore some Automation Studio 2.xy version).
As this is a quite old setup I can’t swear how the folder content should look like (I don’t have any data to compare it with), but I’m relatively sure that the’re some files missing in the SYSROM directories, at least the logger module itself.
I can’t say if the USRROM directories are still complete, but at least I saw there some project-typical modules.

In the end I’m not sure if the missing logger module is the root cause, but for me it looks like that a file system corruption or something similar happened.

Best regards!

Thank you very much for your support.

I have some news so I share here:
With AS3.0.90 I made a brand new image for the panel.

I put the CF on panel.. first boot it taked longer (it seems also he rebooted 1 time).. and then it started perfectly with the static demo page I made.
So: HW is working

Now comes the best part! :slight_smile: ..I put the original CF and magically it started!

It seems that my image resetted something inside and now also original CF is working!
It would be interesting to understand what happened..

Best Regards!
Roberto

Could it be that brand new project has updated something internally? Loader,fw or something..

Hi,

okay that’s really weard… sure, there’s always an explanation for everything, but I personally haven’t had seen something like that in past.

There’s one thing that’s is definitely cleared when the CF image is changed: the NVRAM - most of the PLCs have a non-volatile memory based on (mostly) battery-buffered SRAM. Two different information can be stored there: variables and data modules.
When the image / CF is changed, by default this memory is flushed - so data modules are deleted, and variable values are set to 0. Additionally, possibly firmware updates are processed.

Without knowing more about the project, it’s hard to say what really lead to a functional hardware again - in the end I’m glad to hear that the system is running again.

Best regards!

But this is good point. @robyd check your machine parameters, if there are any. Could be that you have some default values there. If everything is ok, be happy that you have solved it ) show must go on :slight_smile:

@alexander.hefner thank you for the info about NVRAM, battery was low and a colleague changed it.
So.. probably NVRAM set to random values that make the program to reboot for some exceptions.

@kovarj I will let you know, in the next days the panel will be mounted again on the machine.. at that time we will discover if some parameters are missing! ..hoping to have some docs about them!

Ok I marked this summary as a solution. if you find something interesting, would be great if you update us :slight_smile: