Adding to DW in S7

Hi all,

I have a data block with WORD data type.
I need to add or increment the DW of such DW.
I used the ADD_I function , but all the time it's fail.

DB12.DW88 = DB12.DW88 + x

How can I do it.
Regards...

Some possibilities:

Switch to STL and enter:

or redeclare DB12.DBW88 to be an INT (recommended)
or disable type checking in the block editor.

You can also use ADD_DI. Just make sure you format your x as a double integer also: L#x.

Regards,

Ok here comes the dumb question

Data type "word" can only accept binary and hexadecimal values and does not work
on integer values.
Then how does this problem gets solved by switching to STL?

In STL mode, you load/transfer variables to/from the CPU accumulators which are 32 bits wide. Arithmetic instructions operate using the accumulators. So, if you wanted to, you could load a byte (which fills the rest of the accumulator with zeros) then a real and add them together (and of course get a nonsense result).

L D[AR2 said:

So, if you wanted to, you could load a byte (which fills the rest of the accumulator with zeros) then a real and add them together (and of course get a nonsense result).

Click to expand...

Ok very high price to pay for surpassing that RED alarm.

One more thing

If we use ADD_I function in LAD and then convert it back to STL then internally this also is doing same thing(using accumulator),that is
L MW 300
L 200
+I
T MW 302
NOP 0

But still it shows the RED alarm !!
Some C++ problem??

But still it shows the RED alarm !!
Some C++ problem??

What does ? post a screen shot.

Turn off type checking

LD[AR2,P#0.0] What I meant is, ADD_I block also uses accumulator for doing addition, then how it shows error while its equivalent in STL does not.

As noted in the screeny above, type checking is only available in LAD/FBD. In STL there aren't any checks, so it won't produce RED flags....

Jeebs said:

In STL there aren't any checks, so it won't produce RED flags....

Click to expand...

Ok thanks got it.
See I warned it was dumb question.

manmeetvirdi said:

Ok here comes the dumb question

Data type "word" can only accept binary and hexadecimal values and does not work
on integer values.
Then how does this problem gets solved by switching to STL?

Click to expand...

This is jut for the next guy reading along.

"Word" can be declared an INT by right click "edit symbols"

enter name in "symbol" and INT in "data type".

I found the same issue to be less than reassuring.

Why is there an issue here?
IEC61131 is utterly clear about the scope and purpose of the datatypes WORD and INTEGER. They are not the same. The only thing they have in common is that they occupy the same amount of memory in a CPU: 16 bits.

So, do we accept that strongly-typed computer languages are a good thing or not? If we do, leave the type-checking switched on and obey the rules. If not, switch it off and now you have to do all the house-keeping and data management yourself. Simple choice, clear consequences, your call.

Ken

There are several questions here and allot of "stuff" none of it matters.

Ken M said:

Why is there an issue here?
IEC61131 is utterly clear about the scope and purpose of the datatypes WORD and INTEGER. They are not the same. The only thing they have in common is that they occupy the same amount of memory in a CPU: 16 bits.

So, do we accept that strongly-typed computer languages are a good thing or not? If we do, leave the type-checking switched on and obey the rules. If not, switch it off and now you have to do all the house-keeping and data management yourself. Simple choice, clear consequences, your call.

Ken

Click to expand...

In this case Integer is a subset of word. I realise that word is a size of data. I think the software should accept 10 in that word and be able to apply it to an Integer without me having to tell it 10 is an INT. It should be obvious it is not a real, as it is in a word not a Dword. (S7 has no quams about telling you 10 is NOT a real number so what does S7 think 10 is? could be a string I guess.)

So when I define MW45 as "Oil Level" and S7 automaticaly puts the type as "WORD" I question the need to go another step and change the "WORD" type to "INTEGER".

This is just a gotcha in my book. If it is some how critical, as it seems to be, then leave "type" blank and ask for an input and I will evaluate the options and I would then choose INT from the list.

When S7 picks "WORD" as type , it makes it seem non critical or as if "WORD" is the correct choice in this case. ........To the new user.


Of course now that I know this, it is nolonger an issue. None of it is an issue AFTER you find out.

I am not arguing whether it SHOULD be one way or the other, but there should be an indication of what is happening.

Try to define an element in the symbol editor without putting a name in the symbol cell. It wont let you. I wanted to specify a range of memory locations as INTEGER without naming them all, just make them INT and leave the name blank the way it is before............NOPE. And that is completely OK , but why not do the type the same way?

It all boils down to this..........If type is so critical to Siemens and S7 then why does S7 make it soooooooooooooooooo easy to get wrong?

"So, do we accept that strongly-typed computer languages are a good thing or not? "

AHHHHHHHHH

computer languages............yes, but PLC languages is the issue at hand.


"If we do, leave the type-checking switched on and obey the rules. If not, switch it off and now you have to do all the house-keeping and data management yourself. Simple choice, clear consequences, your call."

Turning type checking off does not remove the problem of missmatched types it just turns off the alarms. I do not think this is good advice to anyone. I want MORE type CHECKING and less NEED for type checking.

And what "house keeping" are you refering to? DAta types match or not, S7 tells you or not.

The choice IS simple, walk through a mine field WITH a map that is right MOST of the time, or just throw away the map and run through. Simple yes. Solution, no.

Why can't I compare an Integer with a Real number?

Real numbers contain integers.

(Imagine these are in LAD)

10 < 12.62578

there I did it.

10 > 2.67392

What's the big deal? Turn off type checking and this works right? I am asking for clarification. What is so bad about doing this?

I am serious, with all the fuss I feel like I have missed something fundamental.

Ok now 10+22.89...............What about this one?

The ONLY place I see an issue with data type is when comparing Binary HEX and DEC or when doing MUL or DIV with INT.

Even then I would DO the math and round off to the nearest INT.

6/2=3 int

6/5=1 int

125/10=13 int (if 5 rounds up.) No need to convert int to dint, dint to real and then compare and then trunc or round back to an int.

If it is a show stopper ASK the user and accept NO incorrect entry. EVERY variable should be defined before use if it is critical.

The issue is S7 seems to allow more to happen at the point of data entry than it wil allow at the point of data use.


So much of the discussion seems to get personal or defensive, I don't get that bit.

Several times I see S7 guys say "You need to get past the I can't believe S7 wont do this."

I would say to S7 guys, "You should stop thinking everything in S7 makes sense just because you are past the entry point."

Some of us have used several other packages and there are always differences. Noone would argue that. One expects a deviation from manufacturer to manufacturer. Based on past experience that deviation is far greater with S7 than any other.

Not sayin that's a bad thing, maybe it IS way better, maybe everyone else is that far behind.

PLCs were made to replace relays, not PCs.

That is why they are simple, or why they were simple.

Now the difference between PC and PLC is growing so small it is easy to make the arguement to just switch to C or some other PC based language.

It is meant to be easily understood and intuitive to the casual user during moments of high anxiety. When production stops no one cares how clever the PLC programmer was or why this number wont work here but works there, it just needs to work NOW. Call the programmer or someone who can sort this "clever" design costs production.

Of course it also generates more need for the programer until everyone figures out he's part of the problem.

I am mixing a new angle in here, but it all relates. Complex and tricky are rarely a good thing in industrial controls and things are getting progressively complex and tricky.

I have never met the maintenance man in any plant that could use S7.

dahnuguy said:

In this case Integer is a subset of word. I realise that word is a size of data. I think the software should accept 10 in that word and be able to apply it to an Integer without me having to tell it 10 is an INT.

Click to expand...

How could it possibly tell that? How would it know you meant to type an INT 10, and not a hex 10 (INT 16)?

Try to define an element in the symbol editor without putting a name in the symbol cell. It wont let you. I wanted to specify a range of memory locations as INTEGER without naming them all, just make them INT and leave the name blank the way it is before

Click to expand...

You wouldn't have to do this if the variables aren't assigned a symbol. You would just use the absolute address in your program. Whether specific functions do the typoe checking or not is a different story, but even with type checking turned on, your standard instructions (such as adding MW2400 and MW2600 in ladder) won't fail because the two MW's were not defined as ints in the symbol table.

It all boils down to this..........If type is so critical to Siemens and S7 then why does S7 make it soooooooooooooooooo easy to get wrong?

Click to expand...

I'm not sure what you mean. Maybe you are looking at it from the wrong perspective. When you define an address in the symbol table, S7 has no idea how you intend to use it, especially if you haven't even started writing code yet. I suppose that the argument could be made that it shouldn't default to word when you add a symbol, but after the first time it happens anyone would expect it, and would enter INT, WORD, S5TIME, or whatever matches a two-byte variable.

Turning type checking off does not remove the problem of missmatched types it just turns off the alarms. I do not think this is good advice to anyone. I want MORE type CHECKING and less NEED for type checking.

And what "house keeping" are you refering to? DAta types match or not, S7 tells you or not.

Click to expand...

No, not really. In LADDER, there is some protection when you have type checking on, but that's a function of the editor, not the S7 code itself. I could switch to STL and enter the following code, and it wouldn't complain a bit, whether type checking is enabled or not:

L MW10
L 1.070000e+001
+I
RND
SLD
L 'ABCD'
+D
T MW20

It makes no sense, but it lets me do it (and there are very good reasons to let me mix data types in my code). But if type checking is important and you don't want to do your own housekeeping, then enable type checking and program only in ladder. That should enforce enough rules until someone is more confident with turning it off.

Why can't I compare an Integer with a Real number?

Real numbers contain integers.

(Imagine these are in LAD)

10 < 12.62578

there I did it.

10 > 2.67392

What's the big deal? Turn off type checking and this works right? I am asking for clarification. What is so bad about doing this?

Click to expand...

Not, it doesn't work, even in STL. An INT 10 is just a bit pattern in the accumulator. A FLOAT 10 would be a different pattern, as would a CHAR '10' and a hex 10. That said, there are times when it would work if you really knew what to expect for results (I could compare an INT against CHAR '5' for instance, but I would have to realize that CHAR '5' is actually INT 53), but I can't think of a case where I would compare an INT to a FLOAT, because the data types are so radically different.

Out of curiousity, how common is it in other PLCs to be able to do as described above (10 < 12.62578 ) without first conditioning the FLOAT value? Even in some of the other languages I use which is very loose with type checking, it wouldn't let me do that. I would have to do something like float(10) < 12.0

So much of the discussion seems to get personal or defensive, I don't get that bit.

Click to expand...

Not at all. I have ripped Siemens up one side and down the other often enough, and think their WinCC Flex is a joke. Jesper, another Siemens user here, put in a lot of effort gathering lot of user complaiints about the software. But honestly, the good outweighs the bad, and once you learn the package (you know, like every other software), you'll be fine.

PLCs were made to replace relays, not PCs.

That is why they are simple, or why they were simple.

Now the difference between PC and PLC is growing so small it is easy to make the arguement to just switch to C or some other PC based language.

Click to expand...

It's the application that makes it complex, not the PLC. I could show you some programs written for a Siemens 155U back in 1982 that was way, way beyond "replacing relays". PLCs are used to control a process, and relays are just a small part of that.

I have never met the maintenance man in any plant that could use S7.

Click to expand...

Seriously, I know hundreds. Maybe you are working at the wrong plants.