Posts by Koppel

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 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 !?

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

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

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.

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 !?

So the automatic external mode is run by means of PGNO_VALID.
So the PLC sends a program number to the KUKA controller... the controller sends the program number back to the PLC... you compare the two numbers and if they are the same you can trigger the PGNO_VALID... after that the program will start.

That is not an error... its a normal message... the controller is just waiting for you to trigger the PGNO_VALID bit.

Maybe something on the PLC program side is messed up... look into why it is not sending the PGNO_VALID.

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.

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 !?

Yes... the functions I am talking about are on the PLC side.

My PLC logic is definitely flakey... but I can't put my finger on it.

I think I can have a situation where function sends a PNGO_VALID, and the robot does its thing.

Then a separate function also does all the sending a PNGO, comparing it with reflected and also wants to output PNGO_VALID

... but KUKA complains that it waits for PNGO_VALID to be not true... So it was TRUE because of the first function... and then TRUE because of the second function and therefore TRUE constantly...

... and I have PGNO_REQ as one of the conditions.

In this situation this program step "MyDB".SR7 is activating the output "PGNO_VALID"

Infact ... eight different steps are activating the PGNO_VALID through an OR logic.

Are there any complaints about the way I do this?

EDIT: Hahaha... PGNO_REQ was missing as a condition on one of the 8 functions... and this probably caused the problem...

... hmm... I am already doing what massula suggested..."job done" bit at the end of each program.

And SkyeFire suggesting to add this handshake thing to the CELL.SRC itself is good for sometimes running through the program manually... and not wanting to trigger the handshake bits in the end.

... but the problems I encountered... functions wanting to start two programs at the same time... Is there a recommended sequence of steps that avoids this?

Hi,

I use the CELL.SRC program to run different programs depending on PLC input.

On the PLC side I do the following:

• Move a PGNO to the KUKA controller
• Verify that the reflected PGNO is what I want
• Send the PNGO_VALID to the KUKA controller and the program starts.
• ... WAIT for a specific input TRUE (that I switch high at the end of this specific Kuka program) that tells the PLC this specific program is now done... and not something else.
• Send a CONFIRMATION to the KUKA controller that I got the message about the program being done.
• ... WAIT for the specific input to be FALSE again... (KUKA program turns it FALSE when it it got the message)

I do this because I have 8 different KUKA programs that are executed at different times by 8 different functions...

BUT there is a problem... sometimes two of these functions are at the same point in life... they both want the robot to do something at the same time.

So first one tells the PGNO should be "7"

The second one tells the PNGO should be "8"

The reflected PGNO is equal to "8" ... this program gets executed but... the second function will forever wait until the program number equals "7" ... but it never will... Its past this point already.

The remedy to this problem has been to to not start a sequence if any of the other 7 sequences are busy... but it feels wrong... there must be a correct way to do it.

So...

Is there a standard way for the PLC and Robot to talk to each other about what program is done... what should be started next. Perhaps even a buffer of different jobs and their order.

I have seen in some threads but I don't know how its done:

I don't understand the problem.
You have 64 safe inputs/outputs. I think they are automatically mapped in WoV.

So you can immediately use them in your Siemens FailSafe PLC safety program.

Output address Q5500.0 is Local E-STOP

Output address Q5500.1 is Drives Enable

Output address Q5500.2 is Motion Enable

...

I think you cannot just monitor the Safety Inputs unless they are used in the Safety program...

So you might have all of the Safety I/O-s in some Tag table and you just monitor them and it seems like nothing is coming through...

But use the inputs in a safety program and then you can monitor them.

Yeah... that's some weird mapping.

I also explained in my post

"... $OUT[2] would be Input I100.1 to the PLC"

The two devices are talking to each other.

One speaks and the other one listens...

In your case both are listening... hence the silence.

Don't worry, you will get there... I know all of this is frustrating but this is how we all have learned - by making mistakes... a lot of mistakes.

1. You should drag one thing to TIA hardware. KRC4-ProfiNet_4.1

I have the following hierarchy.

• KRC4
  • Interface1
    • Port1
• 256 digital in- and outputs_1

And if you open the KRC4 under "Device View" tab and you open the properties pane for that, you can see additional settings.

General > Profinet Interface [X1] > Ethernet addresses > ...

I have checked "IP address is set directly at the device"

And further down there is:

- PROFINET device name: kuka-noname

- Converted name: kuka-noname

- Device number: 1

2. I think I have seen this error... I guess you have used a wrong version of the GSDML file - too old. All the the versions are under Program Files/Kuka/WorkVisual 6.0/DeviceDescriptions/GSDML. Pick the one that you have in the actual controller. Import that to TIA Portal and use it in your hardware configuration.

3. I have not tried with WiFi... I would connect the Kuka controller, the PLC and the PC with a wired network.

No PSEND/PRECV needed

If the connection is done over ProfiNet than:

• You load the GSDML file into TIA portal
• You add the KUKA controller to your hardware configuration
  • Under this configuration you set the start address for your communication... I guess it was 4096 inputs and 4096 outputs...
  • You set your profinet device name and IP address.
• In Kuka Work Visual software you map your inputs and outputs to this ProfiNet range.
  • $IN[1] to ProfiNet input [1]
  • $IN[2] to ProfiNet input [2]
  • $OUT[1] to Profinet output [1]
  • $OUT[2] to Profinet output [2]
  • If your start address was 100 then this $IN[1] to KUKA would be Output Q100.0 from the PLC
    $OUT[2] would be Input I100.1 to the PLC
• After you Deploy the modified WorkVisual project to your KUKA controller, the connection should go GREEN between the KUKA contoller and the PLC. The I/O-s come through.

Since I cannot use $PRO_ACT to determine if CELL.SRC is running, is there any clever way to inform the operator that the Robot is not ready to take commands from the PLC and the operator should check the Kuka Teach Pendant.

If I need multiple equipment to work together and things are not starting up, I would need a hint on the HMI for troubleshooting. Something that would hint towards checking the robot...

... interesting.

Form the signal diagram in the system intergrator manual... it seems its always ON after its initially turned on. Doesn't matter if CELL.SRC is running on if some EXAMPLE.SRC is running... is always ON...

I need EXT_START in the beginning for PGNO_REQ to go up so the robot starts to take interest in receiving program numbers... And I want this to happen in the bacground.

This is how I know that CELL.SRC is running. And if its not running I have a message on the PLC side HMI "CELL.SRC is not running" so that the operator knows to check the KUKA TeachPendent... selects the CELL.SRC, homes the robot and the warning on the HMI goes away.

Ideally I want the operator to do minimum ammount of activities after a cold start.

Does APPL_RUN stay ON during HALT ?

I could then only send EXT_START when both PRO_ACT is OFF and APPL_RUN is OFF

Quote from panic mode

how sure you are that PLC does not simply activate another $EXT_START when it sees that program is not running?

I gess that is it...

I use automatic system start with program number acknowledgement by means of PGNO_VALID.
Certain program steps send a PGNO ... I look at the reflected PGNO and if they match I put PGNO_VALID on... and that starts a program.

And SkyeFire, a cycle start button is also one of the conditions, so no scary "taking off" immediately

If $PRO_ACT is not on, I will put $EXT_START on. And thats the only thing that turns $EXT_START ON.

Is the HALT command turning $PRO_ACT off !?

Fantastic... In my case the CONTINUE before the IF statement would be good enough. There is no precise timing required for the input evaluation. Its decided minutes before.

Hi,

I have a gripper test subprogram that I run immediately after grabbing something... while the robot is stationary. When the gripper closes all the way I know that the grabbing was not successful.

IF $IN[1]==FALSE THEN
HALT
ENDIF

Works like I expected during testing in T1, T2 and even in AUT mode... and stops the program when there is a problem.

During EXT mode it does not skip a beat and the program continues without stopping.

Why?