You could also trade off some time resolution for color resolution, some bonus fun time to figure out the protocol to use
If you insist on sending numbers through outputs, then convert the type from real (prob want to multiply by 100 to get two decimal places) to unsigned int and then send with signal, although using 19 outputs seems... inefficient. And that's just for X value.
As I understood I need to add 500 instructions in the Spline block manualy in this case. Can I work around this and still get a smooth motion for 500 points?
This is where some scripting language (python, bash...) comes in handy. Or just google spreadsheet to get numbers from 1 to 500 and some regex. Or worse case scenario, use this:Code
This is probably known by some people here, but since I didn't found any mention on manuals, I would leave the tip.
This week I accidentally discovered that WorkVisual KRL editor also has a column selection mode, and it is triggered by the same shortcut used in Notepad++ (Ctrl + Alt + Left mouse button).
The funny part is that this feature is present since WoV 3.0.10, older version I've tested here.
Use this quite often, works with just alt+leftmouse.
Look into advance pointer to understand why this happens. You might also want to read about triggers if you want fine control over I/O during motion.
Your assumption that robot works with files directly from windows filesystem is wrong. They are only used as a form of permanent storage. When robot starts, it copies the files onto a ramdisk. If your robot's KSS version supports it, there is an add-on module- Directory loader (only works in external mode though). There are plenty of forum posts about it, just search.
I also heard this Java hegemony in KRC controllers some times, but I think KUKA wouldn't simply throw away decades of KRL accumulated knowledge.
I think a bigger hurdle is real time execution vs Java's garbage collection. Now that's a can of worms I wouldn't like to open.
Btw. I did bunch for projects for Honda and they want everything Mitsubishi. Detailed documentation is one thing i really learned to appreciate from working with Mitsubishi products (PLC, servos, whatever). Translation of the manuals may not be exactly the best but it is more than adequate. But... what really impressed me how VERY clean and consistent structure of everything is (file format, file version, references, troubleshooting etc.). Each manual TELLS you what the related manuals are, each function, parameter etc is FULLY documented (R/W, range, scope, validity, exceptions, execution time for each instruction etc.). One can literally build anything and know what to expect and what the performance will be - just by reading the manual. And manuals are named according to predefined format so one can have several versions of "same" manual in the same folder - no conflict. And downloading latest version will have unique file name so there is no risk of overwriting older ones, while one can instantly tell which version is the most recent. Germans could or would not ever do that - simplicity is not on their minds.
Well, if their products are good on top of that, then I would want everything Mitsubishi too. A lot of companies see documentation as only a checklist requirement or an afterthought. For any complex thing, documentation is part of the thing.
Cerco di essere più specifico. Ho un robot KUKA KRC1 e vorrei programmarlo con robodk. Utilizzando la post-elaborazione "KUKA KRC1 DATA" non ottengo un file compilato .src. Allego il file .txt [attach = 27731] [/ attach] sperando che qualcuno suggerisca di apportare modifiche. Grazie e ci scusiamo per l'inesattezza della domanda [attach = 27731] [/ attach]
Ev forûmek ingilîzîaxêv e, pirsa xwe bi îngilîzî bişînin.
The piece of iron is not scary. The change to body's structure and reduced functionality after the piece of iron impacts it with sufficient force/momentum- is. Even if you consider yourself invincible/expendable, other people may wander into the robot's working area. Do you really want to clean up flesh, blood and bone fragments after all the additional paperwork?
Erm, have you tried using alternative DNS, like 188.8.131.52 or 184.108.40.206 ?
What is the difference between wait sec 0 and wait for true and why the second one is better?
There might not be any discernible difference in KRL code execution, but at least for me personally, it's very easy to remember that "Wait for True" has only one purpose- to stop the advance pointer. "Wait sec 0" might have been "Wait sec 0.3" before, it's now not needed there at all, but I forgot to remove it. So it's not better somehow, just easier to recognize.
But I can't even store coordinates in currentXYZ = $ POS_ACT - I get error. Something like "you can't save runtime data in the main program".
If you read the manual, you would know
Interrupt routines cannot change runtime data- passed as parameters or otherwise. I suggest making currentXYZ a global variable (just declaring it in .dat file might also work) and using $pos_int instead of $pos_act.
I can do it by setting an output in sps.sub and wiring that output to another input, but it seems like a waste of 2 inputs and 2 outputs just to reroute signal from the robot to itself.
Yet that is exactly the way I do it -although it's 3 "wasted" inputs and outputs each.
I prefer using "Wait for True", that way it's easier (for me) to distinguish that stopping advance pointer is the only reason that line is there.
Writing functions to iterate over commonly used structures like pos, frame, axis and the like was game changing. Highly recommend.
Use ptp $Axis_act for quick BCO instead of $pos_act- unlike the latter it works predictably in singularities.
Assigning pos to frame to remove status and turn is obvious, but still useful.
Something that I use quite a lot:
Very easy to remove after debugging, as opposed to just Halt.
Use VarState function to write functions with default parameters or to turn structures with missing elements into strings.
Geometric operator can be used to avoid stopping advance pointer when there is a need to change $tool and or $base.
Don't do complex things like trajectory planing or collision avoidance in KRL.
Don't use literals for inputs, outputs, timers, interrupt priorities and the like- name them all in one .dat file. $In[_IDTableVacOk] is a lot easier to read than $in. Then, when changing, you have to change number in one place only, instead of combing through the code and hoping you didn't miss anything.
Similarly, using functions to return base or tool frame is better, since it's easier to remember and impossible to accidentally change them.
TIMER_LIMIT(Time) is great when you need a simple timer in combination with other things that run in main.
E.g. while not $in[_DI_PressOk] or TimerLimit(3)
Another obvious thing, but you can modify workspaces programmatically.
Check the wiring, I suspect robot movement causes some vibration making the wires disconnect for a moment.
Here is an idea- read through the expert programing manual, get the gist of the basics, then come back with a specific question. Maybe someone out there would enjoy it, but there is no point to typing out parts of the manual here when you can just read it on your own.
Well, why don't you use Swrite to create a complete string you want displayed and use that as a parameter for any of the MsgLib functions? If you are this new to programing in general, I suggest first learning some C or Pascal (or some other simple language with strong typing) to understand some basics. KRL is bad as a first programing language