RMA
Member
For those of you who, like me, have a week's holiday coming up, I've got a nice little problem to keep you from getting too bored!
The Trigger signals for my 21 Capacitor Bank Modules can be delayed by 0 to 2000 mS, these times are either entered by the operator or are pulled up from a recipe DB (the same DB where the operator input lands). Since the Timers in the FM352-5, where this delay is timed count in 10µS increments, the mS value needs to be multiplied by 100 before being used to preset the Timer.
Up till now I did this by multiplying the value as I was transferring it over to the FM, however, this bit me when I had delays of zero. Because the Timers don't actually run if the preset period is zero, I needed to modify the 0 delay to a 10µS delay (preset = 1), however, when this got passed over to the FM, it also got multiplied by 100 giving a delay of 1 mS instead. 10 µS difference is irrelevant, but 1 mS definitely is not!
So I had to change things and modify the operator inputs to cater for the 10µS period before passing the data over to the FM. Doesn't sound very difficult, but for some reason, it doesn't work!
I went chasing the problem with breakpoints and this is what I turned up:
As you can see in AKKU2 we've picked up Module 18 (12 hex) which is the first selected module. The Module select BOOLs are in Bits 0.1 to 2.5 of DB4 (the recipe DB) and AR1 is showing 2.2 which is the correct address for Module 18's select Bit. The VKE Bit is set, indicating the module has been selected. So far, so good, on to the next step:
and this is where things start to get slightly peculiar. The Breakpoint is set immediately after having picked up the delay time (in mS) in this case for Module 18 as an INT in DBW 52 and sure enough, in AKKU2 we've got 1A0 = 416 decimal which divided by 8 (to correct to Pointer Byte.Bit format)= an Offset of 52. Only for reasons best known to itself, AR1 is still showing 2.2! However, in AKKU1, we've got 76 hex = 118 = Module Nr. + 100, which is what I stored in the DB. By the way, I initially stored the Module number itself, but that got a bit confusing, because it was then not too clear which value was in the AKKU. Since this change was visible, I think I can be pretty sure that I'm picking up the correct data.
OK, now on to the last bit, multiply by 100 and store the new value in newly created DINTs at the end of the recipe DB:
Once again we've got our peculiarity, that AR1 is still showing the offset as 2.2, however, in AKKU2 we've got 440 hex = 1088 decimal = Offset 136 when divided by 8, which is the correct address. In AKKU1 we've got 2E18 hex = 11800 decimal so the multicplication's worked OK, but when we go have a look in the VAT table, after refreshing with F7, just to be on the safe side:
down near the bottom of the VAT table, you find DB4.DBD136 with its new contents: 773324800!!!!!
All ideas most welcome! I'm taking the 314 back home with me, so if anybody comes up with some suggestions, I'll be able to try them out!
Cheers
Roy
PS, I forgot to mention the destination DINTs were initially set to zero, and at this point, all the other locations still were 0, so the correct address has been written to, even if the contents are rubbish.
The Trigger signals for my 21 Capacitor Bank Modules can be delayed by 0 to 2000 mS, these times are either entered by the operator or are pulled up from a recipe DB (the same DB where the operator input lands). Since the Timers in the FM352-5, where this delay is timed count in 10µS increments, the mS value needs to be multiplied by 100 before being used to preset the Timer.
Up till now I did this by multiplying the value as I was transferring it over to the FM, however, this bit me when I had delays of zero. Because the Timers don't actually run if the preset period is zero, I needed to modify the 0 delay to a 10µS delay (preset = 1), however, when this got passed over to the FM, it also got multiplied by 100 giving a delay of 1 mS instead. 10 µS difference is irrelevant, but 1 mS definitely is not!
So I had to change things and modify the operator inputs to cater for the 10µS period before passing the data over to the FM. Doesn't sound very difficult, but for some reason, it doesn't work!
I went chasing the problem with breakpoints and this is what I turned up:
As you can see in AKKU2 we've picked up Module 18 (12 hex) which is the first selected module. The Module select BOOLs are in Bits 0.1 to 2.5 of DB4 (the recipe DB) and AR1 is showing 2.2 which is the correct address for Module 18's select Bit. The VKE Bit is set, indicating the module has been selected. So far, so good, on to the next step:
and this is where things start to get slightly peculiar. The Breakpoint is set immediately after having picked up the delay time (in mS) in this case for Module 18 as an INT in DBW 52 and sure enough, in AKKU2 we've got 1A0 = 416 decimal which divided by 8 (to correct to Pointer Byte.Bit format)= an Offset of 52. Only for reasons best known to itself, AR1 is still showing 2.2! However, in AKKU1, we've got 76 hex = 118 = Module Nr. + 100, which is what I stored in the DB. By the way, I initially stored the Module number itself, but that got a bit confusing, because it was then not too clear which value was in the AKKU. Since this change was visible, I think I can be pretty sure that I'm picking up the correct data.
OK, now on to the last bit, multiply by 100 and store the new value in newly created DINTs at the end of the recipe DB:
Once again we've got our peculiarity, that AR1 is still showing the offset as 2.2, however, in AKKU2 we've got 440 hex = 1088 decimal = Offset 136 when divided by 8, which is the correct address. In AKKU1 we've got 2E18 hex = 11800 decimal so the multicplication's worked OK, but when we go have a look in the VAT table, after refreshing with F7, just to be on the safe side:
down near the bottom of the VAT table, you find DB4.DBD136 with its new contents: 773324800!!!!!
All ideas most welcome! I'm taking the 314 back home with me, so if anybody comes up with some suggestions, I'll be able to try them out!
Cheers
Roy
PS, I forgot to mention the destination DINTs were initially set to zero, and at this point, all the other locations still were 0, so the correct address has been written to, even if the contents are rubbish.
Last edited:
