Re: [foxboro] Automation of upload/checkpoint/save_all at sites with IACC, ICC, or IEE!!

  • From: "Kevin Fitzgerrell" <fitzgerrell@xxxxxxxxx>
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Fri, 31 Oct 2008 06:23:59 +0900

Tom,

There are still a couple of options for keeping a central
configuration machine in the MESH age, but it depends on your CP
hosts.  We use (for now at least) P82 Solaris 10 workstations for our
hosts and ICC seems to work just like it always did between them.  In
our testbeds we use P91 Windows 2003 servers, and while you can't
remote ICC between them, you can pull a remote RDP session for ICC.

Regards,

Kevin

On 10/31/08, tjvandew@xxxxxxxxx <tjvandew@xxxxxxxxx> wrote:
> Terry,
>     Using the checkpoint file as the master for all CP information IS
>  the best idea.  There are utilities such as dbvu that already extract
>  data from the checkpoint file and they are lightening fast.  Alex talked
>  about Foxboro moving in that direction back before the Infusion
>  development and it sounded like a good idea then.  When using IEE as the
>  configuration tool is there still a checkpoint file as we know it
>  today?  I would think it would still have to exist.  If so, the
>  checkpoint file should be a great and absolute source of all information
>  in the CP regardless of whether you are using IEE, IACC, or ICC.
>  De-compiling the checkpoint file might be a bit complicated but it seems
>  like it would be money well spent by Foxboro and would provide users
>  with more credible information in a much faster and more reliable way.
>  The relationship between the checkpoint and workfile has been a source
>  of confusion from day one and the workfile has become corrupted on too
>  many occasions.  Since the checkpoint creates a raw image dump of what
>  is running in the CP at the time the checkpoint is initiated it contains
>  all of the data needed and it is now quick enough to be invoked at the
>  beginning of a configuration session to insure the user is seeing what
>  is really running in the CP.
>     Alex or Russ, what were the factors that facilitated the quantum
>  reduction in the time it takes to checkpoint a 270 series CP?  Was it
>  just the 100mb/s bandwidth and switched Ethernet that the MESH provides
>  between the 270 CP's and the boot host where the checkpoint file is
>  stored?  The increased processor power of the CP and/or boot host?  Or a
>  change in the checkpoint communication data stream?  At any rate, the
>  270's checkpoint in seconds rather than minutes that the  nodebus based
>  CP's take.
>     The silence on my last email asking questions about automating
>  uploads in IACC was deafening.  I think that silence was a positive
>  confirmation that there is no mechanism in place to allow it and it
>  points out a glaring deficiency in IACC.
>     This email proposes a possible solution to a problem that has
>  plagued IA users from the beginning of IA time but it would be no
>  surprise to me if it falls on deaf ears also.
>     Before retiring from Dow Corning and working on the Tesoro Hawaii
>  project I had no experience with IACC.  Although I am still not an
>  expert on IACC I see little advantage to using IACC as a day-to-day
>  configuration tool.  All of the people I have seen use it are still
>  using ICC driver tasks functions, (iccprt), to provide the bulk of data
>  they need to do their jobs.  There are a lot better tools that users
>  have developed with individually developed applications than what IACC
>  provides.  I can understand that it provides people developing the
>  software applications from a remote location a better tool to create
>  loop templates and standards but IACC actually gets in the way down at
>  the day-to-day use level IMHO.  But IACC is the only mechanism on a
>  multi-boot-host MESH network that allows for a centrally located
>  configuration workstation.  If you use ICC on the MESH you have to be in
>  a direct session with the CP boot host.  That was a large step backward
>  from the UNIX based use of ICC that allowed configuration of any CP from
>  any workstation on the nodebus/carrierband network.
>
>  Cheers,
>  Tom VandeWater
>  Control Conversions Inc.
>  Kapolei, HI
>
>
>  _______________________________________________________________________
>  This mailing list is neither sponsored nor endorsed by Invensys Process
>  Systems (formerly The Foxboro Company). Use the info you obtain here at
>  your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>
>  foxboro mailing list:             //www.freelists.org/list/foxboro
>  to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
>  to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>
>
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts:

  1. Home
  2. foxboro
  3. Archive
  4. 10-2008