RE: OM-List question.

[Schouten, Frits JF]

Excellent explanation Alex.
Thank you.

I've decided, after long consideration and examination of the legacy code, to do away 
with the lists and go for the set_confirm with PSAP format style.
The 'C' code and associated other programs/scripts and whatever, are really legacy 
code written specially with the AP20 in mind.
That included binary tables in stead of Informix purely for speed reasons.
The source code has now been ported and recompiled to a more modern platform (AW51) 
and can do with a bit of a spruce up.
Rather than changing the old code bit by bit I've now decided to go green field.
The old code has served very well for the last 10 years but it's past it's due by date.

Cheers,
Frits Schouten.
BHP-NZSteel

> -Original Message-
> From: Johnson,Alex [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, June 16, 2000 3:41 PM
> To:   Foxboro DCS Mail List
> Subject:  RE: OM-List question.
> 
> I've fired up my trusty FoxDoc CD and the answer is that the VALUE parameter
> of a REAL data block is an OUTPUT.
> 
> The table describes it as a Data Variable, but the key to knowing that it is
> an output is the fact that it is tied to RO1. RO1 is the range array for the
> "first" block output. 
> 
> Name   DescriptionType Accessibility Default Units/Range
> VALUE  variable value real con/set   0.0 RO1
> 
> So, the answer is that you cannot "write" to these blocks. You can only set
> them.
> 
> However, if you use an optimized set and you don't have to update them very
> often, I'd say that you can use them without worrying too much. 
> 
> You have a choice of setval calls. The setval and set_confirm calls allow
> you to add the compound name to the IMPORT table. Other calls allow you to
> get the PSAP address and use it.
> 
> The biggest concern with the IMPORT flag is that you might fill the IMPORT
> table. There is one entry in it for each new compound name or SV name. Use
> show_params to check how full it is. See Chapter 9 of B0193ND - System
> Administration Guide for 50 Series Systems (Solaris 2.x) covers the
> reconfiguration that you might require.
> 
> There are no other external issues with the ones that require you to acquire
> and retain the station address.
> 
> The 'set' calls in general have to be used cautiously to ensure that you do
> not saturate the target station's input buffers.
> 
> Hope this helps.
> 
> 
> Regards,
> 
> Alex Johnson
> The Foxboro Company
> 10707 Haddington
> Houston, TX 77043
> 713.722.2859 (v)
> 713.722.2700 (sb)
> 713.932.0222 (f)
> [EMAIL PROTECTED]  
> 
> 
>   -Original Message-
>   From:   Schouten, Frits JF [SMTP:[EMAIL PROTECTED]]
>   Sent:   Thursday, June 15, 2000 6:05 PM
>   To: 'Foxboro DCS Mail List'
>   Subject:RE: OM-List question.
> 
>   Thank you for your reply Alex,
> 
>   but I still don't get it.
>   I'm reading in the REAL Variable Block description (FOXDOC) that
> VALUE is con/set for accessibility.
>   One thing I noticed was that when I do an omget of C:B.TYPE on a
> real data block I'm getting (i)151 returned while the block description
> tells me, I should get (i)153?
>   It's a pity that I have to use (M)AIN blocks for all occasions where
> (write)lists are involved. I suppose I'll have to get rid of the lists
> then.
> 
>   Cheers,
>   Frits.
> 
>   > -Original Message-
>   > From: Johnson,Alex [SMTP:[EMAIL PROTECTED]]
>   > Sent: Friday, June 16, 2000 4:11 AM
>   > To:   Foxboro DCS Mail List
>   > Subject:  RE: OM-List question.
>   > 
>   > I just have a moment, but...
>   > 
>   > Get a copy of the document that describes the parameters of the
> blocks.
>   > 
>   > Only those parameters in the INPUT list which are marked as
> connectable can
>   > be connected to with a Write list.
>   > 
>   > All OUTPUT parameters are not connectable for write. The block
> "owns" them
>   > and you may not write to the parameter.
>   > 
>   > 
>   > The table is confusing if you don't know this, but it basically> 
> works as
>   > follows:
>   > 
>   > 1)All parameters can be "gotten" (one-shot get: getval family
> of
>   > calls)
>   > 2)Parameters marked settable can be set (one-shot set: setval
> family
>   > of calls) under the proper circumstances (inputs if nothing is
> connected to
>   > it; some outputs - if the block mode is appropriate, e.g. .OUT and
> MA set to
>   > Manual)
>   > 3)All parameters marked as connectable have a "value record"
> and can
>   > be connected for Read (read lists)
>   > 4)INPUT parameters marked as connectable can be connected for
> write
>   > (write lists) under the proper circumstances (no one else is
> connected)
>   > 5)OUTPUT parameters marked as connectable can NEVER be
> connected for
>   > write. 
>   > 
>   > 
>   > I hope th

RE: Failed FBM

[Craig Rookes]

No  Standard FBM 9 

>>> [EMAIL PROTECTED] 06/17/00 03:11AM >>>
Is the new FBM configured to have an extender card? This could cause
problems.

-Jason

-Original Message-
From: Craig Rookes [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, June 15, 2000 5:36 PM
To: [EMAIL PROTECTED] 
Subject: Failed FBM


Hi 
I had a bad fault occur on one of our plant cp,s and wonder if anyone has
seen the same

We have a fault tolerant cp 30 with 10 different fbm,s connected to it
running software ver 6.1
I added a new fbm via ECB, install etc
I then added the new fbm to the first position on a y adapter which had a
card already in the second slot which was healthy
The new card didn't do anything (no red green ) but the card next to it
crashed.(red green)
buy taking out the healthy card, and trying in a new slot or new hardware or
delete / undeleting the ECB had no effect on getting it back. System
management showed the cards status as blue or red for the existing fbm when
tried to put online. Downloading seems to lock up the system (download is
enabled )
Currently we have no new fbm and one old fbm that wont work in any slot ??
All hardware is ok
The same ver of software is loaded on a hotspare and the fbm,s can be added
no worries.
The major concern is that adding a new FBM to an existing system can crash a
active FBM??
Any thoughts


---
This list is neither sponsored nor endorsed by the Foxboro Company. All 
postings from this list are the work of list subscribers and no warranty 
is made or implied as to the accuracy of any information disseminated 
through this medium. By subscribing to this list you agree to hold the 
list sponsor(s) blameless for any and all mishaps which might occur due to 
your application of information received from this mailing list.

To be removed from this list, send mail to 
[EMAIL PROTECTED] 
with "unsubscribe foxboro" in the Subject. Or, send any mail to
[EMAIL PROTECTED]