Posts by panic mode

i have been pondering the same thing though have not found solution yet.

thi sworks with OPS for example (which does have KLI) but there should be a way to get this working in OL as well (similarly KEB can be convinced to work with OPS)

$CONFIG.DAT

or system variable monitor...

variable name is

LOAD_DATA[1..16]

yes, when windows is ok, there is no requirement to reload image.

corrupt KSS can be restored by reinstalling KSS and option packages.

if both windows and KSS are ok, system restoration only needs deploying and activating WoV project (if complete).

restoring backup image is a convenient way to bring everything back to a known state quickly.

but having multiple options is never an issue so multiple forms of backup are advised.

i appreciate shared updates but would not mind faster downloads from kuka.com

even small file such as UsbRecovery upgrade 3.0.4 with just 300Mb or so take forever as trickle is comparable to dialup speeds. i can download from other sites (Microsoft or whatever) many times faster so Flashenhals is definitely not on my end

using reducer (gear,belt etc) will reduce speed and increase torque. lowering speed is not an issue

and when connected in reverse, it will do the opposite (increase speed and decrease torque) but in this case (increasing speed) there is a limit how far you can go before the system is not driveable any more.

there are some small loses which are usually ignored since one adds safety margin anyway (20% for example).

so using gear ratio of 100:1 you can get the output speeds and torque

1600RPM * 0.8 = 1280 RPM

where 0.8 is 80% of rated speed, just to make sure there are some reserves....

1280RPM / gear ratio = 12.8RPM at output shaft

motor torque = 97.2oz-in * gear ratio =9720 oz-in

which exceeds required 8110 by some 17% or so.

sounds like your option is corrupt, did you try to copy it again from D:?

how about using OPC? you can add OPC UA server to your KRC4 and it looks like this HMI can use it too..

the simplest and most efficient way is to contact author of the DLL to make changes you want.

short of that, you can recreate this on your own from scratch as mentioned before. however this will be a significant effort and if you don't already have serious programming skill, may take years to develop. Note, forum is meant as a conversation place to share advice and point people in right direction. this is NOT substitute for formal training.

alternative to creating everything on your own from scratch is to simply purchase it (from KUKA or 3rd party) since there are ready to use HMI packages for Krc4. this is MUCH simpler path and you should be able to get result in maybe few days or maybe 2 weeks. and it does not cost an arm and a leg (usually). Advantage of purchasing product is that things are tested, they are ready to use, learning curve is short and such products come with support. if you are developing something on your own, you need to know much more to develop usable product and - you are practically on your own.

Example of commercial HMI for KRC4:

KUKA.Zenon: basically full fledged HMI suite. requires purchase of Development license to create applications (this is what you install on your computer). you also need RunTime license for software that installs on KRC4. if you have 5 robots where you need custom HMI, you can buy 1 Developer license and 5 RuntimeLicenses. (one Runtime is needed for each robot). This is really nice product but it costs more than others. price of Runtime license depends on number of tags you plan on using (more tags = higher cost). i don' know the prices but i would guess that every single license is maybe $2k or so...

Kuka.EasyHMI:

is a low cost (guessing under $1k) per runtime. there is no Development license cost as application is generated by WorkVisual (free download). it allows to create many applications, each can have multiple screens etc. you can choose screen size t obe half a page or full page. but the number of controls you can place per page is limited by selected grid size. This looks like a response to OrangeApps.MyHMI which too did not need special development package.

OrangeApps.MyHMI: a lower cost than KUKA.Easy (price is on the website). It predates Kuka.EasyHMI and it made it possible to create basic HMI using any text editor. to run it, one would need a runtime license per controller. free trial version is available.

as long and you have a plan. i am not sure what you are really after since your posts keep changing objective:

1. create DLL

2. edit existing DLL

3. replace some picture

and what the heck is KKK screen?

programmer writes code in one or more files. this set is called source code. it is what programmer wants computer to do.

but computers cannot execute source code. there are two basic ways to proceed:

a) use special program called interpreter that will parse and process instructions in the source code one line at a time.

b) use special program called compiler that will convert source code into executable file (which is in a binary format).

compilation may take long time and multiple passes to get desired result. interpreting does not have that luxury so of course compiled programs are executed faster. also interpreters require distributing source code but most companies are interested to keep their effort protected. finally executing compiled programs is simpler. user can focus on use of application rather making adaptations, setting paths etc.

DLL is a binary file created by compiler. it does not contain source code. analysing and making changes to such files is EXTREMELY difficult and requires very advanced and specialised knowledge. it is so hard that even in a rare case where modification is done, it is a hack at best a patch (replace couple of bytes with hexeditor). essentially there is no decompiler, at best you can try disassembler but any sybolic data, comments etc will be missing. also the code may not seem intuitive any more since compilers have optimised hell out of it, to work with thin one really need to know a lot, have tons of time and patience. which is not worth it.

just to put it into perspective:

if learning to program is like learning to drive a car,

then developing apps is like being ale to repair cars for a living.

then reverse engineering compiled DLL or EXE is more like finding charred remains of a crashed UFO then fixing it and then optimising its inner working. all because you really wanted the extra trunk space when doing grocery shopping (this is what i mean by not worth it).

if you are really interested in doing something, you will have to develop it from scratch, not patch some binary file.

considering fact that you are asking this, you should really think if you want to get involved at all. you have been warned.

https://www.wikihow.com/Create-DLL-Files

https://www.youtube.com/result…+dll+file%3F&search_type=

any application development software targeting Windows can be used ot make DLL file.

heck if you really wanted to, you can hand assemble it using hex editor

one easy way to start is to get programming software from company thad made Windows itself.

for example you can get VisualStudio of particular vintage or edition and get started. there is tons of tutorials on Youtube.

for example VB.NEt or C# are some of languages available in VisualStudio.

common path is to start with basics and adopt more as you go along.

learn about forms and standard controls, declarations, properties, objects, classes, timers etc.

then try something bigger like DataGridView etc.

then add reference to external controls (OCX, ActiveX) and use them in your program (this opens up a world of possibilities).

Dependencywalker is used to sniff out what they can do and what else they depend on.

then learn communication (open close socket, etc.) and communicate with KRC4 for example.

finally how to do the same but pack it into a DLL instead of EXE.

now you need to figure out how to integrate it in KRC4 HMI so it can be loaded, and selected from menu.

interrupts are limited resource and have some peculiar properties.

and he did mention 10000 GOTO labels. sounds like perfectly 'maintainable' program.

so good luck with porting... i would wear hazmat suit before touching it with a 10-foot pole, then burry it in a desert...

create something contemporary. enough of ghosts of past like punchcards, core memory and ... goto commands.

http://www.google.com

http://www.ebay.com

http://www.kuka.com

why bother with GOTO? ... <shudder>

the only time i consider using GOTO is to to exit nested loops without leaving subroutine.

i see that you were trying to change base. not sure why change base if wanted change is related to tool....

well, if you need to change tool, then.... change tool... either physically different tool or alter tool data for exising tool so robot would reposition or reorient it..

DECL INT tool_number

; if tools are not defined, compute them using whatever suitable offsets you need
; maybe rotate about center of flange:
tool_data[11]={x 0, y 0, z 0, a 0, b 0, c 30}:tool_data[10]
tool_data[12]={x 0, y 0, z 0, a 0, b 0, c 45}:tool_data[10]
tool_data[13]={x 0, y 0, z 0, a 0, b 0, c -30}:tool_data[10]
tool_data[14]={x 0, y 0, z 0, a 0, b -30, c 0}:tool_data[10]
tool_data[15]=tool_data[10]


; or rotate about TCP (alternative to previous calculation):
tool_data[11]=tool_data[10]:{x 0, y 0, z 0, a 0, b 0, c 30}
tool_data[12]=tool_data[10]:{x 0, y 0, z 0, a 0, b 0, c 45}
tool_data[13]=tool_data[10]:{x 0, y 0, z 0, a 0, b 0, c -30}
tool_data[14]=tool_data[10]:{x 0, y 0, z 0, a 0, b -30, c 0}
tool_data[15]=tool_data[10]


FOR tool number = 10 to 15 ; do some motions, then change tool and repeat
  $BASE = base_data[4]
  $TOOL = tool_data[tool_number]

  LIN xP1
  LIN xP2
  LIN xP3
  LIN xP4

ENDFOR

you need to initialize X so that base assignment in line 167 can work

Quote from hydra

You don't need to connect resistors on either side. Just connect 120 Ohms to one side.

What...?

Data bus is 5V.... Comms chips are powered by 5V and this is why CAN_H and CAN_L are measuring half of that -when using multimeter. On an oscilloscope you would see square wave 0-5V. Multimeter is just too slow to catch that and tou see average.

hmmm.... let me get this straight...

J61BT11N is a PCI network card meant to be added to an industrial PC. like any hardware, in order to work it must be installed in compatible environment and have drivers installed. this could be one or more problems.

One is that PC in KUKA robot controller runs not just Windows. in fact Windows does not get access to hardware at all. That is reserved to RTOS called vxWorks. standard NIC can work but who can be sure until you succeed... for example even if drivers can install, they may not like operating regime within time-slices that Windows is given chance to do something. it could be timing issue. but lets say all this is ok. next question is if drivers for your board are ok to run in this environment. This is not desktop OS so driver may not like it (Win7Embedded).

the next thing is that you are mentioning safety. this is definitely going to be a problem.

one option is to use hard-wired safety (X11 with or without X13)

other option is to use one of three safety networks - ProfiSafe, CipSafety and FSoE.

i think CC-link was on the roadmap but no idea how far it got (if anywhere) or if just standard fieldbus without safety.

and then you also mentioned "ethernet ip". one of us is confused here....

i think you are mixing Ethernet/IP with raw sockets communication (TCP/IP).

how many robots? you can also put all controllers into one cell (in WoV).

this need to be done once instead of clicking on checkmats of all robot everytime you want to make backup. then you can save project(s) in one click. though i am not fan of this,..

i would rather have each robot perform backup on their own at regular intervals. then if Connection to some server is avaliable dump copies. this way you don't have to guarantee that connection exists at the time of backup. it is automated, no manual intervention is needed since humans are not good at doing repetitive things. and each backup is competely independent. no need to worry if one robot is powered off etc. it will catch up...