S7 - Can anyone tell me what causes this?

I've had this happen a few times, but I've never really sussed out why or when.

As you can see, in the main AND structure, all the conditions are satisfied, but it still hasn't switched on. Just for a change I thought to make a screen-dump so I could post it.

I have a sneaky suspicion that it might be that the network has got too complex - there are another 14 similar structures feeding the final OR (all the possible combinations of the four Kollektor-Select signals). However, I'd be grateful if anybody can tell me definitely what's going on.



By the way if it's any help I've also got the View in STL if anybody's prefers it that way.

Roy

I have been faced with a similar problem before when working with 'complex' networks containing quite a bit of math. In the end I split the networks down into smaller ones, just to keep it in ladder (we won't go discussing the benefits of ladder over STL and vice versa as that has already been done in another thread)

I assume that you are seeing something similar to what I faced

Paul

I suspect that's the problem too and I'm already in the process of breaking it down into smaller chunks. It would just be nice to know for sure!

By the way, this isn't one of the occasion when View is presenting things incorrectly. The output of the final OR controls the visibility of the button to enable the operator to move on to the next screen and it isn't becoming visible, which it should do under the above conditions.

I had a similar problem that was caused by some logic in the preceeding network. Someone had commented out the "=M1.7" (as shown below) resulting in the A M0.6 starting the first check, the logic in the network I was monitoring "appeared" to be operating but the final result wasn't was as I was expecting.
When I switched to STL and looked at the whole picture, the problem became evident.

//Preceeding Network
A M0.6
//= M1.7

// Next network now controlled by previous network

That looks like it's my problem as well, Simon.

In the previous Network I changed my mind about resetting a particular Bit and commented out the reset command without thinking about the consequences of leaving the AND in place. As it happens, even in STL the Network is so big that it takes up more than a screen, so I had scrolled the start of the network right up to the top of the screen.

I did wonder why the RLO as shown wasn't what I expected, but the idea of going back to the previous Network didn't occur to me.

Another of those "interesting" ones to be filed away carefully for future use!

I've already chopped the Network up into smaller chunks - one Network for each possible combination which makes it a bit more readable anyway. It used to cover about five screens and even displaying it in ladder it wasn't much less!

RMA, my recommendation is that you should never comment out code. If you want to disable something, either jump around it or use logic that always evaluates to TRUE or FALSE. Better still, include an "INeedFixing" M flag to remind you that you have left something unresolved.

Leaving the code in place means the variables will still come up in the xref (if applicable). Using an M flag for "INeedFixing" will also come up in the xref so you can easily find all your unresolved issues.

Actually, as a rule I usually do jump round code that I'm not wanting to use for some reason (mainly during testing when parts of the equipment don't exist). However, that is just habit, not because I thought it through and this time I got lazy...!

I like your idea of the "INeedFixing" flag though - I'm off to plant three or four flagpoles straight away.

Cheers

Roy

Roy

I don't know if these ideas are an influence here, but here goes ...

a) STEP7 usually only updates the data for the screen once per cycle at the end of OB1. It is quite possible that if a bit is written to more than once in the program you can have ambiguous information. You may be observing a network where all the logic conditions are satisfied and the output is 'true' but not showing as such. This is because later in the cycle the same bit is set 'false' therefore the status at the end of OB1 is 'false' and that is what STEP7 displays.

b) Complex networks do take time to update in STEP7. As far as I know the CPU itself will easily rattle through these combinations up to at least 32 series and parallel connections in ladder (and probably more). However because the default comms time is limited as a perecentage of the overall cycle, STEP7 may not have time to update an entire network with all the required data. You can adjust the amount of time permitted for comms. I can't remember the STEP7 menu (I'm not at a PC with STEP7 at present) but it's something to do with switching between 'Process' operation and 'Test' operation. 'Test' allows you to set a higher comms time per cycle. Check the Help file for these.

c) I don't know where your code resides, but if it's in a re-used FB how do you know which instance is being used to update the data? You need to specify the full monitoring path to include the data from the correct Instance Data Block, otherwise the display can not be trusted. I know from experience!

Regards

Ken.

I use

A "INeedFixing"
= "INeedFixing"
JU Past

Do not rely on the state of "INeedFixing", you can then then use it as an output parameter from a block as well.

A "INeedFixing"
= "INeedFixing"
JU Past

Click to expand...

Thanks, Simon. That's exactly how I decided to implement it - just finished going through and marking all the places where there is still work to do.

Ken,

a) STEP7 usually only updates the data for the screen once per cycle at the end of OB1. It is quite possible that if a bit is written to more than once in the program you can have ambiguous information. You may be observing a network where all the logic conditions are satisfied and the output is 'true' but not showing as such. This is because later in the cycle the same bit is set 'false' therefore the status at the end of OB1 is 'false' and that is what STEP7 displays.

Click to expand...

It's a while since I had this problem and since I was a lot less experienced at that time, this may well have been the source of the problem.

b) Complex networks do take time to update in STEP7. ... You can adjust the amount of time permitted for comms. I can't remember the STEP7 menu (I'm not at a PC with STEP7 at present) but it's something to do with switching between 'Process' operation and 'Test' operation. 'Test' allows you to set a higher comms time per cycle.

Click to expand...

In my more complex networks the View display usually stops updating after 10% - 20% of the network. I'd never really thought about why, just accepted it as a fact of life. I know about the "Test" Menu, so I'll have a look at increasing the permitted comms time when I'm back on site next week.

c) I don't know where your code resides, but if it's in a re-used FB how do you know which instance is being used to update the data? You need to specify the full monitoring path to include the data from the correct Instance Data Block, otherwise the display can not be trusted. I know from experience!

Click to expand...

Having been bitten by this one a few times, I'm now careful. Because of the layout of my system with its 21 functionally identical modules I have quite a few cases where I have an FB/FC pair - a calling FB (usually) where the called FB/FC is called for each module and the called FB/FC with the actual program. During testing I've only ever had one module available up to now so in the calling FBs I jump over all the other non-existant module calls. This allows me to examine the called FB/FC in peace, knowing that it is actually only being called one time.

Actually in most cases I don't even need to modify the calling FB, because the called FB/FC is only executed if the Module is selected. Since I've got an interlock which prevents modules which are not physically present from being selected in the first place, up to now there has been no problem. I'll have to be a bit more careful from now on though!

Thanks for the input guys.

Cheers

Roy

SimonGoldsworthy said:

I use

A "INeedFixing"
= "INeedFixing"
JU Past

Do not rely on the state of "INeedFixing", you can then then use it as an output parameter from a block as well.

Click to expand...

Hi Simon!

Didn't someone in the department call these "I_need_shooting" once?