Re: [foxboro] FoxAPI questions
- From: Jason Ewasiuk <jason.ewasiuk@xxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 6 Jun 2002 19:28:47 -0600
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
Other related posts:
