I have recently run across what I think is a bug in the FactoryLink v6.6(SP1) software.

I had made a change to my current system, and performed the usual Multiplatform save. I restored it to one of my operator stations, and when I started FactoryLink, I got an error stating that it could not open file "shared/ct/sys.ct".

Upon investigation, I noticed that none of the CT files in the FLAPP/CT directory were there. The same was for the ../Shared/CT and ../User/CT directories.

After trying everything I could think of, the only thing that could have changed was the fact that we are now into the year 2012. So I rolled back the system clock on the computer to the year 2011, and restored the application again. I then started FactoryLink, and all of the CT files were generated, and the application is running fine. I then changed the system clock to current time.

Has anyone else seen this issue? I would hate to have to change the system clock every time I have to do a restore.

Thanks in advance for your help.

Dlogger

 

Hi Dlogger,

I do not have a solution yet but know you are not alone, this seems to be worldwide. I've heard a rumor or a workaround but do not know it yet.
When I do I will post it here.

Please do the same if you find a solution.
DF

 

Hi,

Very rare the problem but the workaround should be what you did or this:

1) Set your PC time to 2011 and run your FL app to generate all .ct files

2) Copy these files in other folder

3) Set your PC time to 2012 and copy again the .ct files from the new folder to {FLAPP}/CT, ../Shared/CT and ../User/CT directories.

4) Your app will run without problems

As you know, the .ct files are generated when the app runs for first time and regenerated when there is a change in some task's configuration table.

What happens if you delete all .ct files manually (PC time = 2012) and you run the FL app again, are they created with no problem?. I try to find out if the problem is caused by a restoration process or not.

In normal situations, you can delete all .ct files manually whenever and FL will create them the next time your app is running. It's a "manual way" to force a creation of these files.

Let me search/study a little more your problem to find a final solution.

Best regards.

Saludos desde Venezuela
Gustavo A. Valero P.

 

Thanks to DF and Gustavo for their replys.

Sounds like my workaround should do the trick. It's a pain, but unless someone has a better solution, I'll go with that.

I did as Gustavo suggested and deleted all of the CT files with the system clock at 2012. I then ran the application again, and the CT's were generated properly.

If anyone has any additional information, just post it here.

Thanks for all your help,
Dlogger

 

Interesting regarding the CT files.

Apparently Siemens has just come out with patches for 6.6.1 and 8.02. I'm not sure about any others yet.

I have not yet determined who to contact within Siemens to acquire these patches.

Will let you know what I find out.
DF

 

Ok. at least we are narrowing the problem sources.

What Windows version are you using: 2000, 2003, XP. etc?.

Try this please and let us know the results:

1) Restore your original FL app with the system clock set to 2012

2) Run 'ctgen -c -r' from the drive:\{FLAPP} directory at the system prompt (this will generate these files manually)

3) Check if the .ct files were created manually and your app runs fine

4) With year = 2012, save your app as an MPS file and later restore it again and run your app.

Regards.

Saludos!
Gustavo A. Valero P.

 

DF,

The last service pack for FL 6.6 is the file "FL66 SP1_base_di.zip" released on 10/2/1998 (FactoryLink Service Pack 1 Base and DI install) but there are some newer patches to specific tasks/issues.

If you need one let me know, I can find it and send it to you (FL 6.6, 7.x or 8.x)

Bye

Saludos!
Gustavo A. Valero P.

 

Hi Gustavos,

Interesting exercise but no joy.

I did as you requested on a test platform running on windows XP sp3.
When I ran ctgen -c -r only one file was created: type.ct

If I run ctgen for a specific task then that file is created. eg. ctgen al_info.ct will create al_info.ct.
Interestingly, if I manually create all 41 files that were originally in the folder then FL will start. I do not know at this point whether it is a viable system yet as it is late in the day.

I am waiting for serial numbers to receive my patch from Siemens but I am interested in this experiment of yours.
If you have further attempts please let me know.

DF

 

Gustavo,

We are still running Window NT 4.0.
We have already tried the restore and the CTGEN -c -r that you talked about above with the clock = 2012.

The CT files do not generate, and we get our original error of not being able to find the CT files when we run.

We are going to be upgrading to Rockwell's FactoryTalk View in January of 2013, so I only have to limp along until then. But still, it's a problem that I shouldn't have to deal with.

Thanks,
Dlogger

 

DF,

I have performed the same task as you stated above. Only the type.ct was generated. You are running XP (SP3), and I am running Win NT4.0 (SP6a)

We did not generate each CT individually to see if Flink will run, but we did a number of them, and each CT's that we tried did generate. So I would assume that if you generated all of them, Flink will run.

It is interesting to hear that this is across different Windows platforms.

Thanks,
Dlogger

 

I am having similar issues with FL 7.2. A modification to the alarm definitions followed by an online restart did not update the .CT files and the alarm change did not occur on the running application. I shutdown the application and deleted all of the .CT files and restarted the application. I did not change the system clock. This time, the .CT files were generated and my changes were incorporated into the application. Subsequent changes were incorporated with the online restart without any additional intervention. However, the subsequent changes resulted in even the online restart regenerating all of the .CT files and being flagged that CML needed to be rebuilt.

I hope we can get a patch and explanation soon as this makes me wonder what other date/time related issues there might be.

Tony Gunderman

 

Hi again,

I tried to install a FactoryLink 6.6 system on my laptop to test all what you have lived but unfortunately my CD has something bad and I can't finish installing the software. therefore, I have to follow your cases using the theory and my imagination.

DF and Dlogger:
Can you edit FLrun.bat file and remove or disable the 1st line where you find the "ECHO OFF" command in order to see the steps and messages sent by FL when your app is executed at 1st time after a restoration?

This can give you some idea about what FL is doing or searching in your app just restored.

Tony:
The problems with .ct files which are not regenerated when there is a change in some of FL tasks are old. My first FL app using FL 4.3.1 in 1994 has already this problem and the workaround that I discovered was to delete all .CT manually and run the app again (it's an undocumented trick saved in my X files).

This problem still alive in FL 8.x although has reduced its frecuency

With the time, my theory took shape and I can say based on my experience with FL is that the source of this problem are the .cdb and .mdx associated to each task (configuration tables).

The .ct files are created or rebuilt (online or not) if FL detects an important change in .cdb associated to a task (e.g. a new record/line, a deleted record or a change in file' size).

If you change a tag's alarm description or the alarm condition (ON instead of OFF for example) I can bet that FL won't see this kind of change if you carry out an online restart (and probably if you stop the app completely and start it again). The plan B in these cases is to delete all .ct files manually and start your app.

My suggestion in these cases is copy any line of configuration table and paste it in any place bellow, save the changes and later delete this new record saving again your final modification.

With this, the .cdb file had an important change, its .mdx file will have a new index to be considered by FL and the .ct files associated to that task will be regenerated.

Be careful with M&L programs working as CML and the online restart. Try to change M&L programs and later see the modifications online can cause strange and no secure results in M&L programs when these are running as CML (the C compiler and RTDB have problems).

Years ago I had this kind of problem with CML and the online restart and the USDATA personnel confirmed me this issue and warning.

I hope it can help you a little more.

Feliz día!

Gustavo A. Valero P.

 

Gustavo,

Thanks for the follow-up post. The changes we do to the alarm tables are done with a PAK task which actually deletes all of the records in specified groups and rebuilds them based on information in an external file. This winds up being a significant change that FL sees. We have been doing this successfully for years. The online restart recognizes there is a change and I can see it stop and restart the alarm logger tasks to pick them up. The only difference in 2012 is that the system does not seem to recognize that it needs to update the associated .CT files. Once I deleted all of the .CT file and got them all updated with 2012 dates, it seems to work, but it wants to update all of the .CT files with any change.

The fact that it now wants to update everything is what is causing problems with the CML. Typically, it would not even try to update CML because there have been no changes to the source programs. Luckily, the linker cannot update the executable for CML while CML is running, so it is not really causing an issue.

Tony Gunderman

 

Same problem with Flink v7.5 and v8.02.

 

Hello everyone,

Not directly associated with this thread topic but relevant to Factorylink users is the following:

'With the release of FactoryLink Version 8 SCADA, a decision was announced by Siemens to stop future product enhancements and place the product in maintenance mode.'

'Existing Customer Support & Service (CSS) contracts for versions 6.6, 7.5, and 8.0 will be honored without restrictions until October 2012. Sustaining engineering for operating system revisions, layered product revisions, and defect correction will be provided under the terms of a CSS contract.'

I only mention it here as some of the replies talk about wanting a patch, which given the status of the product is unlikely.

Siemens do claim to have a low cost migration path to Win-CC although other than reading about it i have no further knowledge at this time.

Regards

Graham Burnikell,
Technical Specialist,
Intuitive Engineering Solutions Ltd

 

If anyone wants to report a case and get a fast and final solution about FactoryLink, the new way is clicking on
http://www.siemens.com/automation/support-request

Just write "FactoryLink" in "Product/Order number"
field and later follow the steps.

This request goes to FL support guys in Richardson, TX - USA directly. It really works!

Although the earth and civilization won't end in 2012 based on Maya calendar, the FactoryLink days are tied to a Siemens calendar which ends this year unfortunately.

Saludos a todos!
Gustavo A. Valero P.

 

Saludos Gustavo y todos;

My question is. If monitor 6.6 has the same 2012 problem, how did Siemens manage to create a program that stops in this year? The versions that we are using are about 10 years old, so Siemens should have placed some spy in the Factory Link development team long time ago to create the problem and then wait patiently to buy the company.

And still a second question. If the problem is so similar in a few consecutive versions of the software, this may confirm a very extended theory that new releases of software imply only minor changes, mainly in the views, menus, and so on, but the main code hasn't been reviewed at all for years.

 

On Tue, Jan 17, 2012 at 6:46 AM, The AList <[email protected]> wrote:
>
> My question is. If monitor 6.6 has the same 2012 problem, how did Siemens manage to create a program that stops in this year?

have you not heard that the world i going to end in 2012? Why would you need to have software that works after the world ends?

 

I would like to say thank you Gustavo, for your efforts in trying to solve this and for posting the link to the solutions from Siemens.

 

The SIEMENS HMI CoC is providing updates for the currently supported versions of FactoryLink, versions 6.6.1, 7.5.2, and 8.0.2. These version updates are provided as courtesy and at no charge.

The Schneider Electric provide 2 patches: There are patches fixing the problem for versions Monitor Pro 7.6, Monitor Pro 7.2 SP3.

You can send support request to SIEMENS or Schneider Electric
OR
You can send me email [email protected]
In this time available updates for FactoryLink7.5.2, MonitorPro 7.2.3 and 7.6

Updates overview
Monitor Pro update for version 7.2.3
http://sites.google.com/site/aiutomation/automation-info-blog/monitorproupdateforversion723

Monitor Pro update for version 7.6.0
http://sites.google.com/site/aiutom...torproupdateforversion760-problemwithyear2012

FactoryLink update for version 7.5.2
http://sites.google.com/site/aiutom...rylinkupdateforversion752-problemwithyear2012