Posts by panic mode

why not create own structure and buffer the motions?

example

STRUC MOVE_T L,P

STRUC MOTION_T MOVE_T Motion, POS Position, BOOL Approx, Transferred, REAL Speed

DECL MOTION_T Move[10]

then your comms can be simple, you can write each Move[] element in a one shot and you can keep feeding data into array as the program runs. when you comms write the element, it should set flag Transferred. and when program executes the motions, it should only proceed if Transferred is TRUE, then it could clear the Transferred flag, so that comms can repopulate it. you can use the small array as a ring buffer to process many motions (1000s).

what did you do exactly?

if you changed DEF_VEL_CP, that is a wrong thing to do.

DEF_VEL_CP is simply default value for non-PTP motions (it is the upper limit). and one is not supposed to change it.

the other thing is how did you test it?

if you program has $advance set to 3 or so but you change the values one motion before early, you will not see change - at least not on that motion.

if you reach soft limits it is already too late for any programmatic recovery. if you have motion that is calculated and could wind up in far or strange place, you need to check what the target is like before you send robot to go there. for that you need to use INV_POS() to see where the axes would be if the robot is to proceed on this path...

Quote from bukalajc

Ive written a test program and tried both of them and the first opens, but the other one doesnt, so im guessing it isnt a software issue.

i would not be so sure... did you check the IO mapping? did you try to skip programs and just manually toggle one output at a time? how certain are you that program is not pulsing the solenoids or turning both sides on at the same time?

was this working before? did anything change? is the silencer on exhaust port R plugged? maybe the plant air is not of good quality and air+dust has caked and sealed fine pores of the silencer. in that case the back pressure may prevent valves from shifting properly. maybe remove the silencer and try again. other than that have KUKA take it apart... it could be that airline is pinched or not plugged correctly...

in case of a Beckhoff PLC, the standard PLC is processing non-safe logic and managing all traffic (both standard and safety). but processing of safety logic is done elsewhere, in one of the block like EL6910 or even one of safe IO modules that have capabilities to process safety logic.

so what happens if the non-safe CPU responsible for organizing traffic stops doing that? what happens when safety messages are not delivered on time?

well, in that case, each and every safety node (every safe IO module) checks on its own if the safety message is on time or not. when it is not on time, each of them enters tripped state and shuts down.

so if you want to connect PLC and KRC, one of them need to take the role of a Master, the other must the role of the Slave.

KRC can act either as Master or Slave or both at the same time.

if can be master of few nodes that are local (tool control) and at the same time be slave to a PLC that manages entire shop floor.

PLC needs to exchange some data with robots... when to run.. what type of process to run etc.

but PLC does not need to be micromanaging everything that robots do. for example it does not need to know if Robot 24 has gripper open or closed. it can (if this is important to you) but normally it does not need to.

you need to choose which information is shared among which nodes. and you need to choose how each node handles information at hand...

but...

That is for standard signals (gray logic).

What robot cannot do is manage safety traffic... or manage safety logic for other nodes. for that you need a Safety PLC.

You can still have robot act as a master to some non-safe nodes. But when it comes to safe fieldbus, KRC can only be a slave.

no...

Master/Slave only tells who is managing network (data exchange).

this has absolutely nothing to do with what the actual signals and logic are or how they are used.

Think of the "Master" as someone responsible for maintaining a bus schedule. It keeps track of vehicles and their sizes (some busses could be bigger than others), knows the list of all bus stops and tracks arrival/departure times. basically it only organizes traffic.

It does not need to know or care who the passengers are.

so in this case

the buses are messages (some are bigger than others)

the roads are cables (all busses use same roads)

the nodes are bus stops (not every bus need to stop at each station)

the "Master" is just the extra duty (responsibility) assigned to one of the nodes. you can think of it as a central station, but really it is just another bus stop that happens to have added duty of managing traffic, instead of just being place where passengers can get on/off the bus.

bus service is just that - a service... allowing messages to travel around. what you do with messages is up to you.

you would be lucky to get 12ms. the update is slower than 12ms - always...

12ms is just the interpolation time of the Submit and it does not even account for spillovers due CPU quotas. on top of that there are other delays like fieldbus refresh.

if you need fast response, you need own servo drive controlled directly from the motion controller (without fieldbus, without submit..)

the async axis is meant for indexing positioner. there is no need to 'stream position profile' peace-meal to it - just give it the target position and trigger it. the motion profile will be calculated by the KSS.

btw, i do not recall seeing external axis (synchronous or not) where 12ms made any meaningful difference since positioning of the axis takes orders of magnitude longer to complete. from cycle time perspective that is simply insignificant. setting load correctly, tuning axis, planning motion, buffering data etc. allows for much greater optimization.

you can:

1. transfer program

2. select it

3. check if selected (that means it compiled)

4. deselect it

Quote from aknezevi.proton

Thank you panic mode , so the advance run is not stopped regardless of the statement called by TRIGGER.

technically yes but ...i would not go that far...

one can use TRIGGER to call some routine. that routine could have delays or processing that takes long enough so that main pointer (doing motion) runs out of pre-planned motion segments. in that case main pointer WILL stop and wait for advance run to fetch more data for the motion planner.

the idea with interrupts and triggers is that whatever they process - that code block need to be SMALL AND QUICK.

as SkyeFire stated... on the robot side safety signals are already mapped and that arrangement is fixed. you cannot rearrange the safety signals and you should not touch them at all. the only thing you need to do on the robot side is create configuration that connects to PLC. since you only need ProfiSafe, there is no actual need for standard IOs - therefore there is no need for any IO mapping.

that was on the robot side.

on the PLC side you need to create network configuration compatible with KRC. PLC will be ProfiNet master, KRC will be PRofiNet slave. you cannot change the roles in this case since you are using safety.

in the PLC you need to map safety IOs and of course this has to match bit-by-bit the safety signals that KRC uses. on safety interface there are 64-bits in and 64 bits out. if you are not using SafeOperation, you only need to focus on first 16bits in and 16 bits out.

all signals from PLC to KRC will need to be TRUE for robot to move. so you can write code that simply keeps them TRUE all the time - except for EStop and OperatorSafety. there you need to add logic where those signals to KRC are set by PLC signals coming from safety inputs.

and safety inputs need to be configured correctly. not just to 'work' but to work correctly (redundancy and all).

in practical terms you will want your safety inputs configured and wired as at least 1oo2

Quote from jrobotics

Any idea what would I do to restore the HMI on smartPad?

in short - use KUKA USB recovery stick to restore good HDD image.

but, since you are already in the hole, stop digging...

think before you do something else that may make things worse.

ask yourself if you do have a good backup. if answer is no, create one right now - system may not be functional but you do need ability to at least restore this state. also you need all your programs, settings and option packages... and a good idea is to create more than one form of backup.

after that:

if you do have a good backup image, restore it and you are done.

but....

if you do not have a good backup image, try restoring one from hidden partition (if one is still there). otherwise contact KUKA to get factory image.

depending on history of the robot this may or may not get you back to a working system (you may need to select correct, robot, configure external aes etc.). but at least it should get you back to the point where smartPad connects to KRC. then you will need to load back options and your working project that you backed up.

172.16.x.x and 172.17.x.x are internal networks used by KRC. smartPad connects to 172.17.0.1 but in this case this is no longer possible.

TRIGGER command does not cause advance run point.

code called by TRIGGER is entirely processed by the advance run point...

Backup that you cannot restore is not much of a backup. I strongly suggest making one right now even if system is bot in working order. Then you can compare the two.... And at least gou will have something to go back too if things get worse than already are

Replace EXEC with ;EXEC

you REALLY need to stop messing with things you do not understnd, specially when they involve safety - at least until you get proper training... and forum is NOT the substitute for formal training.

you are going to harm someone.

standard IO and safety IO are two different things (in fact VERY different) - they serve different purpose and are handled differently.

standard IO (aka gray logic) is the usual, cheap, plentiful, not safety rated and not redundant IO such as robot inputs and outputs. they can be manipulated any way you like and anyone is allows to mess with them as those are (in case of KRC) just SRC and DAT files...

safety rated IO (red or yellow) are safety rated and serve to protect human life. their signals are redundant, use monitoring, cross checking, etc. it is not enough to just "have safety IO". they also must be used in special program called safety task where you can program logic using special instruction set - safety rated and certified instruction set... once you start working with safety rated devices - everything need to be safety rated.

you are NOT allowed to mix safety and gray IO.

you are NOT allowed to mix safety and gray logic.

you are NOT allowed to map gray logic IO to safety inputs or use gray signals in safety logic.

the only exception is that you are allowed to copy state of some safety variable or I/O to a gray block of data (or IO) for the purpose of diagnostics. for example so that you know which of ten EStop buttons was pressed. this way you can display suitable message for the operator and save him some time so he does not need to go around the cell with 10 robots checking each and every button or safety device.

but... once the safety signal is cast into gray signal, it is a duplicate or clone of the safety signal... but... this duplicate is no longer safety rated and cannot be used in safety logic. and thankfully, WoV is trying to stop you from doing something really dangerous and stupid.

What real world application requires external axis position update that is so fast?

After all it takes some time for axis to reach the target position and this is always boing to be THE bottleneck.

What is your PLC scan time? What is the real handshake logic? For example do you know in advance what the next target position will be?

If you are going to control the axis from Submit, this is always going to be tied to 12ms interpolation time regardless of used transport mechanism (fieldbus type).

EKI is slow.

RSI is faster

FSD is fastest but... It us only the one way (sends position from robot to external system, cannot send anything in the other direction).

Robot is too complex and too slow for direct control of the single axis. Power of robot is complex, coordinated and geometrically constrained motion of multiple axes.

If you want fast control of some simple axis, do not use robot, use own motion controller or perhaps a plc. Avoid fieldbus by connecting motor to your own servo drive. Then you can have sub millisecond turnaround time.

You did not put complete robot model or state KRC type or KSS....

How many axis does your robot have?

If this is a 5 axis palletizer, A3 and A5 work together, so that flange is always facing down...

To separate them set $PAL_MODE to false.

After you done with service or mastering, change it back to true.

You can use single variable monitor for this.

why not simply create a fresh archive?

then you can go through each file that has errors and fix them one by one (or comment that line out) until all errors are resolved. to comment line out, simply place semicolon at the line begin, that will turn the program line into a comment.