Step7 - data getting lost on the way to a DB!

I've got a bit of a weird problem here, so I'd appreciate it if anybody has any thoughts on what's going on.

I'm looking into sporadic problems in a hot strip rolling mill where occasionally the walking beam transport system fails to cleanly pick up the billet in the oven to tranport it to the roller conveyor line. Using a VAT I've already found some areas where data is being incorrectly handled, but since much of the operation is edge triggered and only runs for a single cycle I decided to build myself a ring buffer to save the relevant data each time. This is something I've used successfully in the past, though never with so much data, 120 Bytes in this case.

In principal it seems to work OK and I can't find any faults, but some data is not being saved correctly. In some cases the data is never being written (or is being written as zero) and in other cases, as with the TIME_OF_DAY and DATE they are sporadically saved as zero (3 - 4 times in 80 sets of data). I can't rule out that in the odd case I may have timing problems resulting in some data not being available during the actual cycle when FC1 is active, but there are some situations where this is definitely not the case.

At the start of FC1 I check the Marker Bits M505.0, M505.1 and M505.2 to see if the program for calculating the target position for the walking beam transporter is active. One, and only one, of these Bits must be set, otherwise the program exits. These control Bits, generated at the start of FB505 are only active for one cycle. In order for these Bits to be set certain other Bits must be set - M371.5 or M372.4, for example. These Bits, in turn, require that (amongst other things) one of the Inputs I56.2 or I56.4 be set. This all happens very early in FB505. The state of the control bits M505.0 - 2 is being recorded correctly but the other Marker Bits and the two Inputs are always zero - over 80 sets of data so far!

Another oddity is the data for the billet width and length. This data is picked up from DB963 and DB973 as INTs, saved in DB508, then converted to REALs which are also stored in DB508 to be used for the subsequent calculations. This happens shortly after the control Bits have been evaluated early in FB505. Over all 80 data sets the INT values from DB508.DBW112 - 118 are Zero, but the REALs in DB508.DBD60 - 72 are mostly present, once again with a few sporadic zero's thrown in for good measure.

The CPU is a 416 - 2 DP, first time I've used a 400, but I can't imagine that can have anything to do with the problem.

I'll append the source files (renamed to *.txt) to this post - FB505, FC1 and UDT9, I won't bother with DB499 as it's simply 256 sets of UDT9 or the other DBs, although if somebody feels they could be useful, I can add them later, but they are all pre-existing, unmodified blocks.

I'd be grateful if anybody has any suggestions, I think I may have got to the stage where I'm seeing what I expect to see instead of what's really there!

Cheers

Roy

Edit: I don't have access to the PC on this system (just screen and keyboard/mouse) so I couldn't dump the source to my USB-Stick. As a result, I can't rule out the possibility of the odd typo having found its way into FC1 or UDT9.

RMA said:

One, and only one, of these Bits must be set, otherwise the program exits.

Click to expand...

I haven't looked at the rest of the code, but this doesn't work the way you describe. It will only exit of all three bits are false. If one, two, or three of the bits are true, then it will run. Is this ok? Mayybe it doesn't matter, but it could cause problems if you expected it to work differently.

Sorry, S7Guy, I phrased that poorly. Ultimately the three Marker Bits are set by the operator choosing one of the conditions and he can only choose one. The "one and only one" reflects this external situation not some programming which is not visible here. If none of the bits is set then we are still waiting for the billet to reach temperature, so FC1 exits.

Hope that makes things a bit clearer!

Roy, to test FC1 I modified it so that it ran all the time and each load from DB963 et al was replaced with a load of the current ring buffer count (and converted to the correct data type). DB499 thus ended up with data in it corresponding to the array element number. I then created FC11 from FC1 which read the data from DB499 and compared it with the ring buffer count and no differences were found.

How confident are you that DB499 data is not being overwritten from outside of FC1 ?

My suggestion is to create DB999 (or any other as yet unused DB) as a copy of DB499 and then in FC1 write to DB999 as well as DB499 - then see what happens.

Regards, Simon

Hi Simon, thanks for having a look. Unfortunately I don't have PLCSim available here. I tried the Demo Version of Trysim, but couldn't get it to run properly at all, so I finished up taking a deep breath and jumping in feet first. The thought of possibly bringing a hot strip mill to a grinding halt isn't exactly good for the nerves!

I don't think it's likely that something else is overwriting DB499, because when I first started chasing this problem, I checked the diagnostic buffer and there were no errors before I created DB499. The steelworks have a "no indirect addressing" rule, which, I've already discovered, isn't always observed, but so far I haven't found any in this particular project.

Just a bit more explanation what this is all about. The oven can hold billets up to about 13 m long. It's 30 m deep so, depending on how wide the billets are, there can be about 20-odd billets making their way through the oven at any given time. Mostly they work with long billets, but they can also handle two short billets under 6m. The problem as they explained it to me was that when the first billet (can't remember offhand whether that is Säule 7 or Säule 8) is wider than the second one, the walking beam occasionally gets sent too far under the second and catches the edge of the next billet behind it (they're only about 10mm apart) and so tries to lift two billets at once, which ain't on!

In the course of trying to figure out what was happening I noticed that the width and length data for Säule 8 (rechts) in DB508.DBW114/116 was not updating. This data comes via Ethernet from another PLC and since there are no writes to the DB963/973.DBW14/16, I initially thought the data may not be coming over correctly, however, later on this afternoon I found the comms DB and discovered where the data is deposited then copied to DB963/973 by a block which takes the target address as an ANY Pointer - hence no writes in X-ref! The same FC is called twice to copy the data to DB963 and then again to copy the other data to DB973 - in this DB the data is correct, so either the copy from DB973 to DB508 in FB505 is being jumped over, or else it is also not writing correctly. Anyway, I've put some SET Marker Bits in each of the paths where the data is transfered to DB508 in FB505, so maybe I'll be a step further on tomorrow.

Thanks for taking the time.

Cheers

Roy

We had two pairs of short billets overnight and my Marker Bits showed that the relevant part of the program which should have executed did not, in fact, run. So I'm slowly making progress on the real problem!

However, I'm still a bit puzzled as to where the Black Hole is, into which my data are disappearing, so I'd be really grateful for any theories - the weirder the better - as to what's happening (if that's not an invitation to Ken ... )!

As another plc is connected, doesn't this have free access to overwrite anything it feels like - there wont be any entries in the diagnostic buffer for this type of write.

Working with multiple PLCs is not something that I do all that often, so I hadn't thought of that aspect. I assumed, though, that since there were no read or write faults in the diagnostic buffer before I created DB499 that nothing should be trying to access it, it hadn't occured to me that they wouldn't show up if coming from another PC. Would they show up in the other PC's Diagnostic Buffer - if so what would they look like?

Any failure to write would have to be dealt with programatically and would not appear in any diagnostic buffer.

That's a pity, would have made life a bit easier!

Just another thought, I've been assuming all along that I can safely use AR1 here without needing to take any precautions - is that a safe assumption, especially if some interrupt driven program doesn't save and restore AR1?

Having said that, I only load AR1 once, right at the beginning and some of the very early Marker Bit transfers never work, while most of the later REALs always get saved OK. I would have thought that if AR1 was getting its knickers in a twist everything thereafter would be screwed up - or am I missing something there?

What about my DB999 idea ? you would have a duplicate DB to compare with DB499.

That's a thought, I'd rather forgotten that suggestion - will give it a try.

OK just tried it out with an additional DB1499 - just the same, but ...

I discovered that for my integer transfers (right at the end of FC1) I cas Transferring to DBDs instead of DBW, so now all the load and transfer commands are OL - it's only the BOOLs that are giving problems.

Could it be that I need to use "S" rather than "=" - don't miss tomorrow's exciting installment!

OK - now tell me why!

Well I changed my assigns (=) to SETs (S) and preloaded DBW6 with 0 to remove any data from the previous trip through the ring buffer and now everything's working fine - and I haven't a clue why!

The only explanation I can think of is that somehow the data is being written on more than one cycle, but I can't for the life of me see why!

Edit: Forgeot to say the original problem is also solved. Always a nice feeling to wander into a plant you've never seen in your life and come out a few days later having fixed a fault that's been plaguing them for years - good for the ego, that is!

Is this what you have done ?


If so, this will execute the same as the original code


so, as you say, something else is still going on.