Advertising

How to access/use the Signal editor in WV

  • Hi,


    I want to do the byte swapping in Work Visual 6.0 to transfer a 32bit integer as a signal to the KUKA controller from a Siemens PLC


    The WV help instructs me:

    - Select the device on the Field buses tab in the I/O Mapping window.

    - In the I/O Mapping window, click the Edit signals at the provider button. The signal editor window is opened...


    So I select "PROFINET" and look for the button

    Where is this button? I have gone through all the menus and all the corners of the interface...


    EDIT: Apparently I did not go through all the corners... because the button is a small... usually grayed out thing on the low right hand corner of the screen that looks like a pencil or something...
    Sorry to have waisted your time.


    Ok... this signal editor really needs good nerves. Its just constantly flickering...

    There are two options for byte swapping.

    • 1-2-3-4 >>> 2-1-4-3
    • 1-2-3-4 >>> 4-3-2-1


    What is the correct variant for a Siemens PLC?
    ... although I can only drag a single orange "SWAP" region over a single 32 bit signal range...


    And once I have created a signal in the Signal editor... How do I connect my inputs with it... the connect button is grayed out !?

  • AD
  • Koppel

    Changed the title of the thread from “How to access the Signal editor in WV” to “How to access/use the Signal editor in WV”.
  • Quote

    What is the correct variant for a Siemens PLC?

    depends if you are swapping 16-bits or 32-bits



    Quote

    the connect button is grayed out !?

    yup... Connect is only enabled when selected block sizes match. if you choose on side 16-bit and on other 5 bits, WoV does not know what to do.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • The help is rather vague on this:
    "It makes a difference whether a range is swapped as a whole or in parts:"


    So what do to for 32bits?


    About the grayed out Connect button...

    Ahaa.... If I select the proper amount.... like 32 of the inputs... the button is no longer grayed out and I can press it.

    Then it asks: "Do you want to group these signals and then connect them?"


    I previously tried to select a bunch of the inputs... right click... everything was still grayed out. But if I select 8 or 16 or 32 of them... then I am able to group them. It was not immediately clear how any of this works.


    PS! I was also wondering why I cannot write anything to the I/O Mapping "Description" column. Turns out that there is this "Symbol table editor" and these descriptions can be added only in there... And for groups the first ones name is applied to the group.

    Edited once, last by Koppel ().

  • KUKA help is not vague at all... in fact it is very specific and accurate... it clearly tells you that answer is 'it depends'... because it does... it depends on what is done on the PLC end. and that can be organized neatly or it can be a sort of Tetris-like. because of that flexibility, there is no magic silver bullet that makes things work for YOUR case without seeing what that case is. and it is not KUKA's fault that Siemens PLCs are different from pretty much everyone else. so if you have to use Siemens, you need to get used to this.


    those that plan things thing of this before PLC code is done and can organize things better, in order of signal size, and byte aligned. but this happens rarely so you may get mix of bits, bytes, words and double words in whatever order PLC programmer decided to do it.


    the goal is to get signals in correct order. you get to choose to sort this out either on PLC side or on WoV side. WoV makes this easy on KRC4 because you can do anything you like - even map them all bit by bit if you really want to... on KRC2 you could only do this byte-wise (8bit groups).


    and nobody says it is set in stone that the robot programmer that must be one dealing with this. you could pick mapping yourself and let PLC guy do the swapping on his end. just create your own list of signals and hand it to him/her...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • One more thing related to the interface to siemens plc:

    The plc word should/must begin on even byte number in the interface (siemens begins counting with zero), otherwise the plc programmer has to make some silly conversions. I'm not sure about double words, but I think they also have to begin on an even byte (and don't have to begin at a number that only can be divided through 4).

  • ... my adventure with trying to send a value from PLC to KUKA KRC4 Compact continues.


    • In Workvisual
      • I mapped $IN[201] ... $IN[232] to a PROFINET range
      • I dragged the orange SWAP bar over this PROFINET range like on the picture in the first post
      • I clicked on symbol to change it to "±"
    • In TIA portal
      • I created a new TAG with output address %QD41
      • I use the MOVE block to send a DINT value in a DB to this output.


    As Hermann says: "The plc word should/must begin on even byte number"

    ... My %QD41 is definitely not an even number.



    I am sending the value "200"

    So in binary I send:

    00000000'00000000'00000000'11001000


    Because of byte swap I receive:

    11001000'00000000'00000000'00000000


    That is in decimal: 3355443200

    That is in decimal from signed 2's complement: -939524096



    To see what I receive I created a SRC file with a signal declaration and I write the value to a constant


    Code
    SIGNAL DynX $IN[201] to $IN[232]
    ...
    DynX = MyVariable_iniside_DAT_FILE

    The value was: -939524096


    Because my bytes are swapped I checked different ranges to see if I can get the 200 out of somewhere.

    Code
    SIGNAL DynX $IN[225] to $IN[232] ;checking the last byte
    ...
    DynX = MyVariable_iniside_DAT_FILE

    The value was: 100

    Remember... the input was always "200"

    I changed the input to "100" ... out comes "50"

    I changed the input to "150" ... out comes "75"

    I changed the input to "50" ... out comes "25"


    Exactly half of what I send... what, why !?

  • because your mapping is wrong and somewhere you are off by one bit...

    try to remap it to inputs 200-231, instead of inputs 201-232


    also your code does not work. you cannot write to inputs.

    this is impossible (write variable value to inputs):

    Code
    DynX = MyVariable_iniside_DAT_FILE

    this is ok (write inputs value to a variable)

    Code
    MyVariable_iniside_DAT_FILE = DynX 

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • ... yes... of course the variable was in the wrong order... it was correct in the actual program...

    MyVariable_iniside_DAT_FILE = DynX


    Wow... shifting bits makes the value halve... I would have never guessed.

    00000011 is 3

    00000110 is 6

    00001100 is 12

    00011001 is 25

    00110010 is 50

    01100100 is 100

    11001000 is 200


    What is the deal with this "The plc word should/must begin on even byte number"


    Is this required on not?

  • well... this is nothing new.. the same thing happens when shifting in every weighted numbering system (where position of digit indicates 'weight' of that position).


    so shifted value gets multiplied or divided by the numbering system base.

    for example if you are shifting in decimal system, you are multiplying or dividing by 10 because 10 is base there.

    in binary that factor is 2 (base is 2), in octal is 8, in hexadecimal is 16 etc.


    about computing platforms peculiarities... there are many. memory or data structure alignment is just one of them. it is one of things where things boil down to efficiency of access to memory. of course it is possible to work around that if one is writing that part of software (direct access to memory). this is low level hardware programming. ladder logic, KRL etc are all high level programming languages where hardware is abstracted. what you can and cannot do is platform specific and should be documented on that platform. for more info refer to:


    https://en.wikipedia.org/wiki/Data_structure_alignment



    BTW.... certain CPU operations take different number of CPU clock cycles. in the past before architectures and instruction sets were optimized those differences were sometimes extreme. for example addition could be 1 cycle, subtraction 1 cycle, bit-shift 1 cycle, multiplication 70 clock cycles, division, 230 clock cycles or something like that.


    so if you were writing software where performance was critical (scientific data crunching, or video game programming), you would carefully consider how to multiply or divide for example. multiplying something by smaller number (10 for example) is much faster if not multiplying at all. one could add value multiple times and get same result MUCH faster. or - use combination of shifts and additions for example.


    or if you needed to divide bunch of values by some something. it was much better to find reciprocal of that divisor (or just have a lookup value), and then perform bunch of multiplications.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Hi everyone,


    Seeing this topic I would like to ask if someone has help material on this swap bytes information?

    Something like how bits are arranged in kuka, rockwell and siemens.

    There is an easy way to see the bits from a word on the robot?



    Thanks,

    Marcelo Rebouças

  • Seeing this topic I would like to ask if someone has help material on this swap bytes information?

    Something like how bits are arranged in kuka, rockwell and siemens.

    There is an easy way to see the bits from a word on the robot?

    Well, I know from painful experience that KUKA and Siemens use different byte orders. I think KUKA and Rockweall/Allen-Bradley use the same byte order. I always found that odd, given that KUKA and Siemens are both German companies and used to be very close -- the older KUKA robot controllers were essentially Siemens hardware with a few labels changed.


    There are a few different ways to see the word on the robot, but you have to be careful. Any SIGNAL declaration larger than 1 bit, and less than 32, is treated as an unsigned integer by KSS. However, once you make a 32-bit SIGNAL, this changes -- KSS natively assumes the 32nd bit is a sign bit, and the values you might see displayed in the VarCor or .DAT file will change accordingly.


    When you really want to see raw binary, sometimes the best thing is to ignore the declared SIGNALs, open up the I/O monitor, and look at the individual bits that make up the SIGNAL. Years ago on some KRC2s, I ran into a bizarre bit-ordering issue on an analog input device, and ended up building a program that would log each bit individually while I "swept" the analog input through a range. Then I cross-referenced the bit values against the real analog value and was eventually able to reverse-engineer the non-standard bit ordering.

  • I still struggle to understand the concept.

    I have KUKA inputs 201...232

    I use BYTE swapping in the signal editor


    I send decimal "1" with the PLC ... guess what Input is active... input 225. !?

    Should it not be either the very first or the very last INPUT?


    I attached a small PDF with my trials of what bit is activated by what decimal input. ByteSwappingKuka.pdf


    And it made no difference if the byte swapping was enabled in the Signal Editor or not... Decimal "1" still ended up on input 225 !?

  • The swapping is not done through manual mapping... it is done via dragging the orange "swapping" bar over the range of profinet inputs in the signal editor. Take a look at the screenshot on the first post.


    But it kind of makes sense to me now why the decimal "1" is not the first or the last input.
    Its not the bits that are in diverse order ... its the bytes.

    Something that used to be the first bit of first byte.... ends up being the first bit of the last byte.... and that will be $IN[225] in my case... not the first bit in my range and not the last bit in my range of 201...232

  • I admit, I tend not to use the WV byte-swapping tool, just b/c I worked out ways to do it the "hard" way before WV was a thing. My particular "cheat" was to map each byte of the 32-bit word individually, deliberately mis-ordered, to correct for the byte-swapping. And since it's being done at the I/O level, the word still looks like a valid 32-bit word to both the PLC and the robot.


    So, in WV, instead of grouping 32 bits together, I would group those bits into 4 bytes. Then, I would simple "cross-wire" them in the mapping screen: say, Byte 0 on the KRC side to Byte 1 on the PLC side, KRC Byte 1 to PLC byte 0, KRC Byte 2 to PLC Byte 3, and KRC Byte 3 to PLC Byte 2.


    I liked this method b/c it gave me complete, granular control over every detail of the byte-swapping. And a quick test would show me if I'd gotten it wrong, so fixing any mistakes was just a matter of looking at test results and swapping the bytes around in a different order.

  • that sounds good.... dealing with it at a byte level may remove some stigma on this subject.


    here is something to help visualize this and how the incorrect mapping causes bit-shift:


    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Amazing level of help guys... I really appreciate.


    panic mode, If I send decimal "1" from the PLC and use BYTE swapping in WV ... it should make the first input, $IN[201] in the range TRUE.

    If I don't use byte swapping... it should make $IN[225] to TRUE


    Now... what to make of the situation if $IN[225] was TRUE in both cases... byte swapping enabled and byte swapping disabled in the Signal Editor.

    My logic tells me that the BYTE swapping in Signal Editor in the WorkVisual 6.0 is not working... or it works in mysterious ways.


    SkyeFire suggestion to just group bytes and cross-map the 4 bytes yourself seems like a solid idea.


    PS! panic mode, my signal really is 201..232 and not 200 to 231. The loss of the least significant bit and the values being off by exactly 2x came from my SIGNAL declaration just looking at 7 bits... I was looking at 226 to 232 ... and not 225 to 232.

  • hmm no.... you just do not understand numbering systems or how to interpret the data. if you are getting value shifted by one bit, your mapping is definitely wrong - either at PLC side, or WoV side or both.


    first consider case of a DECIMAL number 3748 and - NO SWAPPING.

    in this case we are dealing with 4-digit decimal number.

    digit "8" is the right most, position weight is ones, place is designated as D0

    digit "4" is the second right most, position weight is tens, place is designated as D1

    digit "7" is third right most, position weight is hundreds, place is designated as D2

    etc.

    digit "3" is the left most, position weight is thousands, place is designated as D3.


    but we read from left to right so placement of digits is from most significant (left most) to least significant (right most) and order in which we read it is

    D3 D2 D1 D0


    if you only place digit "8" at D0, you get 0008 which is 8

    if you only place digit "8" at D1, you get 0080 which is 80

    if you only place digit "8" at D2, you get 0800 which is 800

    if you only place digit "8" at D3, you get 8000 which is 8000


    observe:

    1. we can look at digits separately but place where digit appears, affects combined value all digits represent...

    2. any digits could be in any place. for example digit value that is in position "ones" is not necessarily 1, in this case is 8. but the value could be any possible digit for used numbering system. in case of decimal that is (0,1,2,3,4,5,6,7,8,9)

    3. moving digit by one place, affects (in this case) combined value by factor of 10 (10x bigger or 10x smaller depending if moving left or right). for example 80 is 10x smaller than 800. and this factor 10 is the base of used numbering system. here we looked at decimal and decimal has ten possible digit values (0-9), therefore moving digit by just one place multiplies or divides by 10. moving one more place does it again (so moving two places left is multiplication by 100, moving right is division by 100). if you used numbering system with different base, then factor to multiply or divide would be different as well. for BINARY (base 2) there are only two possible digit values (0 and 1) and the factor to multiply or divide is by 2 if digit is moved to a next place (left or right). moving by two places in binary means factor is 2*2=4. moving three places in binary, factor is 2*2*2 = 8

    etc.

    4. look again at points 1 and 2... make sure to understand difference between value of single digit and combined value of all digits.


    now take a look at the attached image. here we are dealing with binary values. each byte has 8 bits, B0-B7 but arranged from most significant to least significant (because we are reading from left to right):

    B7 B6 B5 B4 B3 B2 B1 B0


    this matches what we explained with order of digits in decimal number which in case of only 4 digits was

    D3 D2 D1 D0


    it is just that now we are using 8 of them and values of each position are binary (0-1) instead of decimal (0-9)


    if you only place digit "1" at B0, you get "00000001" which is 1

    if you only place digit "1" at B1, you get "00000010" which is 2

    if you only place digit "1" at B2, you get "00000100" which is 4

    if you only place digit "1" at B3, you get "00001000" which is 8

    if you only place digit "1" at B4, you get "00010000" which is 16

    if you only place digit "1" at B5, you get "00100000" which is 32

    if you only place digit "1" at B6, you get "01000000" which is 64

    if you only place digit "1" at B7, you get "10000000" which is 128


    so if PLC sends 32-bit number whose value is 1, it will be B0 that is set. but 32-bit value is 4 bytes and so there are four B0. none of them are associated with $IN[201] or $IN[225]. both of them are B1 and not B1.


    byte swapping means changing order of bytes, not changing bit-order within byte.



    Quote

    If I send decimal "1" from the PLC and use BYTE swapping in WV ... it should make the first input, $IN[201] in the range TRUE.

    If I don't use byte swapping... it should make $IN[225] to TRUE


    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Well... I did what SkyeFire suggested, swapped the bytes manually, and everything worked immediately. Positive numbers, negative numbers... everything came through correctly.

    • Group the desired 32 inputs into 4 groups...
      • BYTE 1 $IN[201] ... $IN[208]
      • BYTE 2 $IN[209] ... $IN[216]
      • BYTE 3 $IN[217] ... $IN[224]
      • BYTE 4 $IN[225] ... $IN[232]
    • In the Profinet "Edit signals at the provider" group your input range by dragging the first orange box downwards and rename the groups for easier understanding
    • Map the inputs to profinet inputs in swapped order
      • Profinet BYTE 4 >>> INPUT BYTE 1
      • Profinet BYTE 3 >>> INPUT BYTE 2
      • Profinet BYTE 2 >>> INPUT BYTE 3
      • Profinet BYTE 1 >>> INPUT BYTE 4


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now