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.

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...

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).

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):

DynX = MyVariable_iniside_DAT_FILE

this is ok (write inputs value to a variable)

MyVariable_iniside_DAT_FILE = DynX 

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.

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

there are different ways to go about this. probably the simplest is to simply create SIGNAL and write value to it.

Quote from Marcelo Reboucas

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.

You should post a Screenshot of the byte swapping in WoV. Think the problem is on that side.

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:

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