RMA
Member
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.
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.
Last edited: