Operand data type

[Winall 0]

A question & application using CPM1/2A : - Each time a pulse is received, add 1 to DM0 - Compare it with 100 (decimal) The instructions that can be used for this simple task and data type as stated in each place: CPM2A manual & CX-P: No Instruction CPM2A manual CX-P Comments ================================================== 1 ADD BCD UINT_BCD OK 2 ADB Binary (Signed or unsigned) INT ? 3 INC No specification of operand data type UINT_BCD Confusion 4 CMP No specification of operand data type UINT Confusion 5 ZCP No specification of operand data type UINT Confusion For ADB instruction, it'sOK for most cases. But it’s still confusing when adding an unsigned binary value to a signed one and vice versa or how to interpret the result! Besides that, due to incompatible data type, a conversion is needed after incrementing in order to compare it using CMP or ZCP. It's a bit cumbersome to convert btw data types just to perform such a simple logic. Anybody can share ideas ? Thanks.

[PdL 71]

-[ ON ]--------[pulse]---------@ADD            |                   DM0            |                   #1            |                   DM0            |            |-------------------CMP              |                   DM0            |                   #100            |            |            |--[ EQ / GT / LT]---[ output ] Can't it be that simple ? p.s. dont forget to set dm0 to 1. Edited 25 Jun 2005 by PdL

[Winall 0]

Thanks PdL But if the matter is such simple, I wont waste your time here ! Looking at your code wont distract us from our question, so let's have a look at it: Data type required for ADD is UINT_BCD Data type required for CMP is UINT UINT & UINT_BCD are basically different data types and at times U cant guarantee its compatibility. Sometimes it works, sometimes it wont. What I usually do is use BIN to convert UINT_BCD data type for use with CMP instruction. My second part of the question is CPM2A documentation does not dictate clearly the data type for CMP. Only CX-P does so. Any body can share idea ?

[ChrisKozanecki 2]

Why cant you do: -[ ON ]--------[pulse]---------@ADB (binary add)           |                   DM0           |                   #1           |                   DM0           |           |-------------------CMP             |                   DM0           |                   #64  (Hex Equivalent of 100)           |           |           |--[ EQ / GT / LT]---[ output ] As far as I know, CMP doesn't use a data type.

[Sleepy Wombat 27]

Correct.

[ECSI 17]

Even though CMP will work with either data type, it still looks for UINT as the data type when compiling the program. I usually just set my data type for single word data to CHANNEL to avoid those annoying warnings.

[Winall 0]

INC, DEC, ADD work with BCD. ADB with signed integer. CMP with unsigned interger. If anybody interested in binary calculation, you can see that if an instruction that "can" work with signed or unsigned integer, it must has a way to distinguish btw the 2 data types. Otherwise, the result will be very different. Let's say you have 2 words used in ADB. Word1 contains F000, Word2 contains 000F. Word1 has bit 15 = 1, so if this word is interpreted as signed int, it will have a negative value. 000F is positive. Conversely, if Word1 is interpreted as unsigned int, its value will be 61440. My question is -how CPM2A distinguishes its data type used with ADB ? - CPM2A documentation does not state data types of many mathematical & comparison instructions. Only CX-P states so. So where is the reliable source ? To ChrisKozanecki: If CMP doesnt use any data type, how it can do correct comparison? Data type is the fundamental base for any calculation & comparison. Clearly, PLC cant just blindly compare it bit by bit, right?

[IO_Rack 178]

See the first post in this thread.

[Winall 0]

Read that post, but question still remains! That post deals with generic data type like Channel or Word, which is more or less dangerous. It doesnt deal with data type behind the scene of the PLC processing.

[gtsuport 61]

Winall, Not to disagree, but actually that post does answer the question. In the Omron plc all values in memory are stored in HEX ("behind the scene of the PLC processing"). The data types are only there for the users benefit. This has been a huge confusion for many users, and difficult to try to explain for support purposes. Certain instruction will error if invalid values are entered (ie: #A for a timer preset, instead of #10 for "ten"). To answer the question about reliable source for data types, refer to the programming manual. CX-Programmer will allow you to set any data type for a data memory location, assuming you know how you wish to view the data. CX-P will then check when compiling the program for "incompatible" data types in the instruction. But again, this is only for display within CX-P. I hope this helps, and good luck. gtsuport

[Jay Anthony 118]

WinAll: Listen to the Omron experience of those above. In the end, all data is stored in the Omron PLC as hex. Any other data type is a conversion from what you see in CXP. Stick with Channel and Bool until you internalize this fact.

[Winall 0]

To all, I deeply understand that everything in PLC is in binary/hex format. But from that base format, it can be of different value if it's interpreted in a different data type. I dont want to mention how CX-P "display" or "view" that channel, because it's just the surface of the matter. Rather, I want to focus on PLC processing. Why CX-P only gives "warning" to incompatible data type instead of "error" ? Because actual data stored in a channel can only be determined at time of instruction execution, this time it's OK, but next time it's error. But CX-P's warning to this incompatibility should not be treated as scrap, because incompatible data type stored in a channel can lead to different results in mathematical & comparison instructions. Maybe I have to ask OMRON expert.

[Jay Anthony 118]

You are not going to find better Omron experts than the people here who have been trying to give you advice.

[ChrisKozanecki 2]

I come here because some of the people on this forum actually are the Omron experts.

[Sleepy Wombat 27]

Winall old buddy..... I believe that you are use to programming AB PLC's ? With Omron, it is more open and not as regimented, believe me there is a lot more flexibility. But as with all PLC's, AB, Omron, Mitsubishi........to borrow from Clint Eastwood "A man's got to know his PLC's limitations" In the CPM2 ADB and SBB use SIGNED DATA, therefore the largest number you would get +32767 and smallest being -32768...... Ask you self how does a PLC know if the data is signed or not ?????? The most significant bit (bit 15) is turned on..... So getting back to your dilma... d32767 = h7FFF correct THEN d-32768=h8001. AB deals with signed INT's also. Now there in lies the problem...the Omron compare will compare UINT (Unsigned integers that is a number from 0 - 65535) In fact Omron allows us to use such a number quite easily.....whereas AB can't, unless you use a double via using S23 and S24) In fact Omron has a number of functions to utilise double math etc. So we need to get back to your dilema of how to compare signed data (thats if you need to compare signed data...let us know and we can show some code.) I would aggree that this is a bummer and mabey not what you are used to in AB, but then again You can;t online edit with a Micro Logix PLC can you ... It might please you to know that the CJ1 and CS1 PLC;s do provide over 400 instructions and the newer ones enable you to develope your own function blocks...This includes full support for 16/32 bit floating pt math, and signed compares... I only hope that you get the opportunity to programme one of these beacuse IMHO AB doesn;t even get close with it's Compact Logix. So summing up .... regading the compare CX-Programmer will give you a warning because it is basically saying that hey buddy...make sure you know what / how you are comparing this data OR you might get erroneous results. IE i could compare the data #A to &11, where # is Omron Hex value and & is Omron decimal. The compare will work....why #A = &10 deoes it not. Where you would get erroneous results is if Operand one contained a BCD value of #0010 and you compare this with an Operand two that contained a decdimal (INT) value of &11....why because internally the BCD value of #0010 would look like &16...however if both operands contained BCD values of #0010 and #0011 respectively then the compare would work correctly.

[OIDMBTRTECH 0]

I come to this forum because an OMRON GURU, that admins/moderates this site, was kind enough to give me the web address. I have used the OMRON hot line and one of the GURU's there also directed me to this site for an example.

[simon Ong SK 0]

Hi guys: I had been using all type of PLC, from Festo to AB. Omron seems to be getting better & better from the OLD Syswin to the CXP. I always got the headache comparing data. Especially the BCD. In order to get rid of the message below: "WARNING: Symbol Sartorius's data type (UDINT_BCD) is not compatible with the data type (UINT) for this instruction operand at rung 10 ( 0, 0 ). " I always need to convert it back to hex and then performed the comparison instruction. Any body have any suggestion. Or I just continue to used the conversion method or plainly ignored the messages and continue to compare with the "Hex" comparison instruction. Thanks Simon

[Winall 0]

Hi Sleepy Wombat & all others, I know all of you are exprienced with programming OMRON PLC and maybe an expert in some area, but it seems that this matter is too "trivial" to you. Actually I have worked with GE Fanuc & OMRON PLC only. With OMRON, I didnt notice much about data type like most of you here. So your example and mention of AB to me is irrelevant, because I'm quite ignorant of AB. But I know what I'm asking. Sleepy seems to get near to what I'm asking. I'd like to sum up some points: - PLC cant determine if a word is signed, unsigned or BCD. Because PLC dont have any flag to mark data type of a channel (memory is too expensive the old days ?) But each instruction is "designed" to work with certain data type. Like ADD work only with BCD, where a word of 0123hex is interpreted as 123 decimal, not any other way. Therefore, it will raise error if the word doesnt contain a valid BCD contents. Question: CPM2A documentation dont state data type for INC, CMP,... As you know, with the same hex value stored in a word, its "interpreted" decimal value will be different, depending on how PLC determines data type of that word. Lack of specifications of data type for each instruction makes programmers very confused on how to use it properly. -

[IO_Rack 178]

CX Programmer is the best! Edited 30 Jun 2005 by IO_Rack

[gtsuport 61]

Do you have the Omron manual #W353-E1-(?), or are you only using the on-line documentation in CX-Programmer? While the on-line information is helpful as a "refresher", it does NOT fully explain each instruction. The manual does explain the data type associated with each instruction. (see attached) This may help to explain some of the confusion. gtsuport

[Jay Anthony 118]

Winall raises a valid "concern", but not an insurmountable "issue." Data Typing is a form of programmer's reality check when assigning variables for use in a readable and structured program. It has its roots in C, C++ and C# languages which are very precise in how variables are declared before the start of designing of a C program. Data types are imposed on a PLC processor which actually could care less about the data type. If Data Types are declared for variables, the onus is on the programmer (not the PLC) to use only these declared variables with the appropriate instruction. Those of us who have been programming Omron PLCs for more than five years got along fine without data typing in past software packages. CX Programmer is the Omron IEC 61131-3 programming package which seeks to adhere to standards developed by users and manufacturers. Data typing is one of those conventions. If you are comfortable with data typing, then by all means use this feature. If the concept of contiguous hex memory mapping is easier for your programming style, then I would stick with this convention. My advise to beginning programmers is to stay clear of data typing as they hardly need another distraction as they are learning the ropes of PLC programming. When beginning the process of developing a programming style, I would use the Omron universal "data types" of CHANNEL for all words and BOOL for all bits. These "data types" are compatible with any Omron instruction set. I wholeheartedly support and invite continual comments on this subject as it is new to the Omron programming community and is typically misunderstood.

[Winall 0]

Hi Jay, Welcome back to this discussion. But I have to disagree with you about forgetting data type ! I would strongly recommend anybody, experienced or newbie, to know what you are doing with your data. Why? because eventually, what you work with PLC is data, or more precisely, bits and words !! For somebody who always want to overlook or forget data type, I believe soemday they will encounter a problem that they wont think data type is the cause in the first place. Let's say U want to compare DM1 & DM2. DM1 has F123 hex, and DM2 has 0123 hex. What's the result ? DM1 > DM2 or vice versa? Pls give me your answer ! To gtsuport: INC is clearly specified to work with BCD. But other instructions are not, like ADB, CMP,...

[Jay Anthony 118]

Man, I love the discussion. This is what MrPLC.com is all about. But I'm afraid that we are debating styles of programming rather than hard and fast rules.

[Sleepy Wombat 27]

As Jay says the CMP works with channel....therfore his reconing is that it is DM11 of course is Greater Than DM10 is correct. Remember that the Compare CMP will compare channels, or if you like to type cast it UINT (Unsigned integers), therfore the values must be between 0 and 65535 (or in hex #0000 and hex #FFFF) Or alternativelly in BCD #0 to #9999. I can understand the typing problem, in the past mostly the math in the omron plc code would be by BCD not decimal. And there are tricks to get around the problems you seem to be having. CX-Programmer allows you define as types. Previous software such as Syswin would define everything as channel, if you wanted to view otherwise you could do so in the data watch window or memory view. The newer models CJ, CS allow instructions to have type casting, ie S> which is a signed Greater than compare. The older ones do not.

[Winall 0]

Men, I dont want to talk much about BCD data type because it's too common in OMRON PLCs, especially old PLC until CS1 platform focuses more on binary data (U can see a lot of instructions for binary data type introduced into new CS1/CJ1 platform recently). BCD is also documented quite well in documentations. Back to question: Let's say U want to compare DM1 & DM2. DM1 has F123 hex, and DM2 has 0123 hex. What's the result ? DM1 > DM2 or vice versa? It seems that it's very clear that DM1>DM2. Kid's algebra, right? But the answer is not so apparent. To try it, you can write a program to test, or try my program attached herewith (U can set operand data while online). This test shows 2 results: DM1 can be > or < DM2, depending on how PLC thinks about the data type, even though the 2 instructions use identical operand data values Let me know your opinion! Test_Compare.cxp