Posts by diglo

It looks like an EVS93xx.

The external programming LCD/keypad socket is exposed but I don't want to risk 80€+ to buy a keypad which might be unusable.

Ok thanks skyefire,

do you know which series of Lenze drives was kuka using at the time?

diglo

Hello guys,

I'have got an old but working KSD1-08 servo drive from an old robot, does anyone know if it is possible to use that drive in a DIY context, maybe emulating the protocol with an Arduino or similar? The drive is using the INTERBUS protocol but there is no documentation around...

Is there here any crazy hacker who tried to do that?

diglo

Ahhh! Thanks for the info....

I have that chackbox grayed out... is that a paid feature?

diglo

hello, yes it still usable, but i do not offer any warranty on the code!

you have access to any GLOBAL variables you delclare in your .dat files

DO NOT expect real-time communication and do not use this variable exchange method to control process-critical aspects.

I have come up with an update of the socket communication, i will update the files shortly.

diglo

Hello robot people!

Do you know whether the Fanuc Roboguide simulator does compute the reducer wear when running a simulation?

I've been running a simulation of a very intensive application for few hours and the reducer life is not changing in the page MENU-STATUS-AXIS-DIAG

diglo

Thank you DHA, I figured it out myself...
I made a fimple karel program which can set the configuration flags for a given PR[] index:

...


VAR
status:INTEGER
target_pr:INTEGER
read_pos:XYZWPR
conf:CONFIG
input_FN:INTEGER
input_UD:INTEGER
input_TB:INTEGER


BEGIN
status=0	
read_pos=GET_POS_REG(target_pr,status,1)


conf=read_pos.config_data
conf.cfg_flip=input_FN>0
conf.cfg_up=input_UD>0
conf.cfg_front=input_TB>0
conf.cfg_left=FALSE


read_pos.config_data=conf


status=0
SET_POS_REG(target_pr,read_pos,status,1)


...

diglo

Hello robot people!

Does anybody know hot to read/write the position configuration (robot posture/attitude) flags from/to a PR[] ?
We can of course access the 6 cartesian components using PR[I,J]=... where J goes from 1 to 6 but I cannot find a way to read/write the axis configuration...

Thanks!
diglo

The I/O works normally.
The fault only appears when I cut the power supply to the I/O rack, which is of course understandable!

I just would like to know how to put the rack back to service after a power cut, without cycling the power of the controller if it's possible.

diglo

Hello robot people!

we are going to install an ABU05A I/O rack outside of the controller cabinet, powered with a dedicated 24V PSU.

If the interface module AIF01A is powered off while the robot controller is on, the system throws this error message:

PRIO-020 I/O Link comm error 4, 0, 2, 40 (hex)

The I/O Link communication is not automatically restored when the interface module is powered back on.
Is there a way to clear this error and restore the communication without cycling the power of the robot contoller, in my case a R-30iB?

Thanks,
diglo

Did you try to run a file search inside the C:/ or D:/ folders of the robot controller?

diglo

This is a general programming question...

If you have a lage number of comparison to do, declare your variables as an array of REAL or INT and then use a FOR loop to iterate...

diglo

M.Ozkan, the point here is to allow NATIVE communication between an application running on the controller and the controller.
There are no bridges or plugins needed for an app to communicate with the controller, just the right calls to the functions altrady made available by the CrossComm service.

diglo

Hello robot people!

I've been working on a solution to natively communicate with the robot controller without the KUKAVARPROXY bridge and finally figured out how to do it.

I'll develop a CrossComm interface component which will allows an application to natively communicate with the controller without the overhead and latency of the TCP communication needed with KUKAVARPROXY.

Is anyone interested in the thing?

diglo

There's an option package called KUKA.MultiSubmitInterpreter, which allows you to run up to 8 different SPSs simultaneously (we have it on our testing robot at the workshop)

You may use one instance only to generate your signal.

diglo

Hi everyone!

Does anybody know if there's a way to get the controller serial number and the robot serial number from a WorkVisual project on a KRC4 system?

diglo

Answered myself for robot serial number: activate controller -> open machine data configuration

I don't know how to have a kuka robot applying a determined force along a vector, but if you just neet to set one or more "soft" axes, you can apply a torque limitation:

I wrapped the KUKA functionality in this function:

GLOBAL DEF limit_torque(ax:IN,range:IN)
   INT ax
   REAL range
   DECL TorqLimitParam limits 
   IF range>0 THEN
      limits.monitor = #OFF
      limits.max_lag=  90
      limits.max_vel=  600
      limits.lower =   -$TORQUE_AXIS_MAX[ax]*(range/100)
      limits.upper =   $TORQUE_AXIS_MAX[ax]*(range/100) 
      SET_TORQUE_LIMITS(ax, limits)
   ENDIF
END

And to make axis 1 pushable by hand for 10 sec, you can do:

limit_torque(1,0)
PTP $POS_ACT
WAIT SEC 10
RESET_TORQUE_LIMITS(1)

BE CAREFUL WHEN LIMITING THE TORQUE OF OTHER AXES!

diglo

My answer is: you will never get precise and repeatable timing on digital outputs.

SPS is not running at a fixed rate! While you can use a timer to set/reset a $OUT, the SPS cycle frequency will vary with the logic run inside it (if-else blocks can affect the SPS cycle frequency), so it will add jitter to your signal.

The only way I've been able to achieve precise timing is by using triggers, so during motion (I've been working on a robotized dotmatrix printer project).

diglo

Quote from panic mode

[size=2px]btw. you still don't specify what is the ambient temperature for your robot...[/size]

I know, it was a generic question... Our machines may end up working with ambient temperatures which may reach 50-55°C

diglo

That's ok... but it's strange I cant't find anything about that in the documentation! Am i missing something?

Obviously it's desiderable to avoid having the robot stopped in the middle of the cycle because the motors are overheating...

diglo