If I want to sent 16 bit integers (-32768 to 32768) to and from a Siemens S7 1500 plc, and I configure them on the IRC5 side as analog input resp. output, will I need to do bytswapping on the Siemens side?
If my communication would only consist of consecutive booleans, will in that case swapping be necessary on the Siemens side?
IRC5 send 16bit integers from and to Siemens S7 1500 by Profinet
-
Plc_User -
November 16, 2018 at 2:31 PM -
Thread is marked as Resolved.
-
-
Why do You configure analog signals if You want to communicate integers
Declare them as GO / GI. And yes You have to swap the bytes.
On consecutives booleans nothing has to be swapped. -
I have read somewhere that sending negative values to group input output is a problem, and that configuring the signal as analog input output is a solution for this.
-
Yes, when you send by GI/GO you must use a Offset from 32768 on both sides
-
For sending values to the robot I do as follows:
I use a function to convert 16bit value to Sint (Signed integer):
CodeFUNC num Gi16ToSINT (num nAnalogIn) !If the value is > 32767 Then the integer should be negative IF nAnalogIn>32767 THEN !Negativte integer RETURN nAnalogIn-65536; ELSE RETURN nAnalogIn; ENDIF ENDFUNC
Then I use another function that uses the above mentioned function for reading i.e a Z-value to a position:
Code
Display MoreFUNC robtarget ReadZFromPLC (robtarget pInPos) !Create variable VAR robtarget pTmp; pTmp:=pInPos; !Read from PLC nZ:=Gi16ToSINT(giPosZ); !Set Z-value in robtarget pTmp.trans.z:=nZ; RETURN pTmp; ENDFUNC
In the Siemens end I Swap the Int-variable just before I output it to the robot (via Profinet).
-
If by "byteswapping" you mean big-endian/little-endian differences between IRC5 and PLC, it is possible to configure your signals 15-0, for example, instead of 0-15 to address that issue.
-
Ok, Thanks.
Yes the byte swapping between Siemens Plc and IRC5 should be big-little indean.
If i configure my sigals as you said : 15-0, and then I send f.i. -800 to the robot (or the other way around),
will these negative values be possible without further conversion?
Is the solution with the configuration of the input integers as analog input (in spite of group inputs) also
a possibility (to avoid problems with byte swapping and negative values)? -
I would proceed like you originally said and again asked just now. Configure it as analog and it will take care of the negative values. You will just have to experiment with the scaling to get it right.
-
If by "byteswapping" you mean big-endian/little-endian differences between IRC5 and PLC, it is possible to configure your signals 15-0, for example, instead of 0-15 to address that issue.Maybe a dumb question, but if you configure the area of a 16bit integer as you proposed, won't it just come out "inverted"?
For instance: If I have value 2, in binary it reads 0000 0000 0000 0010 in big-endian. When byte-swapped, it reads: 0000 0010 0000 0000.
If I instead "invert" it as your solution proposes, then it would read:
Big-endian: 0100 0000 0000 0000 (decimal value: 16 384)
Little-endian: 0000 0000 0100 0000 (decimal value: 64)How would this help?
-
If by "byteswapping" you mean big-endian/little-endian differences between IRC5 and PLC, it is possible to configure your signals 15-0, for example, instead of 0-15 to address that issue.Thanks, I am going to try that
I had the same problem, in my case I wanted to display the joint values on the HMI in real time (almost)
I faced two problems, Rapid has a limitation when sending values using SetGO, it only accepts unsigned integers
The second problem is the byte swapping (little/big Indian representation)
I tried using analog signals (I don't remember if bytes are swapped, too?), but notice the controller was overloaded processing them
I solved it by scaling and offsetting the valueinside the 1500 I rotate the bites
-
I am interrested in the statement that analog inputs could overload the system processing them.
In my case I would read in the analog inputs (integers that come from Profinet) in the normal robotcycle (not background) at some point the cycle.
It comprises some 20 analog inputs. Must I be afraid that going through these 20 analog inputs would cause a very large processing time?