Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Thu, 25 Aug 2011 08:26:53 -0400

Hello:

"Writes set individual bits of a DINT."
That's exactly it.
That's why it works perfectly and efficiently when you assign bi, bo, mbbi,
mbbo records to bits of a DINT, DINT[], BOOL[].

But when you assign a bo to a plain BOOL, this is what happens:

Writing 'true' will write a 0x01 to the PLC.
The PLC, however, will read that back as 0xFF.
When the BO record will next be instructed to write a 'false' value,
it will write a 0 for the first bit, i.e. it will write 0xFE.
If the record was indeed attached to just a bit in a bigger number
( DINT, DINT[], BOOL[] ), that's correct.
But if the tag is just a plain non-array BOOL, the PLC will consider
0xFE==true and still return 0xFF

-> Once you write a '1' (true) to a BOOL tag, it will stay 'true'==0xFF.
You can never get it back to 0 (false).

-Kay

On 8/24/11 22:26 , "John William Sinclair" <[email protected]> wrote:

> I routinely define records as shown below an never see such behavior. Writes
> set individual bits of a DINT. Why is that fundamentally different?
> 
> record(bi,"$(db):BlvIr1:OpnSR") {
>   field(SCAN,"1 second")
>   field(ZNAM, "0")
>   field(ONAM, "1")
>   field(DTYP, "EtherIP")
> # field(INP, "@hrenbt02Cpu1 BlvIr1_OpnSR")
>   field(INP, "@hrenbt02Cpu1 epics_inputs[3] B 11")
> }
> 
> record(bi,"$(db):BlvIr1:ClsSR") {
>   field(SCAN,"1 second")
>   field(ZNAM, "0")
>   field(ONAM, "1")
>   field(DTYP, "EtherIP")
> # field(INP, "@hrenbt02Cpu1 BlvIr1_ClsSR")
>   field(INP, "@hrenbt02Cpu1 epics_inputs[3] B 12")
> }
> 
> Best,
> John Sinclair
> 
> Kasemir, Kay wrote:
>> Hi:
>> 
>> Martin Smith @ APS has found a quirk in the way the ether_ip driver for
>> ControlLogix PLCs and the PLC handle 'BOOL' tags that might be of interest
>> to those that use the driver.
>> 
>> The short summary is that you cannot use BI or BO records with plain BOOL
>> tags on the PLC.
>> 
>> The binary record support in the ether_ip driver is meant for efficient
>> handling of _bits_. It can read and write bits in a BOOL[], DINT, DINT[]
>> tag. In those cases it reads or writes the whole numbers over the network,
>> then dispatches the individual bits to records.
>> 
>> For example, say record A is attached to BOOL[0] or DINT.0,
>> record B is attached to BOOL[1] or DINT.1 and so on.
>> Meaning the records are attached to the bits of a DINT, DINT[] or BOOL[].
>> That all works fine: The driver reads or writes the whole DINT or DINT array
>> or BOOL array and performs the appropriate bit fiddling to interface the
>> bits to records.
>> 
>> But if you attach a binary record to a plain, scalar BOOL tag on the PLC,
>> the following happens:
>> The driver still wants to read or write individual bits.
>> A BO record with OUT="@plc MyBOOLTag" will read or write 0 and 1 values.
>> The PLC, however, returns 0 for 'false' and 255 for 'true'.
>> 
>> The mismatch between 1 and 255 is the issue at the root of the problem that
>> Martin found in a setup:
>> 
>> A BO record would write a "1". The PLC now actually sets the BOOL tag to
>> 255, and the driver from now on sees 255 as a value.
>> If the driver is instructed to write a "0" for the BO record, it will write
>> 254, i.e. the received value of 255 with the first bit set to 0.
>> The PLC, however, considers 254!=0 also as 'true' and keeps the BOOL tag at
>> 255.
>> 
>> Longer summary:
>> Use binary records (BI, BO, MBBI, MBBO) with BOOL[], DINT or DINT[].
>> Not with individual BOOL tags, which - even if it were supported - would be
>> slower than array transfers anyway.
>> 
>> Thanks,
>> Kay
>> 
>> 
>> 
>>  
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System