Step7 - Peculiar behaviour when viewing Block online

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
The customer wants to use an existing function block from previous projects to generate variable length pulses. The block looks pretty simple (apart from the fact that it's totally uncommented :angr: ) and it requires only a level rather than an edge to start it and saves to counters. The operator can set the length of both the impulse and the pause between impulses from the panel. The only problem is - it doesn't work!

This is the program:

Takt_1.JPG


and here is the block being called with the various parameters and associated comments:

Takt_2.JPG



Actually the program originally started at label MX: the bit before that I added to try to see what was happening.

As you can see, significant bits of the program are - apparently - not being run through very often, or even at all. The key bit of the program is the line shortly after label M001: - ON #Takt

#Takt is actually fed by M3.0 which is an impulse for one cycle which appears every second. It's derived from the CPU frequency generator Byte. Accordingly, the part of the program following the jump SPB M004 will only run once every second, thus spending most of its time greyed out - as it is in the screen dump. However, it should run every second and update #IW each time - it doesn't, #IW apparently gets updated randomly at intervals of between 10 and 20 seconds. Apparently, as a result of this the comparison of the #IW (current value) with #SW_Pau (the setpoint) is never, or perhaps only occasionally satisfied, so the Impulse output is never turned on.

I say apparently, because the extra bit of program I added at the top of the block behaves in exactly the same way, but, if I look at the value MW610 in a VAT, sure enough it's counting up once a second!

Anybody got any ideas what's going on here - both with the apparently incorrect display and, given that the pulse input is being handled correctly in my additional bit of program, the actual pulse output is not happening.

The customer is adamant that the FC works as desired in previous projects.

Edit: Just noticed that another of my mods is still in the program the 5 lines following the S #Impuls command are also not in the original program. I've just checked this a bit more closely in the VAT and it turns out that M600.0 is actually being set at the end of every pause (5 seconds in this case), however, it is apparently only on for 1 cycle as the output bits in the VAT only occasionally blink. Maybe the program does work quite the way the customer thinks it does.

Guess I'll need to look at that a bit more closely!
 
Last edited:
I take it IW is a IN_OUT?? if its an IN then probloids

Impuls is an OUT definate and seems to be using its condition before it has been conditioned!!!!

WRONG WRONG WRONG (unless of course its also conditione prior to the section of code we see)
 
Last edited:
Hello Roy,

Is it possible that #Ein is being erratic? That would cause #IW to be set back to 0. Just a thought.

In a case like this where you are troubleshooting events, I like to sprinkle counters at various test points to see what's going on. Just stick, for example, CU C50, CU C51, etc, and see what parts are being scanned with each Takt.
 
Can't you change it to English, I believe SPA = JU and SPB = JC??
Sorry can't change to English, but yes, SPA = JU and SPB is JC. I guess almost everybody knows that U = A !

Jesper, can't post the project from here, but the block FC413 is complete, there's no more code folowing SPB M002.

I hope I can attach it as a txt file here.

And this is the way the 1 sec pulse is generated in OB1 M1.5 is the CPU frequency generator:

1_sec_pulse.JPG
 
You guys are so fast it's hard to keep up!

PeterW, yes, #IW is an IN_OUT, need to take a closer look at the way #Impuls is being used though.

S7Guy, I've done exactly that and that's how I noticed that the output is in fact being pulsed briefly at the end of every pause period. The real problem appears to be that it is not staying on for the number of seconds defined in #SW_Imp.

Is it possible that #Ein is being erratic?

I don't think so, it's a local bit I'm using in the calling program (which I'm writing myself) to say that the level in the tank is over the High limit (GW3). The analog values I'm setting directly into the DB from the VAT and the Analog input scan has been turned of (the DP doesn't exist anyway), so I'm pretty sure that that area is OK.

Since the #Impuls signal is actually being turned on at the right time, albeit only for (probaly) one cycle instead of the desired 5 seconds, I'm beginning to think that the program doesn't work the way the author intended. I'll go and have a closer look at that now.
 
Last edited:
as this is an FC using #Impuls before its conditioned is bad, as it could be anything up until the point its conditioned. If this was an FB it would be OK
 
Hello again Roy.

We also need the declarations.
If you cannot zip and post the project or a cutdown project, then generate the source for the interesting blocks. Then we can load it into STEP7.

edit: from the screenshot it can be seen that #impuls is an OUT. So I think PeterW has nailed it.
 
Last edited:
Looking at it, it counts up to 6 (> SW_Imp which =5) then sets Impuls, then recounts to 6 and resets Impuls.

The problem is, you cannot SET an OUT parameter in an FC, change it to an IN_OUT and it may work.
 
from the screenshot it can be seen that #impuls is an OUT. So I think PeterW has nailed it.



I think you may well be right there, but off-hand, I can't see how I can initialise it as the program stands.

Need to think about that one a bit more!
 
Pardon me if I am now sidetracking the thread, but I think that what you want to do is easy to do with IEC timers.

Attached is a small project with a generic FB that will provide you with an ON-OFF pulser with adjustable timing.
 
I've already been round this loop with the customer. He's worried about the number of Timers he has available and I suggested using IEC Timers instead, but firstly, he's not too comfortable with them and secondly, they count up and we need to display the remaining time (#IW) on the panel.

Peter, I tried changing #Impuls to IN_OUT, but not only did it not work, the #IW display in the VAT stopped counting, which has left me more than a little puzzled!

I'd been bothered about reading an OUT from square one, but re-reading Berger, I came to the conclusion that he implied it ought to be OK under these circumstances. Actually when I think about it, I'm not sure I can see why making it an IN_OUT should help in this situation - after all it's still just an undefined memory area that's being assigned to it, or does the CPU's OS initialise INput words?

To come back to the other question, anybody had any thoughts about why the display in VIEW does not show what's actually happening?
 

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
156
When you download a DB, the values get overwritten by what is in the "actual" column in offline DB. Does this happen at the start of the PLC...
Replies
6
Views
152
Hello Inside a FB, I´m trying to transfer a string from a DB to a IN_OUT var that was define as a UDT. The problem is that i can´t determine the...
Replies
4
Views
144
Hi all, I am trying to convert RSLogix 5000 program to Step7. I need to bit shift left my array of double integers for tracking the product on...
Replies
2
Views
528
I have a word in some DB which I want to load to AR1 and use as a pointer. In order to do this I need to write L DBxy.DBW xy SLD 3 LAR1 I...
Replies
3
Views
544
Back
Top Bottom