Step7 MUL R appears to not work.

See the MUL R to the right?

Why does it not mul?

I moved it to its own network, saved and exit and download , nada.

I want to modify a variable in the DB by another amount in the DB and then put the result in the same DB.

I changed the result to a Dword thinking it was a DB issue with putting the result in.

Looks like it is not reading the data out of the DB correctly if at all.






here it is with representation set to automatic.

The value coming out of FC1020 is being written to DB95.DBW24 (integer) - you cannot then read it as a real from DB95.DBD24 and expect sensible results. Maybe you should re-code FC1020 to produce a real instead ?

I use the rVariable, iAnotherVariable etc. naming convention to highlight these problems.

Your data types are way off. You are using DWB 24 on the left, and DBD 24 on the right. Look at your values- they are incredibly small, and I doubt you have a device that gives you that kind of feedback.

It goes back to the discussion that we were having the other day. You said you turned type checking off and comparing an INT and a REAL worked, but actually it didn't. You have to study the accumulators to make sense of it.

Are you controlling the ENO using save command in FC1020?

L D[AR2 said:

The value coming out of FC1020 is being written to DB95.DBW24 (integer) - you cannot then read it as a real from DB95.DBD24 and expect sensible results. Maybe you should re-code FC1020 to produce a real instead ?

I use the rVariable, iAnotherVariable etc. naming convention to highlight these problems.

Click to expand...

I tried for a long time to to get it to work, the values you see on the right are auto filled by S7 and after several tries I just gave up. I start to type in the db95.dbw24 and it takes over and enters db95.dbd24 with the tag name. It is like a mad spell check program. Really tiresome.

I like being able to have the symbol block pop up and I can select a defined variable, but when I explicitly select one , I do not like for the other to be placed.

Just so I am clear DBW24 is a word and DBD24 is a DWORD?

That would make sense, but why can't I just enter it and hit enter and it go in the way I select it?

WHat you see on the right is what S7 did with its autofill selection.

I am sure I did something to provoke it though.

The FC1020 just averages 10 integers and gives the result, however, I then want to divide that by .8 which is relative to a process calculation and give a result. This part needs to be a real.

SO the break down is when I put the result as an INT into DBW24 and then go get it as a real from DBD24?

That makes sense, I completely missed that somehow. There is a point when working more hours does not equal more work. I think I have passed that point on several days.

S7Guy said:

Your data types are way off. You are using DWB 24 on the left, and DBD 24 on the right. Look at your values- they are incredibly small, and I doubt you have a device that gives you that kind of feedback.

It goes back to the discussion that we were having the other day. You said you turned type checking off and comparing an INT and a REAL worked, but actually it didn't. You have to study the accumulators to make sense of it.

Click to expand...

This time I did not even realise that it had happened.

I put an INT into a real in the DB I think. And it just didn't click.

I knew it was wrong somewhere, but just didn't see it. I completely missed the DBW and DBD makes sense now though.

On another note...........

When I compare like < or > an INT with a REAL it does work reliably which is kinda odd.

I have just for fun and discovery added a network that looks at oil level as an INT and a REAL and does < compare and turns on a coil to nowhere. And it is correct everytime I look at it.

The network can tell 22.3 REAL is greater than 22 INT.

Also as a reference to your doubt, I am reading an oil level every minute and taking an average of the drop during that period.

I am reading .694 mm drop in 10 minutes.

In the field this will be changed to a reading every 10 minutes and an ave every hour, day, week. But I don't want to sit here for 3 hours to see if the math works.

I have 27648 steps in 300 mm. It's just a gee whiz number for humans to compare today with last week.

None of it matters as far as real machine control is concerned so I don't care if it's accurate.

I only need some apearance of consistancy and a plausable number to display on a pointless HMI for people to ignore after the initial OOOOO AHHHH wears off.

Nick B said:

Are you controlling the ENO using save command in FC1020?

Click to expand...

The FC is written with LAD so S7 put the ENO in automaticaly.

And in the post I mentioned that I even put it on a separate network, I may have said "rung", with that same results.

Good point though.

I should realise by now that when the numbers look funny it is a data type issue from word to dword or some such.

I am getting there.

small incredibly small.

S7Guy said:

Your data types are way off. You are using DWB 24 on the left, and DBD 24 on the right. Look at your values- they are incredibly small, and I doubt you have a device that gives you that kind of feedback.

It goes back to the discussion that we were having the other day. You said you turned type checking off and comparing an INT and a REAL worked, but actually it didn't. You have to study the accumulators to make sense of it.

Click to expand...

Do you really think 34 and 0.8 are incredibly small???????? (0.8 is a muliplier to get oz of oil from the level of oil, but I suspect it is incorrect. It is supposed to be the number of oz per digit of the analog in. Not my number. It as measured by weighing the oil and comparing the differential level. I would have used a volumetric measure and put the level transmittter over a known quantity / depth and calibrated the actual ..blah blah........)

I was a calbration /electronics/ metrologist, in the USAF. I have a decent grasp of precision/accuracy/resolution/ etc. I just had to explain how my homemade manometer works to a mechanical engineer and he argued with me about it.

So if 0.8 is "incredibly small", why do real numbers have so many places to the right of the decimal? you only need 3 or 4 for most industrial suff, if that.

I used to work with numbers that were expressed as 4x10 -12 and these were the big numbers! (Cesium beam clock deviation was
4x10 -16.)

So .001 to me is not a small number.

Small is a relative reference don't you think?

Does S7 have trouble with "small" numbers?

Like .0000000002 times .0000004? I would hope not.

dahnuguy said:

This time I did not even realise that it had happened.

I put an INT into a real in the DB I think. And it just didn't click.

I knew it was wrong somewhere, but just didn't see it. I completely missed the DBW and DBD makes sense now though.

Click to expand...

A REAL is a four byte variable. If it is a low value (or even zero), it uses the whole four bytes.

When I compare like < or > an INT with a REAL it does work reliably which is kinda odd.

Click to expand...

No it doesn't. You have to get over this hurdle before you start working with floats. Do this for a test (you can copy this to your editor in its own network in STL, and it will convert to ladder):

L 10
L 9.500000e+000
>I
= #Test (This can be any available variable)

Then change the 10 to a 5. What happens?

Also as a reference to your doubt, I am reading an oil level every minute and taking an average of the drop during that period.

I am reading .694 mm drop in 10 minutes.

Click to expand...

I'm sure the numbers are small, but your screen shot was showing 4.775 +-039, which as we would say in the north, is a wicked small number. Look at the math.

You cannot overlap DBW24 with DBD 24. You are going to have to average your INTS, convert the result to a real, and then use the real to do math with.

dahnuguy said:

Do you really think 34 and 0.8 are incredibly small????????

Click to expand...

No. But I consider 0.000000000000000000000000000000000004775 incredibly small.

I was a calbration /electronics/ metrologist, in the USAF. I have a decent grasp of precision/accuracy/resolution/ etc. I just had to explain how my homemade manometer works to a mechanical engineer and he argued with me about it.

Click to expand...

That's all well and good. But you have to understand REALs to get your program too work.

Just to amplify from the previous post, any compare of a floating point variable with an int variable is nonsense.

It seems that you're still strugling with some of the less obvious matters regarding data types.

Your output from FC1020 is an integer with a value of 43; this is represented in binary as 0000 0000 0010 1011 - it occupies two bytes of memory.

The MUL_R block in LAD multiplies two floating point number in the format of Sign(1 Bit)+Exponent(8 Bits)+Mantissa(23 Bits). If you try to give it a parameter in ladder with symbol selection turned on it trys to help out by only giving you the option of suitable variables.

If you wish to multiply in int with a float you must first decide what answer are you looking for? integer or float? I suspect the latter but this isn't necessarily the case. Follow the previous suggestion and modify FC1020 to output a float, that way you wont loose any precision in your average.

Something else that isn't immediately obvious when wtiting FCs for use in ladder is that the ENO part is governed by nthe state of the BR (Binary Result) bit at the end of the function. This can be useful for example to prevent execution when a certain condition is or isn't true - take a look at the descriptions of the ladder compare funcions to see it's use. It you don't want anything to interrupt the processing of subsequent ladder instruction you you set the BR bit before exiting your function call; this is done by inserting the following code at the end of your function:

Set //Set the RLO to 1
Save //Save RLO to BR
CLR //Clear the RLO

Sorry if this seems complicated but the end result of this learning is worth the effort.

Oh and yes VERY small numbers can be problematic.

Nick

I would use symbolic addressing, makes it easier at times.

therefore if you give the DB a symbolic name "MyDataBlock" and then create an INT called Average and a REAL called REAL_Average, in the program you could then address by

"MyDataBlock".Average and "MyDataBlock".REAL_Average, these cannot be placed in the incorrect place and you would be reminded to convert your INT to REAL

S7Guy said:

A REAL is a four byte variable. If it is a low value (or even zero), it uses the whole four bytes.

Yes I am aware of this, and it is a large part of the reason I prefer to use INT when I can.



No it doesn't. You have to get over this hurdle before you start working with floats. Do this for a test (you can copy this to your editor in its own network in STL, and it will convert to ladder):

If you add "You have to get over this hurdle before you start working with floats .......in S7 "

I agree. I know what a float is. I have used floats in the past a couple times. Just not with S7. If you used something else you would see the difference. Maybe not, but if you use S7 only, you will never get why this is such an issue.

L 10
L 9.500000e+000
>I
= #Test (This can be any available variable)

Then change the 10 to a 5. What happens? ..............In S7.



I'm sure the numbers are small, but your screen shot was showing 4.775 +-039, which as we would say in the north, is a wicked small number. Look at the math.

The actual number was not that small this was because of the missmatch. I see where your comment came from now.

You cannot overlap DBW24 with DBD 24. You are going to have to average your INTS, convert the result to a real, and then use the real to do math with.

Click to expand...

Yeah thats what I did..........

Second time.

First time I did not know I have to divide by .8 else I would have made the output of the FC a real.

I put an INT into a DB location defined as a real. (Which I do not think should be allowed, but that's another issue.

You seem to think I don't "get it" for some reason.

It was an oversight , I did not intentionaly put the INT into a DWORD and then try to use it as a REAL. I understand the bits and pieces, I am just used to working with software that will do the conversion on the fly and not freak out.

S7Guy said:

No. But I consider 0.000000000000000000000000000000000004775 incredibly small.



That's all well and good. But you have to understand REALs to get your program too work.

Click to expand...

That whole bit was an effort give some background and to "share".

Not sure how you take things, but they are rarely the way I mean it.

I apreciate your help and I respect your expertise, but you and I seem to have a missmatch in communication style.