Calling a functional block multiple times with different parameters

spandy16

Member
Join Date
Dec 2012
Location
Germany
Posts
58
I need to call a IO LINK functional block multiple times by triggereing the REQ bit. But every call I want to pass different parameters like changing the Index of the CALL function and changing the RECORD destination. COuld anyone give me an insight over this?
 
Maybe it's a STD_FB that i'm not aware of...Siemens?

Yes, Sorry that I didn't mention it. I am working in TIA Portal V11 and the functional block is provided by Siemens. It's basically a combination of RD_REC and WR_REC functional block. Quite similar in functionality.
 
Then you can build your own FB as a wrapper passing parameters to the STD_FB located inside yours.

Obviously it's not the block you want to use but you should get the idea

wrapper_FB.jpg call_wrapper_FB.jpg
 
Then you can build your own FB as a wrapper passing parameters to the STD_FB located inside yours.

Obviously it's not the block you want to use but you should get the idea
Yes true, I think that makes sense of calling the STD_FB with different parameters. And is there any possibility that by one Input (==1) the STD_FB gets called sequentially with different parameters. Actually I want to read some parameters with diffrent indexes and then store them in memory by just one press of a button.
 
Then I guess you could just build a sequencer, and from the push of 1 button step enable steps 1 through to 15 for example, each step that is active calling the next function.

Code:
a PB
s step_1
//Step through steps 1..15 in whatever way you like
//Use a timer or if the STD_FB you are using has a "BUSY" bit

a step_1
jc wrapper_FB
//wrapper fb parameters

//activate next step_2
a step_1
an step_1_busy
s step_2
r step_1

a step 2
jc wrapper_FB
//next wrapper parameters

//activate next step_3
a step_2
an step_2_busy
s step_3
r step_2

Clearly it won't work as is, but again the idea is what you are looking at.

Sequence through steps and each step activates a new instance of the wrapper_FB call
 
Then I guess you could just build a sequencer, and from the push of 1 button step enable steps 1 through to 15 for example, each step that is active calling the next function.

Code:
a PB
s step_1
//Step through steps 1..15 in whatever way you like
//Use a timer or if the STD_FB you are using has a "BUSY" bit

a step_1
jc wrapper_FB
//wrapper fb parameters

//activate next step_2
a step_1
an step_1_busy
s step_2
r step_1

a step 2
jc wrapper_FB
//next wrapper parameters

//activate next step_3
a step_2
an step_2_busy
s step_3
r step_2
Clearly it won't work as is, but again the idea is what you are looking at.

Sequence through steps and each step activates a new instance of the wrapper_FB call

By this way is every call unique ? because otherwise I will get a IOL_CALL conflict error. And is it possible with labels?
 
I dont get it. Why have to make it so hard ?

RDREC and WRREC are SFB's. Function blocks can be instantiated by simply assigning an IDB for each call.

I dont know IO Link. Is it that you can only process one connection at a time ?
Normally, you have to monitor the "BUSY" and "DONE" bits. Only when the BUSY bit goes off and DONE goes ON, and thereby tell you that the previous REQ finished, may you start it with another REQ impulse.
 
I dont get it. Why have to make it so hard ?

RDREC and WRREC are SFB's. Function blocks can be instantiated by simply assigning an IDB for each call.

I dont know IO Link. Is it that you can only process one connection at a time ?
Normally, you have to monitor the "BUSY" and "DONE" bits. Only when the BUSY bit goes off and DONE goes ON, and thereby tell you that the previous REQ finished, may you start it with another REQ impulse.
Yes, I got your point about the BUSY bit. It's just that once I tried making a conditional jump for the IO Link FB and there was a call conflict. But I will definitely try it in other way.
 
You should not jump past any of these FBs. They have to run through several scans for each REQ. If you interrupt it you will mess it up.

You control what it does by setting the REQ bit.
 
You should not jump past any of these FBs. They have to run through several scans for each REQ. If you interrupt it you will mess it up.

You control what it does by setting the REQ bit.
you gave a hint about calling every time a FB with different parameters by performing a conditional jump. Did you mean using labels because I am not able to make a 'jc' command with the call function. I have never done this so it would be better if you could elaborate it more. Thank you very much for your support.
 
No. I never said you should call the FB by a conditional jump.
On the contrary.
If the FB has started sending or receiving data (by means of the REQ) you may not interrupt it.
The simplest is to call the FB in every scan.
If you want to save a tiny bit of processor scan time you may try to execute the FBs conditionally. But you have to monitor the BUSY, DONE and ERR bits.
To do so would only be worth while in the old days when the CPUs were much slower. Today it is not worth the effort, or the risk of screwing things up. KISS !
 
No. I never said you should call the FB by a conditional jump.
On the contrary.
If the FB has started sending or receiving data (by means of the REQ) you may not interrupt it.
The simplest is to call the FB in every scan.
If you want to save a tiny bit of processor scan time you may try to execute the FBs conditionally. But you have to monitor the BUSY, DONE and ERR bits.
To do so would only be worth while in the old days when the CPUs were much slower. Today it is not worth the effort, or the risk of screwing things up. KISS !

I get your point. My task is to cyclically read the values from the sensor. So this IO link FB with the help of positive trigger at REQ bit reads one data. Then for the next data I need to again trigger the REQ bit as well as change the Index parameters and Record location so the new data is recorded and stored at some other place. And I need to do this until all the required parameters are read from sensor. That's why this was gettin a little bit tricky.
 
Then I guess you could just build a sequencer, and from the push of 1 button step enable steps 1 through to 15 for example, each step that is active calling the next function.

Code:
a PB
s step_1
//Step through steps 1..15 in whatever way you like
//Use a timer or if the STD_FB you are using has a "BUSY" bit

a step_1
jc wrapper_FB
//wrapper fb parameters

//activate next step_2
a step_1
an step_1_busy
s step_2
r step_1

a step 2
jc wrapper_FB
//next wrapper parameters

//activate next step_3
a step_2
an step_2_busy
s step_3
r step_2
Clearly it won't work as is, but again the idea is what you are looking at.

Sequence through steps and each step activates a new instance of the wrapper_FB call

I tried calling the RD_REC FB cyclically. But I guess there is a conflict with each call. How I should make sure that my every call of the RD_REC function passes different parameters like Index and the Record data?
 

Similar Topics

This is the first time I am working with Simatic Manager Step7 as I started my siemens journey with TIA which is pretty easy and do a lot of stuff...
Replies
3
Views
144
I am looking to get an AB series 1774 (PLC1) from the 1970's up and running. I have all the parts, and it powers up just fine without errors if I...
Replies
12
Views
2,321
Hello all, I’ve recently begun using Automation Studio on my own time to boost my knowledge of controllers beyond AB/Siemens. To ease myself into...
Replies
0
Views
899
Hello I'm new to PLC programming and I'm programing in ST. Programming envirement is GX works 3. I can't figure out how to jump to subprogram or...
Replies
1
Views
1,461
I have some code i need to block until a super genie for data entry has completed (by operator input)as per below. FUNCTION New_Setpoint()...
Replies
5
Views
2,274
Back
Top Bottom