Operand data type

[gtsuport 61]

OK, not to get picky here, but the scope of this discussion has changed a bit. Originally the question was focused around the CPM1(A)/CPM2A (C-Series instruction set). Your code example is for a CS1/CJ1 (completely different instruction set). C-series instructions were included in the CS1/CJ1 to offer backward compatibilty and an upgrade path. I understand your example, but the instruction name defines the data type. The CPS (Signed Binary Compare) will give a different result than a CMP (Compare) instruction for the values you are using. (Note: CPS is not a C-series instruction) Jay can verify this, but I believe that C-series instructions will all use Hex as the data type (unless otherwise specified). Only CS1/CJ1 instructions will utilize other data types. Additionally, the data type will be defined by the title of the instruction. It would be up to the programmer to use the proper instruction type to get the desired results. I do understand your point Winall. I think Jay may have summed it up gtsuport

[IO_Rack 178]

The PLC does not think, it only does what you tell it to do. In your first rung, you told it to compare the unsigned integer value of F123 to 0123. D2000 contains F123 Hex = 61,731 Unsigned Decimal D2001 contains 0123 Hex = 291 Unsigned Decimal Therfore D2000 is GREATER THAN D2001. In the second rung, you told it to compare the signed integer value of the same data. D2002 contains F123 Hex = -3805 Signed Decimal D2003 contains 0123 Hex = 291 Signed Decimal Therfore D2002 is LESS THAN D2003. The same raw data in the PLC was processed differently because it was interpreted differently as per the instruction used. How it is stored is always the same. (see Jay's Omron tip #49)

[Sleepy Wombat 27]

[Guest anonymous]

...and so say all of us...

[Winall 0]

Hi To gtsuport: If U say C-series & CS series has completely different instruction set, you're wrong! OMRON has made instruction set quite backward compatible, so when U write a code for C-series, U can convert it to CS-series with minimal changes (CX-P does this for you, but U can notice that little change is made). All instructions of C-series are inherited in CS series as well. But more importantly, the code you write for C-series will work as expected for CS series as well (of course what U have to change is some memory addresses). If it doesnt work that way, OMRON wont be among the top PLC vendors. To IO_Rack: You're right, this is what I'm implying. My wording may be not very correct, because I'm in a hurry, but as always, pls get others' ideas behind their words ! The reason I use 2 different instructions to demonstrate the data type is because if I use the same instruction, then same results will occur. Furthermore, I use CMP & CPS because CPM* has only CMP, not CPS. As I have stated, data type is how PLC interpret the hexa values. To tell PLC to interpret a hexa value in 2 different ways, I have to use 2 different instructions. CMP sees F123 as a positive value, while CPS sees F123 as negative value. My original question is not to elaborate this much, just to ask why CPM2A documentation lacks specifications of data type. But as this goes on, I have to disagree with somebody's ideas about data type, especially with hexa comparison. I believe comparison of 2 channels without regard to its data type is MEANINGLESS! Hexa is nothing but a short form of bit string representation. F123 & 0123 are all hexa values, but to compare it properly, PLC must be instructed to interpret its value properly. ANybody can tell what the statement "hex comparison" means ?

[BITS N BYTES 66]

Got a very useful tip from the Omron support group that really helped me with the Data type issue and data type Warnings that occur during a compile. CX-Programmer permits multiple tag names for the same address. It also allows the data type to be different for each of these tag names [Channel, Float BDC etc.] even though it is for the same address. Use the correct TAG/DATA TYPE to match the DATA TYPE for the specific instruction being. This eliminates the compile warnings and assures the instruction works as expected. Hope this helps.

[ChrisKozanecki 2]

Winall: I think you are falsely trying to apply CJ/CS understanding to a C series. It seems that you are ignoring what we are trying to tell you and only seeking to prove your belief as truth. Being a right-fighter is a bad way to enter a discussion because it will blind you to the advice many experts have tried to give you. The C series will only compare an unsigned value with its CMP function. And its looking at the hexadecimal value. This means that if you enter &10 compared to &16 the function will compare #A to #F. You could also compare &15 to #E and it would say they are equal. If you need to do complex math with your PLC, then you need to invest in a CJ or CS. The reason why the CPM2A (your original reason for starting this thread) doesn't state a data type for the CMP function is because when the CMP2A was first made the only data types that were ever compared were Channels and Bits. Times have changed, but these PLC's still have their place due to their small size and price compared to a rack mount. Unfortunately since CX-Programmer has to support the CJ/CS and these older PLC's there is a lot of functionality in CXP which can cause confusion while programming older PLC's. I think you should re-read this thread with an open mind because there is a lot of good information in here.

[Sleepy Wombat 27]

ChrisKozanecki

[Winall 0]

I'm feeling that this thread becomes off track (I warned sometimes) when you made such a personal statements about others! I'm not the type of person to go with the crowd, even I'm single handed. I'm here to learn and get my questions answered or advised, not to make such stupid confusing implications. So my mind is always open to the others' ideas, if not, I wont waste time here. To make it easier to follow, I number the points still in debate: 1- "C-series & CS series has completely different instruction set" is totally wrong statement. U can write a program in C-series, and CX-P can convert it to CS/CJ series with little change. It means the instruction set is more common than different. 2- Using a CS series to prove a point is TOTALLY VALID! Because data type is universal, it's not OMRON invention, if U prove it with a PLC, it's applicable to other types as well (if that type supports it). If C series lacks smt, I can use other series to test/ experiment to prove it. The lack of a feature doesnt mean that the feature cannot be proved. And the question about data type is not confined to C-series. 3- Pls read my statements carefully before making another statement about others! I havent stated in any sentence that CPM2A documentation is wrong. I just say it's confusing only. You can see CS/CJ series documentation has been vastly improved, so such confusion is not a matter with these series. 4-Haha, hex comparison is meaningless, if not attached to a data type. Your statement "&10 compared to &16 the function will compare #A to #F" means the data type is UINT, not the other way! This is the only thing I can agree with you. But the statement "The reason why the CPM2A (your original reason for starting this thread) doesn't state a data type for the CMP function is because when the CMP2A was first made the only data types that were ever compared were Channels and Bits." makes me very disappointed, because you are not understanding fully what you are saying. I think admin should close this thread here, because nobody seems to be getting better. Bullsh*t statements are presented here and there and are applauded.

[ChrisKozanecki 2]

I am disapointed that you feel the way you do Winall. Since you feel that my statements are BS, I suppose my efforts are wasted but I will try to be more clear in this post. Please help me see what it is that I am not understanding fully as I don't know what you think I am missing.

[Winall 0]

I disagree with all the points you've said above. It's really a waste of time, when no one wants to solve the problem, instead just want to pick others' slip of tounge. So I wont debate this matter here anymore because what everybody receives is nothing from this thread.