Strange S7 problem on FC82, 83 and 84

uptown47

Lifetime Supporting Member
Join Date
Feb 2008
Location
Over there, next to those boxes
Posts
1,146
Hi all,

I'm in the middle of doing an S5 to S7 upgrade. The old S5 software used FB241 (convert binary to BCD), FB 242 (multiply 2 binary numbers) and FB 243 (divide 2 binary numbers).

I've replaced these in the S7 code with FC82,83 and 84 as these are direct replacements for these blocks.

When I've come to test the installation I had some strange behaviour. The old S5 code was using a selection of markers between MW 244 and MW 254. It seems that FC82, 83 and 84 also use fixed address words between these 2 addresses?

When I looked in the 'reference' table at MW 244 it is being addressed by these blocks but my software is also writing to the 'bits' of the word. I moved most of the 'bits' to other words and then the machine started behaving a little but it still isn't working correctly.

I'm missing M237.2 which isn't written to anywhere in the software and therefore I can only assume it is derived from MW236 which is shown as being used in FC82 but FC82 is a 'locked' block so I can't get into it.

I thought the 'locked' blocks only used local data so as to not interfere with any other code??

I've attached my archived program and would be really interested in someone else's more informed opinion of where M237.2 is coming from. The S5 rig was a 115U with no HMI attached (just an old fashioned Wohale Text Display).

Many thanks for any help you can give me on this as it's driving me up the wall!

Cheers

;-))
 
I'm a bit surprised at the original (OCME?) S5 programmers' use of scratchpad flags.......
 
Thanks for the unlocked blocks.

I'm still not clear on whether or not FB241 (the S5 equivalent of FC82) uses F237.2 the same way that FC82 uses M237.2 ??

If it doesn't then I'm stuck as to how M237.2 is being brought on. It's used to increment a counter in the software (C4) and this is the nub of my problem.

If FB241 does use the same flag/markers as FC82 then why does the software not work straight out off the bat. I've had to move all the 'bits' between MW244 and MW254 to get it to work because the marker 'words' are seemingly being used within FC82,83 and 84 and therefore the 'bits' are being overwritten.

This would suggest that in the original S5 software FB241,242,and 243 didn't utilise these words (i.e. FW244 - FW254).

However, if they didn't use these FW's then how did F237.2 ever get brought on ??

Kirk, could you also explain what you meant by "I'm a bit surprised at the original programmers use of scratchpad flags" ? Are these the flags around F255 ??

Many thanks

;-)
 

not me ...I'm Kevin :)

Scratchpad flags in S5 are FB200 to FB255.
Siemens used this range of flags as temporary memory in some of their pre-written functions and they were also traditionally used by programmers for the same purpose so I was a bit surprised to see your program using them with 'unique' functionality.

I'm getting a feeling of deja-vu here uptown.
 
Apologies Kevin,

Christ! You've got a good memory. I'd forgotten all about that. Thanks for the heads up re: scratchpad flags (again!).

I've done a cross reference on the blocks that LD uploaded and I'll make sure that none of the programs original markers conflict with the markers used by FC82,83,84 tomorrow when I get back to work.

I'm still confused regarding M237.2. The only thing I can think of is that it's being brought on 'indirectly'. I can't see anything bringing it on in the program though?

Thanks for all your help Kevin and sorry for my repeat question ;-))
 
FC82 was written to mimic the exact functionality of FB241, so if FB241 used flags, so does FC82. Imagine the remote possibility that someone called FB241 and then used the flags as processed by FB241 to perform some other processing......
By coding FC82 like this, it will behave the same when translated to S7

I would expect to find some code in the Step5 project that copies the flags to a DB (probably using indirect addressing) and then copies them back again.
 
Last edited:
By coding FC82 like this, it will behave the same when translated to S7

The only problem with that though is that the code didn't work at all until I moved most of the 'duplicated' marker bits away from the words.

So, for instance, M252.0, M252.1 and all of MB253 are used to communicate with the Wohale (Anka) text display. The display wasn't responding at all because MW252 was being used by either FC82,83 or 84. I 'rewired' the 'bits' away from MW252 and the text display sprang into life and started communicating??

I would have guessed that either the FC's weren't exact duplicates of the S5 FB's or the behaviour of the S5 115U with regards to using Flag words and flag bits together is slightly different to the S7-314 ??

Or... there's maybe another reason that's beyond my knowledge and understanding...?

Certainly very confusing, any ideas on how this could be?

Many thanks for your continued help.

:)
 
Is the source code in the project you have posted the complete translation of the S5 code? - I don't see a call to FC82 in there.
 
There is code performing indirect access to the M area, here's one example writing M228.0 ( I forced the call to FB104 to get this monitored shot). The M address is specified in DB10 at DBW300 using the data in the project.

fb104.jpg
 
Last edited:
Is the source code in the project you have posted the complete translation of the S5 code? - I don't see a call to FC82 in there.

No, that's not the full source code. FC82 is called from FB100 and FB105 (from memory). FC83 and FC84 are called 12 times each and all from the same block. I think it's FB93 (again, from memory - it might be FB99).

I've double-checked these with the original S5 code and they are passing and receiving the correct addresses.

FC100 does the bulk of the complex stuff. It decides whether the machine is in Manual, Auto or 'Diagnostic' and calls a block dependant on this state.

If you do a search for C4 you'll see that it need M237.2 to increment it. This is my issue. If I increment the counter in the variable table then I can get the program number to change on the text display. This was when I found that M237.2 was being used as MW236 via the FC82 and that's what confused me. Whether this was correct or not ??
 
M237.2 is also declared in DB10 at DBW432 so it is highly likely that under certain conditions this flag will be modified. To back track you could put some trap code in FB104 etc. and test for AR1=p#237.2 at the end of the block and stop the plc if this is the case. You would then have to work backwards....

You did say you were half way through this conversion - maybe more like one tenth :)

db10.jpg
 
LD,

I thought I'd finished the conversion until today!!

That's good news though. If M237.2 is being set indirectly that means it's nothing to do with FC82,83,84 and therefore I can separate all the other bits from these FC's.

I'll have to dig into the code tomorrow as you suggest and track what's setting M237.2. If it's being set indirectly then I'm sure it'll be something on the text display but I've no idea what.

Thanks again for all your and Kevins help.

Very much appreciated.

I'll post back with either further questions tomorrow or the (hopefully) successful conclusion...

Cheers :sick:
 
A former collegue of mine was monitoring the Step5 'Force Variables' and stated that a flag that is 0 is free for me to use, basta!'. Perhaps he progged your S5?:D

Kalle

Quite possibly!! :ROFLMAO:

Right, I've got it sussed now thanks to everyone here. I copied the blocks that LD uploaded into the project and 'rewired' them to spare addresses (that way I'm not trying to rewire lots of existing code and having to wade through lots of indirect addressing etc).

This has seemed to work and everything is now back on track.

A massive thank you to everyone concerned for their help.

Cheers

(y)
 

Similar Topics

We have an OPC server getting data from a Compactlogix PLC. The PLC also communicates with a Panelview and a couple VFDs via Ethernet/IP...
Replies
3
Views
1,163
I had a customer call about a machine counter not working. We checked hardware, determined the input was correctly functioning. In tracing...
Replies
9
Views
2,712
Hi Friends, I have a strange situation at hand. I wrote a Logic for Tank Over fill (5 Tanks). When Level switch senses level, it triggers Alarm...
Replies
10
Views
2,863
I have 3 identical CompactLogix L33ER's running in a factory and have always sent out automatic emails successfully. However, our company now has...
Replies
14
Views
6,058
Hi guys, So I added a routine in a L71, and as is my nature, I selected all of the rungs and pasted them into Notepad++ and then re-imported them...
Replies
9
Views
3,718
Back
Top Bottom