Today is...
Sunday, August 2, 2015
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
Wiring and programming your servos and I/O just got a lot easier...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
CS 3000 yokogawa error 11186
Can not download to fcs from cs3000 yokogawa.
1 out of 1 members thought this post was helpful...

hi anyone,

i have problem in cs3000 yokogawa. i can not any download to fcs...when i want download to fcs, the system shows "ERR:ERROR= 11186:The Generation time of master data base and FCS image is different.

how to fix this problem
THANKS

mrr1345@gmail.com
MRR

By Peter Blyth on 18 June, 2011 - 4:55 am

You have a nasty problem.

Basically the CS3000 project file does not match the file loaded to the FCS.

i.e.; typically EWS crashed and master project was lost and live backup was not configured or maintained or rebuild used the wrong project etc.

There is no documented Yokogawa recovery procedure for this problem, so I will explain my understanding of the problem. There are two things which are checked when you do a load - timestamp & tag list.

A timestamp mismatch will prevent tuning parameter saves, and will cause online loads to be rejected (as you have discovered). If you find your way around the timestamp mismatch - you may still have tag list mismatches (at least with Centum CS - I think CS3000 is the same).

Regardless - even if you can get around the tag list mismatch - you need to be extremely careful as "forcing" a load with a mis-match means you run the risk of orphan code running inside the FCS. Not pretty.

The simplest & best recovery is to offline load the FCS.

Regards, PB

There is no other way to resolve this problem online, you have project mismatch on the project directory and the actual FCS, which means the project which was running in the FCS has been deleted, lost or altered from the project directory.

As PB said, The only solution is Offline Download to FCS: Find the best time when Plant is off and do it.

Thanks,
Will P.
Technical Service Advisor

By peter blyth on 30 July, 2011 - 9:03 am

Cheers Will,

There are other solutions - but they are not for the faint hearted.
See www.automated.com.au/downloads/FCS_Time_Stamp.doc - this also works for CS3000 & Centum VP.

Minor differences due to Unix/Windows MSB order & tools etc.

Cheers, PB

By Mathew Varughese on 25 February, 2014 - 1:46 pm

For me out of 7 fcs 3 got the same error code: 11186 and other three are ok. What are the root cause for these kinds of problems.

Mail to: mathewamv4u@gmail.com

By aburaihan on 14 March, 2014 - 8:15 am

Well all the replies are some what right. But one more problem could be due to the trailing time of HIS (EWS) and the clock of FCS CPU.

Please check whether system time across all the HIS and EWS are the same or it's been getting trailed one you restart any one of the machine? If this is the case then the CMOS battery of individual HISs/EWS will be low and creates "generation time different in MASTER Engg. data of EWS and individual FCSs target data(CPU RAM)" while performing a Engg. builder generation prior to down load(ON-LINE).

Even though there is a special tool under Yokogawa Service tools (Used by Trained Yokogawa Service Personnel) to over come similar situations but it will not work if there is Redundant or non redundant MODBUS Communication with Data write to sub systems under these FCSs.

Finally If this is the case the only solution is to perform an "OFF-LINE LOAD" from the builder system view of EWS for individual FCSs which will surely call for s/d of the process units under these FCSs.

Any solution for Windows Server 2003 OS with the same problem without offline download?

Hi Kashif -

Email me on pblyth@minara.com.au and I can send you my procedure to work around error 11186 - I use it to jog my memory when updating timestamps - applies to Centum CS, CS3000 & VP.

As an observation error 11186 used to be a very common problem back in the Centum CS days with HP EWS builders - but I very rarely have this problem anymore. FYI - We run PICS EWS builders and Centum VP r5 to a total of about 40 FCS/FFCS.

How to avoid 11186 -
* Use only SSD disks for FreeBSD and Windows - RAID if possible
* Centum VP / CS3000 - the project needs to live on the master HISENG - not on a file server (our VP project is about 100GB & 400k files) - many tasks simply "crash" on the other HISENG (maybe not with the current release r5.04 though)
* Centum VP - use the "Set Backup" to maintain a separate incremental backup (for us this goes to another SSD in the main HISENG)
* Maintain plenty of disk space - especially FreeBSD, run a cron task to dump mail & log files daily
* Reboot EWS / builder often ... weekly at least
* PICS builder - do not use PICS function on the builder machines - if we install and start the PICS function, the EWS will randomly core dump during FCS compiles and corrupt the binaries.
* PICS builder - we run incremental backups every 15minutes by cron to capture changed files
* Network - the network between the HISENG / Builder and the project needs to be robust
* And lastly - keep full daily backups going for several weeks at least ... we automate this of course, kix32 and 7zip are my favourites!

Regards, PB