Writing to Boolean parameters is not as obvious as one might think. It might
be worth reviewing your code after reading this. I've seen many occasions
were a simple misunderstanding resulted in strange data being written to
Boolean parameters.
Depending on how you write your code and how data is intialized, you can get
very strange results. Hope this helps.
Also, be sure to duplicate your FoxAPI programming problems using
/opt/fox/ais/bin/foxtst (or /opt/fox/ais/bin/aistst for older systems). This
tool will let you try each call indivdually to see if you understand its
operation properly. It can also be scripted using the << redirection
operation of the Bourne shell.
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]
The Value Record for all OM variables is arranged as follows per
/usr/include/fox/om_udat.h (with minor edits for clarity)
union var_val{
char letter;
int word;
unsigned int uword;
unsigned long ulong;
long longint;
float fpoint;
struct str_rec str_val;
};
struct value_rec {
unsigned int status;
union var_val uval;
};
As you can see, the boolean value (the element letter in the union var_val)
is the right most bit of the left most byte of the union.
Therefore, 0x1000 represents true and 0x0000 represents false.
Here's a code excerpt from an OM program that does work.
unsigned int status = BOOLEAN;
unsigned char value;
unsigned int length = sizeof(char);
char name[33];
if ( use_block )
{
value = (almState == INTO_ALARM);
sprintf(name, "%s:%s.IN", cName, bName);
ec = setval(name, VARIABLE, 0, (char *)&value, &status, length);
/*
if (ec)
fprintf(stderr, "name=%s status=%04x ec=%d\n", name, status, ec);
*/
}
Be careful of this code, it generates broadcasts. They can be eliminated by
using the IMPORT flag (set the third argument to 1), but then you need to
monitor the IMPORT Table to ensure that it is not overflowing. show_params
can do that for you.
FoxAPI is not much different. Instead of a Value Record, it has an IAXVAL
structure:
typedef union
{
char iacval;
char iabval;
short iawval;
int iaival;
long ialval;
float iarval;
unsigned char iaucval;
unsigned short iauwval[2];
unsigned int iauival[2];
unsigned long iaulval[2];
char iasval[256+1];
} IAXVAL;
Again, the boolean value (iabval; I/A Series Boolean Value) is the right
most bit of the left most byte of the union.
Here is a very old piece of code that used uwrite successfully on an INT
(it's so old that the 'official' IAXVAL did not exist. I still use mine
'cause I think it is easier to read, but...):
typedef
union
{
char cval;
short int ival;
float fval;
char bval;
long lval;
} IAXVAL;
char name[1][32];
int gw[1], error[1], nument, reterr, status[1], valtyp[1];
IAXVAL value[1];
/* Read the tank mass */
gw[0] = 1;
valtyp[0] = INT;
strcpy(name[0], flagName);
value[0].ival = 1;
nument = 1;
DebugPrint(LEVEL2_DEBUG, "\tWriting the following object:\n");
DebugPrint(LEVEL2_DEBUG, "\t\t%-32.32s type(%d) gw(%d)\n",
name[0], valtyp[0], gw[0]);
errno=0;
reterr=0;
uwrite(gw, &nument, name, valtyp, value, status, error, &reterr);
Be careful with this code. AIS's one-shots did not use the IMPORT table and
generated broadcasts. FoxAPI does use the IMPORT table so if you use its
one-shot capability, be sure to check the IMPORT table using show_params.
Since I never use FoxAPI one-shot reads and write (uread/uwrite) "on the
box", I can't give you a working code fragment for a Boolean. Sorry about
that.
> -----Original Message-----
> From: Sascha Wildner [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, March 21, 2000 9:37 AM
> To: Foxboro DCS Mail List
> Subject: Re: FoxAPI programming problems on AW70
>
> Cyrus,
>
> thanks for your answer. That's interesting. What exactly didn't work when
> you made the transition to 6.1?
> Did writing to the SWCH block parameters always fail or just sometimes?
> What function call did you use for writing?
>
> It's really weird. I have noticed myself that writing doesn't always work.
> I have a program which writes the IN_1-5 parameters of BLNALM blocks in such
> a way that always one of those inputs is set and the others are 0. If I
> test it here on my local AW70 in the internal station, it works fine. If I
> go to the customer, it shows very strange behavior. Sometimes more than one
> input is 1 as if the setting to 0 didn't work correctly.
>
> But the shared variable hint might be a solution. Thanks so far.
>
> Regards,
> Sascha Wildner
-----------------------------------------------------------------------
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]
