The function basically checks to see if the analog input is within range (4 to 20mA), and if not sets an alarm bit (after a time period). The alarm bits, scaled analog values, and fail-timer accumalated values being stored in datablocks (these all available to LOI - as status).
This function block is called for all analog inputs, from another function block.
Yet the results obtained during testing showed that for different inputs, the time taken for the alarms to be raised differed. Some alarms were generated instantly, others after the fail-timer had expired, and one alarmed usually after a time had expired, but sometimes instantly...
I don't think there is a problem with the code. So I would like to know if anyone else has had quirky problems relating to datablock usage, or timer usage.
I've also noticed previous problems where simple timer code did not appear to work (a password log-in time remaining status), but then later started to work (the only thing that had changed, was that a couple more timers had been used in other bits of the code).
Therefore, do you have to configure/increase memory areas (add timers, or increase the length of used datablocks), in order for the code to work correctly???
Please tell me I am not crazy...
What kind of timers are you using and are they unique T numbers? Each timer has to have a unique T number. Are you calling the function multiple times and passing a unique timer number into it, which would work, or using the same timer inside the call, which wouldn't work as the first call would start the timer.
As a standard I use the following code for range and scale functions of an analog input.
L PIW 512
T "Analog data".PIW512_RAW_DATA
L "Analog data".PIW512_RAW_DATA
_001: A BR
_002: A BR
T "Analog data".Xformer_phase_a_temp
_003: NOP 0
The code may appear to be a little over complicated however this is as a result of the use of CSF to display the segment.
The following code is used to check for under range :
L "Analog data".PIW512_RAW_DATA
= L 10.0
A L 10.0
= "Analog data".PIW512_ANAL_FAIL
A L 10.0
T "Analog data".Xformer_phase_a_temp
_004: NOP 0
On April 27, 2003, Dave wrote:
> I have a S7 CPU315-2DP (with a OP270 LOI/HMI attached). I wrote a function
> block to scale an analog input to engineering units (incorporating FC105).
I have no idea what FC105 is, nor an OP270, obviously you are under the impression that the former is some form of standard block, I have not heard of it before and it doesn't appear in any of my standard block libraries. Your OP270 is presumably either MP270 or OP27, I am not sure what this has to do with your analog input problem.
> The function basically checks to see if the analog input is within range
> (4 to 20mA), and if not sets an alarm bit (after a time period). The alarm
> bits, scaled analog values, and fail-timer accumalated values being stored
> in datablocks (these all available to LOI - as status).
The over/under range check on the analog inputs should take care of this provided you have set your hardware as 4 - 20 ma inputs and not 0 - 20 or +/- 20.
> The problem:
> This function block is called for all analog inputs, from another function
> Yet the results obtained during testing showed that for different inputs,
> the time taken for the alarms to be raised differed. Some alarms were
> generated instantly, others after the fail-timer had expired, and one
> alarmed usually after a time had expired, but sometimes instantly...
Is it called as a multiple instance block, in which case it is unlikely there are any memory areas overlapping, or is it called again and again using the same datablock each time?
> I don't think there is a problem with the code. So I would like to know
> if anyone else has had quirky problems relating to datablock usage, or
> timer usage.
I don't for one second doubt there is a problem with the code, after about 7 or 8 years of living eating and sleeping with S7 I have found it to be rather more free from quirks than my wildest dreams.
> I've also noticed previous problems where simple timer code did not appear
> to work (a password log-in time remaining status), but then later started
> to work (the only thing that had changed, was that a couple more timers
> had been used in other bits of the code).
Timers generally exhibit this form of behavior when they are being used several times for different functions, a timer can only work effectively if it is started once only for one purpose only in the S7 program, and with the amount of timers available in S7 you would be in need of a
serious strategy re-think if you are running out of them.
> Therefore, do you have to configure/increase memory areas (add timers, or
> increase the length of used datablocks), in order for the code to work
Data blocks are set up to contain exactly whatever you require, up to 15600 bytes long, and every byte and its format must be defined in the declaration of the datablock.
It is extremely beneficial in S7 to use correctly documented FB's and DB's in that if you give symbolic names to everything, then you should see the symbols and never the absolute addresses when you are editing the code, as soon as something doesn't translate into a symbol, then it is clear that the addressing is wrong.
> Please tell me I am not crazy...
Difficult to do at this distance.
maybe the error is in the code that fires the timer. I have found that STEP7 get strange results from code that looks OK when using timers.
Doing the same thing a little differently solved the problem without me knowing exactly what was wrong.
Give an example of your code so that we can help you better.
Donald, the OP270 is the replacement for the OP27 and OP37. I use OP270-10 (10 inch screen) and it is good and very reasonably priced.
I agree on possibility of error in user code and I have some difficulty to accept that S7 timers give strange results. It's probabily just a matter of how the timer instructions are used, but I'm interested on possible weird behaviour. Would you mind to provide some sample code?
Just a few comments on some of the above questions and comments.
Firstly, Donald on a point of information:
FC 105 does not seem to appear in the new Version 5.2 of S7. FC 105 and 106 used to appear in the IEC standard functions library and were scale and unscale respectively.
I don't know why they do not appear any more. When you create your own function library you can just copy these in from previous projects or older versions of S7. Not saying that you need to as scaling isn't the hardest thing in the world any way......
One thing that I have found is if you are making multiple calls of a multiple instance created as an FC with TEMP variables you are asking for trouble. The best thing is to create this in an FB using STAT's in place of TEMP's.
Create your FB with the code, then open another FB, in the header under STAT call the first FB.
This then gives you multiple FB's called with only one multiple instance DB.
If this this sounds like an insult to your programming inteligence, I appolagise. I can't be sure from you question!
Also if the program is time critical you can always put each of these calls in OB 35, a cyclic OB with a set cycle time (you an set this in the hardware profile).
Hope some of this helps.
Just a slight correction:
FC105/106 (Scale/Unscale) appear in the "TI-S7 Converting Blocks" library of Step 7.
The Biggest problem you are facing is that you are producing alarams through the FC105 thing.
And you get different times. the problem seems to be not with timers it is the problem with the scan time of OB1.
so make you CPU online a chack the scan time at dirreent instance you will find it different every timer you refresh it.
To over come this problem Use OB30 to OB38 scan time cycle interrupt OBs.
i.e. if you call the FC of Scaling in OB35 all the alaram will be scanned before 100ms.
and you will get the thing done.
Secondly one of friends said that FC105/106 have moved from IEC blocks. Yes they have moved and now they are in the TI-S7 conversion blocks.