Id like to add dependant dropdowns and less limitations on number of variables per page to that request. Button actions would also be nice, now one has to program R/F/P trigs manually to not retrigger actions from buttons.
Posts by Hes
-
-
-
After rereading this 3 times i came to the conclusion i have not the slightest clue what you are after.
Do you want to abort the program, recovery and restart? Do you want the "coffee worker" to do something manually? Do you want the program to loop so the "coffee worker" does not have to do something. Do you want to stop the program at any given time?
-
I found this thread: WorkVisual "Programming and diagnosis" which seems to suggest that it's not possible to do with 8.3.14 so I'll ask the question left hanging in that thread: Is there a way to upgrade to the latest (minor minor) revision without paying for a license?
Minor kss version can be upgraded at no cost if you do it yourself. Just ask kuka customer service for the latest version. Believe the latest is kss 8.3.43 so this one has alot of minor versions.
-
Put the program in a loop of suitable kind
loop .. endloop
for... endfor
while.. endwhile
repeat .. until
Or the nasty option goto and label, if you are sadistically inclined.
-
is there a small typo? Should it be this in the decimal example?:
..exor 1
..exor 2
..exor 4
..exor 8
..exor 16
..exor 32
-
if i remember correctly the R should correspond to $PRO_ACT. Atleast a green R should be $PRO_ACT=TRUE. If you want to know in more details than if it is green or not you need to supplement it with additional stuff. Most likely you would like to check operating mode ($MODE_OP) but in its simplest form what you are asking for is putting this in a submit:
$OUT[??]=$PRO_ACT AND VacMotStartReq
From this you can add as much coding spices as you like, maybe a rising edge trig? Maybe code it so it ignores a start request if pro_act is false? Maybe flip the stop signal so it is False when you request a stop not the other way around (kinda boring if the vacuum motor starts when you turn the robot off) the list is nearly endless
-
dunno if $VEL_APPL is available on kss 8.6 (it exists atleast on kss 8.7) but that is one possibility. Otherwise your only option is modifying $OV_PRO which most often is not advisable.
-
i just tried it on the robot running 8.7 and no problem...
if not logged in, Change is grayed out. this is expected since global point and in the Rights Management default is that touchup of global points requires at least Expert level.
if logged in as Expert, Change button is enabled and it works...
Just out of curiosity, what is the program to the left in your screenshot?
-
workvisual does not work with KR C5 micro
It does work for kr c5 micro.
As for iiQKa i have no idea. Never used it. Saw somewhere they dont support raw krl, got disgusted and never looked back
On a normal robot you would use EKI for tcp communication. Or an EL6692 or EL6695 or EL6695-1001 bridge for straight buscommunication over EtherCat between two ethercat masters.
If using the bridge modules is an option on iiQKa i wouldn't touch anything else. Why start building a complicated system when you can have a simple one? Ofc if you want communication over either EIP or PNET is also a valid option, however only one of them can be active on the same controller assuming iiQKa behaves as a standard robot. Both of these buses require software options for the robot. By far cheapest and simplest option is ethercat bridge in my opinion.
-
Sure, publication number is PB23115 that is for a very new even unknown kss to me. I know i've got one for 8.7 somewhere also.
Publication number PB8872 is for kss 8.2, 8.3 and 8.5
You should find it on xpert by those numbers. Name is along the lines:
Controller option
KR C4 EtherCat
-
as the manual states you also need to do something more than just heartlessly rip the ethercat device from the bus without warning.
-
i have not tried it myself but i did some research some time ago and I came to the conclusion that it should be possible atleast for a kr c5 it might also be for kr c4. There is a manual on xpert for ethercat if you just search for ethercat you should be able to find it.
This is a snippet from it:
-
By using $ROB_TIMER you can get the time in millisecond precision. But it will (usually) be in multiples of the internal cycletime (12ms) of the controller. I dont know what kind of timing accuracy you need but things can be done to either slow down or speed things up if you can omit various things. The bigger question is why? Submits are asyncronous so you cant expect any "perfect" timing to be achieveable. But eg. only doing something every 1s in the background with a fair tolerance in +/- x * 12ms is sort of doable if you code it properly. Submits are called every 12ms but there is no guarantee where program pointer is. When the slice of processing reserved for that submit is used up it leaves it until next 12ms cycle. Some submit loops can take multiple cycles to get through once some can cycle several times in one internal cycle etc. Certain commands are notorious and chews up a crapload of resources and can take 100's of milliseconds to even complete a single command.
Regarding getting the looptime:
In *.sub or *.src
CodeDECL INT StartTime, StopTime StartTime = $ROB_TIMER ;...your program StopTime = $ROB_TIMER LoopTime = StopTime - StartTime
In *.dat set scope appropriately
-
id say that i've seen the same message also, but it has never reset a base to 0, 0, 0
This has happened when manually fiddling in config.dat while alterering bases. Try truncating the result to 7 digits total including decimals. The only difference i have found for me has been that the numerical values have been truncated but not significantly altered in other way. Atleast what i have seen.
-
i think but this is purely speculation that you could try to decouple & couple the ethercat device to get it alive on the bus again. Or decouple it before shutting down the controller. I think the device would have to be configured as couplable in workvisual.
Something along the lines:
IOCTL("SYS-X44", ..., ...)
Or if you just want to avoid restarting the controller, try resetting the ethercat driver from the hmi.
-
as panic mode stated this can be done. Or you can do it thru workvisual.
There is no kuka equivalent to abb pdisp to my knowledge, but if you look up bas.src you will find something along the lines off base_corr which you can use to temporarily shift bases. I prefer to do it by setting a dynamic base to which i copy whatever base i want to start from and offset it accordingly.
But when the only tool you have is a hammer most things tend to look like nails.
There are surely other ways yo achieve this too but you have a few to choose from. If you know what shift you need, doing it from workvisual or smartpad is maybe the easiest.
-
$ROBROOT should always be held in place. $WORLD can be shifted if required. Especially if robot is mounted upside down or similar. Relationship is always $ROBROOT -> $WORLD -> Base..
I see no reason to ever fiddle with robroot.
-
this is somewhat unrelated but still on topic. As the others suggested you should leave $OV_PRO alone as far as possible and only use it when you really have to, set speeds for each motions as they are meant to be set as hermann adviced.
I compared the diffrences between system variables documentation for 8.5 and 8.7 some time ago and low and behold.. I found what appears to be a sparingly documented golden nugget: $VEL_APPL
This fills a gap for the applications where one was forced to hammer $OV_PRO if one absolutely had to adjust speed at runtime. (Or use rsi)
With $VEL_APPL one can adjust the speed at runtime for cp motions with a few logical restrictions. Speed is capped at programmed speed.
-
What is it that you are seeking? A conical spiral, a regular spiral, somekind of ellipsis, a skewed circle?