Re: [foxboro] FoxAPI questions
- From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 7 Jun 2002 10:19:42 -0400
Re: an_add_objects
The call to an_add_objects uses arrays:
So,
nument = 1
name = "JASON1:CALCA01.RI01"
acctyp = 2
rdelta = 2.0
rsr = 2
wdelta = 0
should be something like
char name[32];
int acctyp[1];
float rdelta[1];
float rsr[1];
float wdelta[1];
nument = 1
strncpy(name, "JASON1:CALCA01.RI01", 32);
acctyp[0] = 2
rdelta[0] = 2.0
rsr[0] = 2
wdelta[0] = 0
Re: Is there a significant performance increase in using the OM over the
FoxAPI?
No. Though there is the rsr delay in FoxAPI.
Re: My end goal is to review both FoxAPI and the OM API, and justify (to my
client) using FoxAPI over OM directly.
Don't use the OM API. The company's position is that the OM API is
deprecated and Fox/AIM API should be used instead.
As mentioned before, we do not even ship the OM header files on NT.
Regards,
Alex Johnson
Invensys
10707 Haddington
Houston, TX 77063
713.722.2859 (office)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx <mailto:ajohnson@xxxxxxxxxxx>
Come to the Invensys Showcase: http://www.invensysshowcase.com/
<http://www.invensysshowcase.com/>
-----Original Message-----
From: Jason Ewasiuk [SMTP:jason.ewasiuk@xxxxxxxxxxxx]
Sent: Thursday, June 06, 2002 8:29 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FoxAPI questions
Thanks for your response, Alex. I've seen some of your other
responses to
other threads, and clients have even emailed me quoting some of your
responses on various issues.
>> Re: I have not been able to add objects with the rdwrit setting
using the
>> an_add_objects() function. If any object in the arrays sent to
that
>> function have the rdwrit(2) setting, the function fails. Anyone
know why
>> this occurs?
> There are rules about this kind of behavior: :-)
> * If the C:B.P is secured, you cannot add it for read/write.
> * If an C:B.P is connected to another C:B.P, it is secured and
you
> cannot add it for read/write
> * If the C:B.P is an output (all outputs are secured), you
cannot add
> it for read/write.
>
> I/A Series block parameters have four options:
>
> 1) Getable (one shot get)
> 2) Setable (one shot set)
> 3) Connectable for read (change driven read)
> 4) Connectable for write (change driven write)
>
> Outputs are never connectable for write. Inputs may be connectable
or not.
> Other attributes may or may not be connectable. You have to
reference the
> documentation for the block of interest to find out.
>
> Beyond these rules, you will have to check the error returns and
see what
> the manual says. You have read the manual have you not?
Yep, I have the Foxboro EDocs, plus older paper copies of the
FoxAPI, though
the EDocs is much better. =)
I understand the connectable/settable properties of the blocks, so
I'm not
making a mistake there. I'm attempting to use a CALCA block that I
created
in
my testing compound, and connect to it via an_add_objects() with the
rdwrit(2)
setting in the acctyp parameter array. For example, I'm attempting
to
connect
to the following:
JASON1:CALCA01.RI01
JASON1:CALCA01.RI02
JASON1:CALCA01.BI01
I've successfully connected these C:B.Ps using scopen() with the
rdwrit
flag,
but not an_add_objects(). Note that I've done this during different
sittings,
restarting FoxAPI to clear the OM database, to ensure that it wasn't
due to
the
object being locked from my scopen() attempt. I've ensured that the
wdelta
is
>= than the rdelta, as per the docs, as well. The result is that I
get a
retval
of -1 from the an_add_objects() call, a reterr of 76, which I can't
find in
the
FoxAPI error codes appendix, but is listed in the foxapi.h file as
invarg
(invalid argument). For the life of me, I can't see this invalid
argument
in
even a simple call.
Here's my test call:
The parameters: (just saying what they are, not how I set them up)
nument = 1
name = "JASON1:CALCA01.RI01"
acctyp = 2
rdelta = 2.0
rsr = 2
wdelta = 0
ret = an_add_objects(nument, name, acctyp, rdelta, rsr, wdelta,
index,
error,
&reterr);
Looks ok to me, according to the docs. I remember reading on the
mailing
list
archives about other people that were having a similar problem with
opening
objects for writing using an_* functions, though I think it was
dated a long
time ago. I can probably find the messages again if needed.
Finally, there was a note in the EDOCS under the an_add_objects that
seemed
confusing to me:
"The call an_add_objects() adds an object for read-only access and
returns
error_array element nowriteob if the passed acctyp_array element is
read/write, but:
The object is opened for read-only access in the FoxAPI database in
the
server.
The object's FoxAPI set has a zero (0) write scan rate (wsr), or
MaxWriteObjects is exceeded."
I'm not sure if this has anything to do with the error, but I
attempted to
read a configuration with an_read_init() with a MaxWriteObjects of
100, and
that had no impact on the results.
Note for reference, the exact same error comes up when trying the
same
operation using foxtst.
>> Re: would it be possible, or even a good idea to prime the OM
database
with
>> ALL points in the system by pre-adding all objects to it?
> The ALIAS file allows this to happen when Fox/AIM API starts up.
It is a
> commonly used technique and is documented in the manual. You did
read the
> manual, right? :-)
Noted... I reviewed the appendixes again in the FoxAPI portion, and
there
it
was, right in front of me. =\
>> Re: Is there any difference to making an application that reads
data from
>> C:B.P (or the like) via FoxAPI, and one that uses the OM C
library?
> You get the same data, but...
>
> 1. Fox/AIM API will add a delay equal to the Read Scan Rate
> 2. Fox/AIM API will optimize access to minimize the load on the
CP. If
> you have AIM*Historian and your application on the same box, it is
quite
> likely that the increase in network traffic and CP load would be
zero.
Why?
> Because your application and AIM*Historian would be sharing the
same OM
> resources.
> 3. The header files to use the OM API are not shipped on NT.
> 4. We believe that Fox/AIM API is a better end-user API; the OM
API is
> for the pedal to the metal guys who don't mind using resources
that could
be
> shared.
> 5. There is a networking version of Fox/AIM API that can be
used to
> allow your programs to run either on or off platform with a
linkage
change.
> This can be very useful.
Thanks for the info here as well. Is there a significant
performance
increase in using the OM over the FoxAPI? I haven't reviewed the OM
documentation thoroughly, so that will be my next point of
investigation,
where I'm sure I'll have more questions.
My end goal is to review both FoxAPI and the OM API, and justify (to
my
client) using FoxAPI over OM directly. Performance is the biggest
issue
here, so if the margin of increase is slim, that will definitely
impact our
recommendations.
Again, thanks for all the help.
##############################
Jason Ewasiuk C.E.T.
Software Developer
Systems Department
Matrikon
Suite 1800, 10405 Jasper Avenue
Edmonton, Alberta Canada
T5J 3N4
Phone: 780.448.1010 ext. 4522
Fax: 780.448.9191
mail: jason.ewasiuk@xxxxxxxxxxxx
web: www.matrikon.com
##############################
****************************************************************************
*
READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently
insecure.
Internet messages may be corrupted, incomplete, misdirected or may
incorrectly identify the sender. Therefore, nothing in this message
or
attachments may be considered legally binding.
THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR
ENTITY TO
WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED.
If you are not the intended recipient or their authorized agent, you
may not
forward or copy this information and must delete or destroy all
copies of
this message and attachments received. If you have received this
communication
in error, please notify Matrikon Inc. by telephone at (780)
448-1010.
****************************************************************************
*
_______________________________________________________________________
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:
