4-20mA scaling (PT100 measuring) in Step7

[Ken M]

Dahnuguy

There is nothing sacrosanct about the numbering of an FC. If you write an FC and name it FC100, it will work just as well if you rename it to FC200, or FC327 ... Now clearly the reverse of this is that we could each write two utterly different functions and name them both FC666. Which one is the real FC666, mine or yours?

For the matter of Siemens having produced two separate libraries of functions, each one happening to contain an FC105, I don't think they expected users to simply grab the first thing they saw with FC105 written on it and ram it in to their own project without checking what it does.

Now a further layer of abstraction is the 'symbolic' name given to an FC (or any other program element). I might call my FC666 "Humidity" and you might call yours "Valve Ctrl". If I change the symbolic name of mine to "Speed" that doesn't change what the block does. So ultimately I could have an FCxxx with a certain amount of code in it, and complete freedom to give it whatever number and symbolic name I wish.

Some software designers and coders will have their own or their company's conventions about numbering and naming FCs, FBs, and DBs. But as a very general rule of thumb most users in the Siemens community will tend to stick with specific numbers as originally allocated by Siemens in their libraries. So usually when you talk to someone about an FB41 you would expect it to be a PID control block. Why 41? Who knows - lost in the mists swirling around (inside?) Siemens Bavarian design offices.

My guess is that if you had an FC105 with a given symbolic name in your project, and then dragged or copied a different FC105 with a different symbolic name in to your project, the 'newer' name would overwrite the older. If you need to use the same FC105 in multiple locations to deal with multiple different operations, then just use it. But remember, it is a 'function' - it does just one thing. It has no concept of being assigned to or attached to another entity like a plant device or sensor. FC105 is just an operation like a 'plus' or 'divide by'. What is unique to each occurrence in the program is the actual parameters you apply. That's where you should be assigning a symbolic name to the input variable to identify what it is that's being scaled.

I'm not specifically defending Siemens here. But don't confuse being different for being worse.

Ken

 

[dahnuguy]

Lots of good info, thanks,

As far as the numbering thing goes , it just strikes ma as odd to have so much variable. I would expect an "ADD" block to say "ADD" somewhere and not be able to change that. So I thought that FC105 was a "SCALE" block and this should not be changed.

When I found 2 FC105s I wondered how would a person distiguish between the two blocks in a conversation or in use?

Which FC105?

I still think it odd, but as long as it is constant I can accept it.

And I am ok with 41 or 53 or what ever, I prefer numbers to words most of the time, but it was the changing of the reference that threw me.

And I am not confusing different with being worse. I am evaluating what it takes to make sense of system "A" and comparing that with the same experience in system "B", "C", "D", and "E".

And so far "A" is way behind on ease of use for a new user.

Last month, I learned MicroWin in 3 days. WinCC in 2 days. Most other PLC programs in less than a week. Never more than a week to be fully familiar with all basic functions.

I am on week 4 with Step7 and still have questions about the basics. If I had not used so many others , I would have doubts about my mental capacity.

I am not making unfounded judgemental attacks on S7 , that would be silly. Once I have gotten to a higher point on the curve , I will be able to write it all out and better express the issues as seen by a new comer.


Thanks for your time.

 

[dahnuguy]

Ken M

Dahnuguy



If you need to use the same FC105 in multiple locations to deal with multiple different operations, then just use it. But remember, it is a 'function' - it does just one thing. Ken

I am not sure I get that staement.

It feels like I do , but I suspect there is something here I do not understand.

The way I see it (and I have already discovered I am incorrect in this thought, but stay with me a minute) I should be able to use a compare or function as often as I like until I run out of memory.

Everytime I use GT_I it is still the same item. Same function.

So I expected the same to be true with "SCALE" and "LIMIT" but they ask to be renamed, which is so odd still. I can rename FC105 to FC106 and the program still knows its really FC105. What is it exactly that makes a function a function and how does anybody including the program know which is what if they are renamed?

It feels like renaming the >= to < and nobody notices.

But I accept that the name doesn't matter, not hung up on it, I just don't get it.

Now I would like to use the same function in several places.

If I follow you, I just pick FC105 again and drop it in the ladder network and rename it and just go on with it.

Or did you mean "just use it again" in a different manner?

I have been reading about using the same block and just using different data blocks for each instance. Which is kinda neat, but a little confusing. And I am not sure anyone would be able to follow what I did later.

I see that as the only real value of ladder, others can follow it easily. Even if they can't program anything.

 

[widelto]

sorry, to bother you folks, but this is one of the reasons i never use siemens plc, with ab this is so easy, and can be solved with just one instruction SCP.

 

[Ken M]

...but they ask to be renamed...

Uh-oh, something's going wrong here

You're quite right about instructions at the level of ADD or CMP_I etc. They can't be renamed, as they are part of the CPU's operating system. ADD will always be ADD, and there will never be an entry in the Symbol Table for it. It just "is". You use it as often as you like, every time you want to ADD some numbers.

These instructions are what you use to create your prgram. I suppose you could say that everything else is just packaging or structuring. What's inside an FC? Why, instructions. The particular collection of instructions you (or Siemens) put together in an FC or FB is completely unknown to a CPU until you do it. The CPU doesn't 'know' that the 105th FC will be used for scaling and be named "SCALE" until someone writes it and names it. Thereafter, you should be able to call FC105 just as often as memory constraints permit, just as you anticipated. There should never be a situation when a function 'asks to be renamed'. Can you describe this in more detail? When and how does does it happen?

Exactly how are you programming? If it's ladder, just drag and drop the (correct ) FC105 in to your network. It should be perfectly happy existing alongside all these other FC105s. Then tell it what the parameters are i.e. specifically what is to be scaled in this location. I've seen programs with 10's and 100's of FC105s - one for each analogue input in the system. They are all FC105 and there is only one entry in the symbol table linking FC105 to the symbolic name "SCALE".

The ease of use and speed of uptake issue is an old bone that's been chewed around many times in this forum. Some people value these features above all else. For others, the extra complexity of learning how to play the piano compared to the comb and paper is more than justified by the range of sounds and melodies that can be produced. Guess which side I'm on

Ken

 

[L D[AR2P#0.0]]

If you drag FC105 from the library each time you want to use it, the editor will ask you to rename or overwrite. If you drag it from the FC Blocks folder for the project, it will not. I personally highlight the rung where I want to insert and use ALT+F9 and then type FC22

 

[Ken M]

Aaahh.. so that's what happens. It's quite refreshing to say that I've never seen this symptom, so I've obviously never done it wrong! Well done L D[..whatever]

Dahnuguy,

This is STEP7 trying to resolve a problem you've posed for it. If you have a project with an FC99 already available in it, and you then try to introduce another FC99 from an external source (in this case a library) it won't permit two potentially different FC99s to exist in the same project. It's a bit like Windows and sub-folders - you can't create a new one with a name that already exists.

Ken

 

[dahnuguy]

widelto

sorry, to bother you folks, but this is one of the reasons i never use siemens plc, with ab this is so easy, and can be solved with just one instruction SCP.
__________________
Hope this will help
Bill


Yes, well for the point of disscusion, I will explain the issue at hand.

I have used maybe 6 different PLCs / programming languages.

I have spent several years with 3 different versions of AB.

I have noticed that most PLC software do similar things similar ways.

I have observed that learning a new program is like learning a new human language.

I have observed that thy all aknowledge an iput apply a decision and produce some output to manipulate the real world in harsh conditions 24/7 in all climates. This differs from a PC in that the PC usually manipulates data in an air conditioned office for a portion of the day and if it fails, no one dies.

That brings us to our point here.

Yes in AB I can drop a scale with parameters block and add what I need and go on to the next thing.

In Toshiba, I can drop a timer in a rung an and it flows the FLO without having to use another rung with a timer done bit like AB.

The list of who does what is long.

The advantages and merits of each are equaly long listed.

I have no brand loyalty. Management has selected Siemens for this project, I could say no, and go home or I can learn Step7 and receive compensation.

I choose "B"

Now Siemens is more like learning Arabic and all the others are more like Italian and Spanish.

AB is much easier and mich simpler and gets the ins in and the outs out.

So does everyone else.

Siemens allows massive amounts of control and detailed function and infinite customization. Is all tht needed? I don't think it is worth the complication, but I have not seen a process that requires such. I have seen one situation where AB was just not fast enough no matter what. Even the AB engineer said it just wont do it.

Now the reason I am here is not debate the whose got what. The only reason I mention AB is for comparison.

In the beginning, when learning a new thing we often try to translate the new through the old.

If done with an pen mind it can be a valuable tool, if done as an arguement it is a crutch and limits learning.

So when I say "I can do it in AB like this......" what I am doing is communicating my intent.

I could have writen this whole project in AB in a week and then debugged it in a week. Easily. It is a small project.

Right now , I can't even get the input scaled and turn on a heater with Siemens.

That is an issue with my knowledge of Siemens, not a limitation of Siemens and is not meant to be a slap to Siemens.

Just getting the PID in place and sorta functional took 3 days, and I haven't tested it. That is my limitation.

A good Siemens programmer would be done already.

I also hesitate to use comparisons to other manufacturers in this disscussion because total immersion is a good way to learn. Stop thinking how I would do it in AB and just try to work out how to do it in Sienmens.

There are several hundreds standard blocks in Siemens and they are not known to me.

I know Step7 can do it, but I do not know how. Yet.

So the point here is not to compare or debate merits of one or the other, the mandate is to make it happen. And quickly.

In addition, the guys here have been more than helpful and any statement that might seem un gratful or argumenative would be counterproductive.

So, no your comment did not help. You added nothing to the conversation.

One wonders why you wold read a post on Siemens if you are such an AB fan.

Until you learn at least 3 or 4 PLCs you will always have a limited perspective.

We all have something to learn , there is always someone ahead of you and there is always someone behind you. (This is true of all but 2 people at any given time)

 

[dahnuguy]

L D[AR2,P#0.0]

Well that is simple.

I was comming from the Library as I would in other PLC programs. Never thought to come from the FC block are of the project.

A good example of a simple thing being a big issue.

Thanks,

Doesn't matter which way works as long as know which way is which.

Thanks again.

 

[dahnuguy]

Ken,

The issue was taking the new FC105 from the library every time.

Step7 doesn't like that.

Doesn't make sense to me why, it is the same block from the same place and it is a stadard block. But it doesn't have to make sense as long as it is consistant I will learn it and do it that way.

This issue is not specifically addressed in the documentation, it is assumed that you would bring the block first from the library and then for some reason get the second one from another location.

I don't get it, but I accept it.

I am already intriged by what can do. Enough so, that I nolonger see it as a huge PITA.

It is un necessarily complex, but that's what Germans do best.

A german would say " But with brand Y I am unable to specify the location of the bits in the data block. Further I am unable to specify which unseen datablock to use in this function"

To which a user of brand Y would respond. "SO? Why do you need to?"

"But I must know where all the data is to properly refine the process"

"Why?, It's in there, it does what it needs to do, move on let go."

"I can not."

"OK use Siemens and you can control everything."

"Thank you , I will."

There you have it. The way I see it right now.

And to refine your music analogy I would add, If I can control the process with a comb or a pair of spoons, why learn classical piano for 5 years to play Happy Birthday properly?

Still I do not argue the why or whatfor. It is irrelavant.

This is the task,
I choose to do this task.

So far it is pretty fun. One more addition to the resume.

 

[dahnuguy]

I get the same result by taking FC105 from the library and choosing "NO" to the rename question as I do when I take FC105 from the "FC" area of the project.

After the first one, the "FC105 Scaling values" is omitted. The block does still retain the "Scale" text.

Now it all makes sense.

Not sure why you might want to rename it, or what S7 thinks you might be doing that might need a rename, but that's another issue. No time for those.

Now on to the local varibles at the top of page. Also something I have never seen in A,B,C, or D brand.

I almost like it, I supect it has several uses.

Not sure why I need though.

It gives me the chance to make something a local varible when I may need it later as a global variable.

It may be useful in someway. I just don't see how yet.

 

[ArikBY]

dahnuguy

I follow this thread.I am in about same situation like you.
I know what the feeling.
I have lot experience with other PLCs and Siemens is like French for me (Arabic is easy)
Take a look at this link my be it can give some help.

Good luck
P.S.
I must say I learn a lot from your thread.


http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&objId=21064133&objAction=csOpen&lang=en&siteid=csius&aktprim=4

 

[dahnuguy]

ArikBY vbmenu_register("postmenu_294065", true);

Thanks,

I should have said like Arabic to an English speaker.

I studied some Arabic and Spanish / Italian and some small Latin in English class. So for me it was a valid comparison.

The verbs in Arabic killed my chance for success. So many forms. ACK.



It is good to know that someone else is benefiting from my shared pain. LOL

I suspect this is the way.

The guys who know, do not have the questions.

We who ask, do not have the answers.

All we need is to put the two together. Which is not always easy.

I am about to look through the information on your link

Thanks,

 

[dahnuguy]

Ken M

I may have found my solution.

I opened the standard FC105 and removed the bits I don't like.

Changed all the real numbers and real math to INT and INT math and saved it as FC1055.

Now if I could get rid of the "RET VALUE" on the block.

I got rid of the BIPOLAR part, I just want as few items as needed to do what I want and writing it in ladder and including the standard block, while very clever, seems a bit cumbersome.

I also suddenly understand some of the syntax in the source code.

This is way too much fun.

If the guys in brand Y could see this, they would flip.

Now if I can resist the urge to write function blocks all day and actualy do the project.

The machine is no where near as interesting as Step7 is !

When in source code it looks allot like Visual Basic.

Thanks to all.

A word of caution, I have not received my hardware, and I have not run this in the simulator. It can't hurt anythnig, but it may not work just right yet.

If you see any errors, please let me know.

This is fun.


FUNCTION FC 1055 : WORD
TITLE =SCALING VALUES INT
//
AUTHOR : DAHNUGUY
FAMILY : CONVERT
NAME : SCAL_INT
VERSION : 1.2

VAR_INPUT
IN : INT ; // input value to be scaled
HI_LIM : INT ; // upper limit in INT
LO_LIM : INT ; // lower limit in INT
END_VAR
VAR_OUTPUT
OUT : INT ; // result of the scale conversion
END_VAR
VAR_TEMP
IN_INT : INT ; // input value as an INT
K1 : INT ; // low limit for input value
K2 : INT ; // high limit for input value
SPAN : INT ; // HI_LIM - LO_LIM
TEMP1 : INT ; // temporary result
END_VAR
BEGIN
NETWORK
TITLE =
//
// set K1 and K2 constants NO BIPOLAR
//
SET ;
L 0; // K1=0
T #K1; // .
L 27648; // K2=+27648.0
T #K2; // .
//
// LOAD input (IN) to IN_INT//
L #IN; // ACC1=IN
T #IN_INT; // IN_INT-IN as a INT
//
// determine SPAN = HI_LIM - LO_LIM
//
L #HI_LIM; // SPAN=HI_LIM-LO_LIM
L #LO_LIM; // .
-I ; // .
T #SPAN; // .
//
// If the input value is outside the K1 and K2 range, the output
// is clamped to the nearer of either the LO_LIM or the HI_LIM
// and an error is logged. If the input value is exactly at a limit the
// output will be set to the computed limit with no error returned.
// changed 2/14/00 by ERI per RQ210693
L #IN_INT; // if(IN_REAL<K1)
L #K1; // .
>=I ; // .
JC EL02; // {

L #LO_LIM; // ACC1=LO_LIM
T #OUT; // OUT=ACC1
EL02: POP ; // } else {
L #IN_INT;
L #K2; // if(IN_INT>K2)
<=I ; // .
JC EI04; // {
L #HI_LIM; // ACC1=HI_LIM
T #OUT; // OUT=ACC1
EI04: NOP 0; // }
NOP 0; // }
//
// scale the input
//
L #K2; // TEMP1=K2-K1
L #K1; // .
-I ; // .
T #TEMP1; // .
L #IN_INT; // IN_REAL-K1
L #K1; // .
-I ; // .
L #TEMP1; // divide by TEMP1
/I ; // .
L #SPAN; // multiply by SPAN
*I ; // .
L #LO_LIM; // add LO_LIM
+I ; // .
T #OUT; // OUT=scale(IN_REAL)
//
SET ; // RLO = 1 (NO ERROR)
END_FUNCTION

 

[ArikBY]

The verbs in Hebrew is very similar like Arabic.So it very Easy for me.

I did not like to benefit from other pain.It might my pain tomorrow.
I can understand your situation.
I don't have tight schedule for what I doing now.
I know how hard Siemens can be for first time.
I have a book which can help you but it on hard copy.
I will try to get PDF and send it tomorrow.

Good Luck