For Telegram data, like you might get from an external absolute encoder, I typically use SCL (modeled after how Siemens builds Telegram blocks).

On the input to the Encoder Telegram FB:
W1: Word
W2: Word
Scaling: Real // 1.0 when not scaling required
Status : Word

On the output from that FB:
Position: Real
Control: Word (if available)

Inside, the code would look as quoted below: 

FB Interface
TEMP:
  dwEncoderInput : DWord
  dintEncoder : DInt

//move the 2 registers inside a dword
#dwEncoderInput.%W1 := #W1;
#dwEncoderInput.%W0 := #W2;

//convert the data to a DInt
#dintEncoder := DWord_to_DInt(#dwEncoderInput)

//convert pulses to mm
#Position:= DInt_to_Real(#dintEncoder) * #scaling;

The first 2 lines might need swapping around to get the byte order correct - depending on the byte order of the encoder data. 

AbrahamRiestra

alanTI

Being this device an absolute encoder, I highly doubt that the distance i encoded in REAL.

If I understood the manual correctly, the 2 registers you are reading simply contain the value as a Dint. Multiply this Dint by 0.8mm and you have your distance in mm.

here is how i would do it:

//move the 2 registers inside a dword
tempDword.%W1 := IW31;
tempDword.%W0 := IW33;

//convert the data to a integer
totalPulses := dword_to_dint(tempDword)

//convert pulses to mm
distance_mm := dint_to_real(totalPulses) * 0.8;

 

 Hello Alan, thank you for the help! With this method if I understand well is like this:

1.- Move the two words into a double word (Dword)

2.- Convert the Dword to a DInt

3.- Multiply the DInt by 0.8

In other forums I saw they use the SWAP sometimes for some operations like this one, here won't be necessary right? And it should go in the FB as STL or SCL?

Thank you again for the help.

I am not clear why the FB output is applied to ID50.  To me, it should be a tag within a global DB.  Or, if you must, MD##, where you type a new tag name for the encoder position in mm, like abcde123_position_mm.

The reason I say this is because using ID50 means that some analog input device is connected to the PLC, providing 4 bytes of data, and overwriting the value in ID50 every PLC scan (typically).

Look up the various tag type uses in the S7-1200/1500 Programming and Style Guideline.

For me, I tend to go super simple for tags I would tend to use M-type memory for.  I have a Global DB named Tags.

I add tags to that global DB.

In this specific instance, it would be "Tags".abcde123_position_mm (according to my example above).

After you fix that FB output to either DB or M tag, you should be good to go for this type of encoder.  For that matter, you can extend it's use to multiple encoders because of the FBs scaling input parameter, and it's ability to help determine scaling external to the FB. 

If you set the scaling input's default value to 1.0, you do not even need to provide a value for each FB's instance if that instance's scaling needs to be 1.0 (another thought to consider for FB writers everywhere).

AbrahamRiestra

And the block now