Step7 - Strange goings on!

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
First off, apologies for forgetting to switch to English before making the screen dumps! For those (few) who don't know:

U = A
SPB = JC

Basically I've got three curiosities here: data Bits not changing in the STA column in View, RLOs being set incorrectly and Data Bits being displayed incorrectly in a VAT (at least according to the logic of the program). I strongly suspect that those last two are linked somehow.

We've got a statistics PC which records all the error messages coming from the production line. Unfortunately a lot of the messages are in correct, so I wanted to write a short program to increment through the 4 Bytes of error Bits for each station at 2 second intervals, so that we could get a complete list of the error messages held in the PC. The program is called at the end of OB1 and Bit M777.7 is used to signal whether to run the test or just exit and M777.6 is used as a First-Time-through indicator.

In the first screen dump, everything looks normal - M777.7 is "0" and M777.6 gets reset (apparently) and the jump to "exit" is executed.

AMS_Fault_A.JPG


In the second picture, M777.7 is set to "1", but in the STA column, the value is still shown as "0". However the RLO for the UN query has correctly changed to "0" and the jump is not executed. Unfortunately though, although M777.6 has not been set in the program and #Meldung_Start has not been preloaded with "90" for the start of the Message area, the RLO for the SPB - Jump command has been set and the program continues from "next". This is almost certainly connected with the fact that in the VAT M777.6 is shown as being set!

AMS_Fault_B.JPG


Just for the record, I'm well aware that Step7 doesn't always display single passes through a code block, but in this case I'm relying on the fact that #Meldung_Start is still "0" to concluded that M777.6 should still be FALSE.

AMS_Fault_C.jpg


The memory Bytes 776 - 777 are definitely not being used elsewhere in the program - apart from the fact that I've double checked for overlapping access in X-Ref, before I wrote this code the highest used Memory Byte was somewhere around MB350.

Anybody got any idea what's going on - either with the curious displaying of data or where I've gone wrong in the program, in case I've got to the stage of not being able to see the wood for the trees!


Oh, by the way, the BEA near the bottom of the screen got added after the CPU went into STOP first time round, so that I could examine what was going on, in peace - I didn't want to risk forgetting to remove OB121 again!
 
I did wonder about that Simon and had considered putting a CLR at the start of the program, to see if it made any difference. Since it is being called directly out of OB1 I would have hoped everything should be clean though.

I'll give it a try, just in case.

Cheers
Roy
 
I stuck a "CLR" in at the start of the program, but apart from changing the incoming RLO to FALSE, nothing else changed. In the meantime, I've also tried it out on another CPU where I also changed the MB_Meldung_Nr counter Byte to MB774 instead of MB776.

Once again, no change.
 
I can't see all of the code but my guess is you have an infinite loop as you load MB776, increment the value and compare with 48, but you don't appear to store the incremented value back in MB776.
Concerning the RLO/STA display, I can't replicate the effect you see yet - all that is required to test it is as below I think ?
(There is no more indirect addressing of MB's anywhere else is there ?)

Code:
	  AN	M	999.7
	  R	 M	999.6
	  JC	exit
	  S	 M	999.6
exit: NOP   0
 
Last edited:
I think I store the value back to M776 after the BEA that I put in so that I could check the data in peace. Unfortunately, the Internet PC is not my Step7 PC so I'll have to check that out and get back. I could also post the FC as source code, if you want.
 
RMA, it looks really very strange. Especially second occurence of VKE and STA. In your place, I'l try to connect "in parallel" (it means processed in same manner) with M777.7 and M777.6 two another bits for which you are 100% sure it not in use. Compare behavior of original and debug bits. Maybe situation will be more clear.
 
Hi Gambrinus,

in this case I really am 100% certain that according to the X-Ref list, the Bytes were not being used. Having said that, I have had occasions on which the X-Ref data was incorrect, however, I've never been able to see any connection between such cases. I'll try a couple of Bytes up in the MB2000 region.

Cheers

Roy
 
I didn't think about incorrect X-ref. But I see indirect addressing in your code. Sometimes, if something wrong, it can produce very "interesting" results. If you create new flags in never used area (better in new DB), it'l be guarantee in this case.
 
Roy, can you try sticking in a trap right after the jump? It should be somethng that doesn't affect the code in any way, i.e.

Code:
AN	M	777.7
R	 M	777.6
SPB	exit
  
A M777.7
A M777.6
= #TestTempBit

I assume this is a screen update issue. That said, I know there is one issue with some Siemens firmware versions where some jumps are not executed even though they logically should, but it depends on the instruction after the jump (I know that makes no sense, but there is a Siemens bulletin out ther for it). I saw this myself. In my case, instead of updating the firmware, I stuck a "NOP 0" after the jump and I never had another problem. That's something you could try in case you find the jump really isn't working.
 
Thanks S7Guy - if that's not a typical Siemens weirdo, then I don't knolw what is!

I'll give it a try and get back.

Cheers

Roy

Edit: Won't be back today though, the PC I can use for Internet access is about to be locked away!
 
Last edited:
Note that you could always load the status word (L STW) into the accumulator to cross check the RLO display against the accumulator display. (FC, STA and OR bits are not loaded in a 300 range CPU)
 
S7Guy - is this the Siemens update you are referring to ? I couldn't find any others.

cs1.gif
Concerns the product with Catalog No.: 6ES7 318-2AJ00-0AB0 CPU 318-2, 512 kB, 0.1ms/Kstatem. Reason for the change: ---------------------- A jump operation or a block call will NOT be executed by the above CPU even if the jump or call conditions are fulfilled, if the subsequent operation is a load or transfer operation with the I/O operand area (direct I/O access) AND the PG function "Status Block" is used to monitor these operations. This applies to indirect addressing as well. Example:

...
JC end
L PEW100 ...
end: ...

This problem will not occur during normal operation without "Status Block". Upgrading: ---------- Upgrading is only necessary for the CPU 318-2 with revision level 03, firmware version 1.1.0, because the above problem only occurs here. A free firmware update together with instructions are available under downloads here on the S7-300 homepage under the entry ID 1321078. Your SIMATIC contact at your local Siemens office will answer any further questions you may have.
 
That is similar to what I saw, except it was on a 416-2DP and it happened whether I was online or not. In fact, I noticed it because the machine was acting kind of strange. When I called Siemens, they told me it was impossible (typical) because it was only happened on the processor you described. Anyway, all it took was putting a NOP 0 after the jump, and it has been fine ever since.

I think it's a long shot in Roy's case since he is not loading a peripheral word, but thought I'd through it out there anyway because I've seen it in a processor that Siemens claims it will not happen in.
 
Oops - sorry guys, problem solved

I found the problem less than half an hour after my last post yesterday, but the laptop was already locked away.

The problem was that I was trying to use #Meldung_Start in successive cycles - don't know what got into me there, it's years since I made that mistake!

This is probably a good example of the worst aspect of the occasional problems with the Siemens screen update in "View" mode. After a while you start to assume the situation is due to screen update problems, instead of looking for the programming fault!

Hope I haven't wasted to much time, still, at least we now know about the other jump problem, which may come in useful some time in the future.

Cheers

Roy
 

Similar Topics

Hello guys, I have another, very weird problem with Step 7 functions. In the attachments, you can find sorces for OB1 and two functions. Both...
Replies
9
Views
3,443
I've got a production line station which has two Cognex cameras in it to check that components are present and correctly orientated. The second...
Replies
7
Views
3,951
Hi, i am in the progress of familiarising myself with my new 315-2PN/DP. It is going extremely well, almost too well. Siemens manuals explain...
Replies
12
Views
6,434
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
74
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
504
Back
Top Bottom