Really Really Strange. CLX and PLC-5

[(8{)} ( .)]

Hi All,

This one is really weird. It may have been discussed but It's
something new to me. Really knocked me for a loop.

Anyway...

I was programming a data transfer between a PLC-5 and CLX controllers. The PLC-5 reads data fromt the CLX over DH+.
I set up an INT array in the CLX and assigned it to appear
as N32 on DH+. Some of the data I had to transfer was Floating point data so I COPied the data into the INT array. So far so good.

Now comes the weird part.

When I programmed the MSG in the PLC-5 all of the data appeared
to transfer correctly but when I copied the Floating point data
back from the integer file in the PLC-5 to a floating point
file, behold, gibberish.

After scratching my head and stroking my beard I wrote a loop
that swaps the low and high 16 bit parts (integer data) of the floating point data. I copied the results to floating point and,
behold, good healthy data.

I don't know if this is documented but evidently the COP instructions work a little differently in the two controllers. The PLC-5 copies low-word/high-word and the CLX high-word/low-word when copying floating point data (maybe it's the oposite, who knows).

Regardless, weird.

Any comments?

(8{)} .)
(Yosi)

 

[TConnolly]

Yes, its documented. The problem is releated to the endianess of the PLC processors. The PLC/5 uses Motorola processors and is a big endian processor. The CLX uses Intel processors so it is a littel endian processor. The CLX processor has the SWPB instruction to aid in switching the data.

Refer to tech note 34814 and 46084 for more information.

 

[(8{)} ( .)]

Now I feel a little less insane.

Thanks for the answer.

(8{)} .)
(Yosi)

 

[daba]

At first I thought you were trying to use COP to translate Float data into Integer data, and the alarm bells started ringing, because as you know, you can't do it that way, COP does no data conversion.

But then I realised you were attempting to rebuild the float data in the PLC-5, and have come up against the documented endian-ness problem.

But then I thought - why not set up another message to read the float data directly ?

A much neater solution IMHO.