1/12/2011 6:47 PM | |
Joined: 1/28/2009 Last visit: 9/10/2024 Posts: 6849 Rating: (1365) |
Dear Jens_app Happy news to do the task successfully. BR |
1/14/2011 7:29 AM | |
Joined: 10/7/2005 Last visit: 9/21/2024 Posts: 3021 Rating: (1054)
|
Hello Jens_app its hard to see without seeing the rest of the program, but here afew pointers/questions to start with: 1) If you have any "hardcoded" addresses inside your FC, you can loose the reusability factor of it. 2.) Are you relying on TEMP variables to retain their momery? 3.) You say that, "it doesn't work like it's suppose to" when Fc12 is called more than once, what exactly are you observing in this case? I suggest you upload your whole S7 test project and can then advise further. Last but not least, you can simplify your logic by replacing L P#0.0 LAR1 with LAR1 P#0.0 I hope this helps |
Cheers |
|
1/14/2011 1:40 PM | |
Joined: 1/5/2011 Last visit: 6/15/2024 Posts: 815 Rating: (123) |
I've finally been able to attach the program, maybe it's a bit more clear now.
AttachmentFC12.pdf (153 Downloads) |
Keep it simple and on-topic. |
|
1/14/2011 2:05 PM | |
Joined: 10/7/2005 Last visit: 9/21/2024 Posts: 3021 Rating: (1054)
|
Hello Jens_app by "hardcoded addresses" I mean using any form of global memory as a direct address inside the FC/FB. If you for example program a "T DB10.DBW6" or "S M7.7" or "SD T 15" command in it, you would "loose" reuseability of the block as thelast call of that FC/FB in your cycle would be the "winner" that writes to the address, sets the bit, tries to start the Timer etc. etc. Without having a program backup of your whole FC12 it is a bit hard though to guess what could be wrong and/or advise you further. Having said that, I must admit I didn't see the forest for the trees when looking at your code snippet asyou are actually using "hardcoded" global memory addresses in your FC (e.g. M0.0, M0.1 & M0.2). You may actually be using the M bits as some form of global "scratch" memory and they mustnot neccessarily be the cause of your problem (I'd replace them with TEMP's or Block parameters though). It could be though that whatever condition drives M0.1 and/or M0.2 is true (or false) in one call of FC12 but not true in another call and that they now maystayset or reset and thus falsify the write results in subsequent FC12 calls. I hope this helps |
Cheers |
|
This contribution was helpful to1 thankful Users |
Follow us on