representing analog data in STEP 7

Ken - For the smaller CPU's, the maximum addres will be 255 for the I/O process image - all access to addresses above 255 has to be with PIWxxx. I think you need to go to the 400 range for a larger process image.

SimonGoldsworthy said:

CHANGE THE SYMBOL TABLE ENTRY TO INT ! FC105 must be supplied with an integer variable.

Click to expand...

If you want a symbol for your PIW address, it must be of type int if you want to pass it to FC105. End of story.

Paul - does this clarify things ?

The type in the symbol table is used by the block editor to check the variable you are entering is a valid one, so when creating new code, you may or may not enter the PIW address depending and the type of symbol table entry.
However, once you have entered a valid address and saved the block, you can change the type in the symbol table and it will have no 'effect' as the address is now stored in the block (where it's type doesn't matter, it's just a valid address)

For my project CPU is 315-2 DP, and my application is not very time dependant. Anyway, my program works and I used addresses for analog inputs and outputs directly (PIW288, PIW290 etc.) without entering these addresses in symbol table. I tried to eneter address first in symbol table, change its type to INT and it also worked (in that case I could work with symbolic names in program).
Wow, Simon, Ken, Paul thank you all so much for your time and effort. I think I'm going to learn a lot by sticking to this forum and to you guys.

SimonGoldsworthy said:

The type in the symbol table is used by the block editor to check the variable you are entering is a valid one, so when creating new code, you may or may not enter the PIW address depending and the type of symbol table entry.
However, once you have entered a valid address and saved the block, you can change the type in the symbol table and it will have no 'effect' as the address is now stored in the block (where it's type doesn't matter, it's just a valid address)

Click to expand...

Thank you Simon, I think that clarifys things. This is something I have not come across before.

Did you get that snippet of information from one Mr Berger or from the help files?

Paul

Adressing analog inputs at the process image table

Concerning the adressing of analog inputs : if the process image of the cpu is not yet completely used by digital inputs, why are analog inputs then not adressed at an adress that is in the proces image, since with recent cpu's adressing of the IO-cards is configurable. This would decrease the load because adressing peripherical IO (PIW) uses more time then adressing the proces image table. I checked it out and for instance an analog value at adress IW100 can be read out without problems. Of course I suggest that the reading of the analog values is not time-critical since the process image is only updated once in a scan cycle.

PLucas said:

Thank you Simon, I think that clarifys things. This is something I have not come across before.

Did you get that snippet of information from one Mr Berger or from the help files?

Paul

Click to expand...

I just tried editing with various symbol table configurations and just stated what I found as my opinion. (If I was coding the block editor, that's probably how I would have made it work !)

I think that what you stated and what Mr Berger states...

Hans Berger said:

The data type is part of the definition of a symbol. It defines specific properties of the data behind the symbol, essentially the representation of the data contents

Click to expand...

explains what I was seeing when I was having a play, when I attempted to change a PIW declared as a WORD to an INT already used in the program, step 7 didn't allow the change because it was using it as a WORD elsewhere not as an INT.

But the main point is, that you must declare the data type correctly in the symbol table. I would assume that if you want to chop and change the data type in the program then don't add the absolute address to the symbol table.

Paul

I've just had a look at this one - I generally use a PIW declared as "INT" rather than "WORD" , as it is not possible to then use "WORD" with FC105 SCALE - However , and this seems to be a big however there seems to be a loss of resolution , which may or may not be an issue for you , particularly if you use 16 bit analogues .

I'm going to try this with hardware and see what the results are .

Hi 10baseT

Where does the loss of resolution come in?
I think Siemens' highest resolution modules are all 15 bit + sign, with the top bit being used for the sign. So in theory the range is +32767 to -32768 with a resolution of +/-1. However, in practice the usable range generated by the A-to-D converter is +27648 to -27648 with a resolution of +/-1. Values outside these limits up or down to 32K are treated as overrange or underrange.

For modules with less than 15-bit + sign resolution the value is left-shifted in the word, so the range is always the same (+/-27648) but the resolution will be different. 14-bit + sign gives a resolution of +/-2, 13-bit +sign gives +/-4, 12-bit + sign gives +/-8 etc.

How does defining the datatype of a value affect its resolution? This could be a major upset!

Regards

Ken

Ken ,

Just something I came across on a recent project - I had cause to change 12 bit cards to 16 bit , and following the use of FC105 on the raw data , with a conversion to real , there appeared to be a number of decimal places following the decimal point where data remained unchanged relative to the input . Having just checked a companion project , I notice that the programmer has addressed the PIW as a WORD , and is using his own scaling function , and don't have the same issues . I'm just setting this up with hardware now for a little check - the analogue input was a brand new issue , and was only supported with a backwardly compatible GSD file at the time , but Support maintain that this shouldn't have been an issue .
You're quite right , it shouldn't make a difference , only the resolution of the card is of importance , but this is what I found ! I'll let you know what I found , or alternatively , you can try for yourself .

The key factor here is that FC105 is not being used for the high resolution input - the type of the variable is irrelevant from a processing point of view.

Interestingly , seems that a PIW can be either a WORD or an INT , or possibly both , it only becomes fixed when it is declared in the symbol table .

Having looked at the contents of FC105 , and the dedicated scaling block , there is fundamentally no difference - after all scaling is hardly rocket science - in this particular case , it seems that the variable does matter . I'll set up a little simulation and advise the results .

Variable types are just a convenience for Step 7 so it can display them in the format that means something to you. For example if I could modify FC105 and change it's interface so that the IN variable was of type WORD instead of type INT, would it produce a different result given the same data in ? Of course not. The key issue is what the 16 bits of data from the PIW in question represents.

I quite see your point , and don't disagree with you , however , I'm reporting what I have seen !
S7 is not without its faults and foibles - having contracted for Siemens , I can confirm that there have been many little surprises where even 1000 year old Siemens guys can't explain errors . I'll dig you out a few examples . Windows also used to be the same - W95 , calculator and 750.5 - 750.35 , now we both know what the answer is , but W95 didn't .