representing analog data in STEP 7

The Siemens documentation for FC105 states that for a BIPOLAR input, the range is assumed to lie in the range +/-27648. If the input lies outside of this range, the output is clamped and an error is returned. This is explains your results when using FC105 and a 16-bit analogue input card and why a home brewed scaling routine would be required.

What a number of replies in thread! Cheers guys. I know that many of you are gurus when it comes to delaing with this kind of problems. However I thpught that PIW xxx is the only way to address analog inputs. In my PLC configuration I have one DI 16x, D= 16x and AI bx12bit module. When I placed that in hardware config editor, I got address for AI module from 288 to 303. I've read somwhere that analog inputs are in format PIW xxx and that Step 7 is interpreted them as integers between 0 and 27648, so naturaly I've used PIW288 address for first channel on the module. Now reading this, it seems that this channel can be also addresed as IW288, I didn't check it, but I will tomorow. Where can I lear a little mora about this? For example when to use IW and when to use PIW? Would it be OK to every question I have place in this forum? I know that some questions will seem stupid to you but... I didn't have any training with Siemens equipment, so basicaly many of things I know, I've learned on my own.
Thank you all much for help and I'm glad that there are a lot of people here who wants to help.

Pandiani,

An analog input can only be accesed as IW xxx if the adressing in within the range of the proces image tabele : f.i. for a 315cpu 0-124. Higher adresses always have to be accessed as PIW xxx, even if it shoul concern a digital input card.

That's not what happened Simon .

It is nothing to do with over or under range in this case .
How would you state that the PIW for a 16 bit analogue card be decalred in the symbol table ? as INT or WORD ? , or don't declare it at all ?

SimonGoldsworthy said:

The Siemens documentation for FC105 states that for a BIPOLAR input, the range is assumed to lie in the range +/-27648. If the input lies outside of this range, the output is clamped and an error is returned. This is explains your results when using FC105 and a 16-bit analogue input card and why a home brewed scaling routine would be required.

Click to expand...

I dont get this.
All analog input cards have rated ranges of -27648 .. 0 .. +27648.
It does not explain why a homegrown scaling function works differently than FC105. I believe that FC105 uses REALs for its scaling math, so I cannot see where the error could have crept in.
It should be possible to test this behavior if 10baseT could inform how the error appears.

I am guessing that the homegrown scaling function is made completely with STL. Thats why it could be made even with an input declared as WORD in stead of INT. There is no typechecking in STL as opposed to in LAD or FBD.

I am convinced that the CPU doesnt care what type a variable is declared as in STEP7. Try to upload a program from the CPU, there will be no types.
The types are only used by STEP7 to test that no grave errors are made by the programmer. You can turn type checking off completely, but I prefer to have it on.

I think (think) that this is one of the areas where Siemens expect you to use IEC61131 conventions, but then don't always obey them themselves.

In IEC-talk, if you have a 16-bit variable and expect it to contain a numeric value on which you will carry out arithmetic operations, then that by definition is an INT. On the other hand if your 16-bit variable is a bit pattern and you expect to carry out logic operations on it (WAND, WOR etc) then by definition it is a WORD. Once you have declared a variable type you should be restricted on the operations you can perform on it. If you do want to perform both types of operation then the appropriate type conversion operations have to be used first.

Of course, Siemens statement list is quite happy to ignore this requirement and let you add WORDs or bit-mask INTs. And you can switch off type-checking altogether in STEP7 if you wish.

But I can't help agreeing with Simon in thinking the likely differences in 10baseT's symptoms come from different coding rather than different datatypes.

Regards

Ken

Having been a bit naughty and peaked inside FC105 , there is very little difference between this and the homegrown , the homegrown incorporates a low pass filter , but this is switched off and passes through , the rest of the maths is identical . The only differences being the FC105 only accept PIW's declared as INT's whereas the homegrown allows WORD declarations - it hadn't crossed my mind on site to play , the job was running , and two decimal places seemed enough , I am just digging out a couple of cards now though and will try the same simulation .

Any chance you could post the homegrown scaling block ?

Plc_User said:

Pandiani,

An analog input can only be accesed as IW xxx if the adressing in within the range of the proces image tabele : f.i. for a 315cpu 0-124. Higher adresses always have to be accessed as PIW xxx, even if it shoul concern a digital input card.

Click to expand...

It's clearer to me now. After I have placet AI card on rack in Hwdconfig, Step7 set addresses from 288 to 303, so because it is grater than 124 (for 315-2 DP) I need to use PIW 288

Thanks very much

an easy way of scaling analogue value

//READ PHYSICAL VALUE,CONVERT TO REAL VALUE

L #PIW
ITD
DTR
T #PIW_REAL

//CONVERT TO PERCENTAGE VALUE FOR VISUALISATION IN OP PANEL

L #PIW_REAL
L 2.746800e+002
/R
T #DISPLAY_REAL_P

//CONVERT TO KG

//OFFSET + RATE CALCULATION DEPENDS UPON THE LEVEL PERCENTAGE.IF THE ANALOGUE
INPUT VALUE IS MORE THAN MIN LEVEL PERCENTAGE IT OMITS THE MIN LEVEL OFFSET FOR
BETTER ACCURACY & IF THE INPUT VALUE IS LESS THAN MIN LEVEL PERCENTAGE IT ADDS
THE MIN LEVEL OFFSET FOR CORRECT EVALUATION
*********THIS PROGRAM APPLICABLE IN LEVEL MEASUREMENT ONLY WITH THE TRANSMITTER
PLACED ABOVE LOW LEVEL FOR HYGENIC REASON IN CONICAL TANKS*********************


L #MIN_LEVEL
L #MAX_LEVEL
/R
L 1.000000e+002
*R
T #COMPARE_MIN
L #DISPLAY_REAL_P
L #COMPARE_MIN
>R
JC ggg1
L #DISPLAY_REAL_P
L 1.000000e+002
/R
L #MAX_LEVEL
*R
L #MIN_LEVEL
+R
T #DISPLAY_REAL_KG
JU ggg2
ggg1: NOP 0
L #DISPLAY_REAL_P
L 1.000000e+002
/R
L #MAX_LEVEL
*R
T #DISPLAY_REAL_KG
ggg2: NOP 0


//OUT OF RANGE ALARM


L #PIW_REAL
L 2.846800e+004 //27468+1000.HIGHER RANGE
>=R
O(
TAK
L -5.000000e+002 //0-500.LOWER RANGE
<=R
)
= #Xmitter_out_of_range