Thanks for these expert advices.
I've just checked the KRC2 and there is no LPDN card.
To provide discrete I/Os back on the tool side, downstream the DN signal module of the ATI changer is another issue.
I think I feel more comfortable extending the existing fiel bus right now, even if it means more wiring.
I think DN runs on the MFC card. But I must double check that. Does it make a difference ?
Absolutely, my point is to control the ATI QC310 Master/Slave "coupler" through a (DN or not ?) signal/control module on the master.
I have no DN node/device downstream the ATI coupler (ie. on the tool/spindle side).
I just need to pass a small bunch of I/Os (mainly fo the spindle tool holder sensors).
So my point was exactly this : would it be more simple to wire this as supplementary DN node or to map the 26-pins to supplementary KL terminals on my existing Beckhoff field bus.
If I go through extending my system with DN vs Beckhoff field bus, would you also recommend to go DN for the few proximity sensors I need to wire on my tool stands ?
Hello,
KR500-2-MT + KL1500-3
KRC2 2005
KSS 5.6
Devicenet with 1 BK5250 coupler and several DI/DO/AO modules
We are upgrading our cell for stone milling.
We are moving to a multiple spindle system and we plan to use a QC-310 tool changer from ATI.
The tool changer is controlled through a signal module which can be shipped in 2 flavors :
- "DB10" > devicenet capable control module (mini connector)
- "VB7Z1" > basic pass-through control module (26-pins amphenol cable)
I don't see if there is a preferred way to go : should I integrate the tool changer as a new devicenet device ? Or simply extend my existing I/O fieldbus with additional modules to map the I/O required by the tool changer control module ?
Would you advise one way more than the other ?
Thanks,
Lionel
Hello,
KR500-2-MT / KRC2 ed 2005 / KSS 5.6
+ linear track (E1)
+ turntable (E2)
I'm trying to check the accuracy of RAT_MOT_AX for my turn table (infinite axis).
I have a probe on the table and a probe on the robot. The two probes are almost touching each other.
I've programmed 500 fullturns (robot is not moving) so I can measure a corrective angle to update RAT_MOT_AX.
However, after about 400 turns, I've lost the value of $AXIS_INC[8] (E2).
I think this is because the value has exceeded 2^31 (max value of an INT32).
Indeed :
RAT_MOT_AX N/D = 323,55556
RAT_MOT_ENC N/D = 0,25
AXIS_RESO = 4096
So for 1 motor fullturn I do : 16384 INC <=> 1,112637347°
So for 1° I do 14725,37304 INC
Thus, for 2^31 increments, I do 2^31/14725,37304 = 145835,6024° = 405,1 fullturn.
Can you confirm I'am right ?
How should I read the $AXIS_INC[8] value after 405 fullturns ?
Why the controller can still correctly turn the table for more than 405 fullturns ?
Ok, I got the main cabinet plus an extension cabinet.
In the main cabinet, corresponding to DSE-1, I got one KPS + 7 KSD
In the extension cabinet, corresponding to DSE-2, I got one KPS + 2 KSD. But only one seems to be active (the other one is unplugged and leds are off).
Yes, this is exactly what I was thinking about.
Our milling programs are quite long (from 1 hour to a full day). And the turntable can make lots of turns. It is thus a lot of time to unwind the turntable (the max speed is 8rpm) and some permanent hardware like the EMT or something similar that can help zeroing the table and avoid unwinding it would be great.
=> Is there any type of material/sensor you would recommend to do this ?
I understand that simply programing a motion to the "nearest Zero" and getting ride of the full turns like this :
QuoteDisplay More
PTP {E6POS:E2 0}
;FOLD RAZ Axe E2
$ASYNC_AXIS='B00000'
WAIT SEC 0.5
$ASYNC_EX_AX_DECOUPLE= 'B000010'
WAIT SEC 0.5
$AXIS_ACT.E2=0
WAIT SEC 0.5
$ASYNC_EX_AX_DECOUPLE= 'B000000'
WAIT SEC 0.5
$ASYNC_AXIS='B000010'
WAIT SEC 0.5
$ASYNC_AXIS='B00000'
... is not a good approach as it will cumulate any errors on $ROT_MOT_AX.
Sorry I was confused. It IS a AA robot. And $ABS_ACCUR = TRUE.
Hello,
I am working on KR500-2-MT with KRC2 ed2005 / KSS 5.6.
I would like to know what is the specified accuracy/repetability of the EMT mastering system ?
If doing twice the mastering on a given axis, what would be the expected maximum relative difference between the notch and the spike ? Is there a technical sheet I missed describing this somewhere ?
Behind this, I am thinking of reseting an infinite axis to zero (a turntable in my case) in place of unwinding the axis back to the zero after each milling program.
Ok, I was thinking that this robot was equipped with a single RDC because it has 8 axis. But in fact it has 2 RDCs, one for the robot + linear unit, and one for the table.
I've found the box inside the table and managed to achieve the EMT calibration properly this morning.
Thank you for your valuable help.
Hello,
I am working on a :
- KR500-2-MT with KRC2 ed2005 / KSS 5.6
- a linear unit (E1)
- a simple turntable (E2)
Today I successfully remastered A1-A6 and E1 doing the EMT mastering procedure. Unfortunately, it does not work with the turntable : the mastering gauge passes through the V-notch correctly, the green leds go on/off correctly and in correct order but the process does not stop has it should just after passing the bottom of the V-notch. Unless, it goes on until the HMI says that the limit for mastering has been reached.
I have no ideas why I encounter this problem and how It could be solved. The notch looks fine. The EMT is working fine on the others axis. Any help/tips would be appreciate.
@skyfire :
Thanks for you very detailed answer.
1) This is not an AA robot. We're stone cutter and something like 1mm absolute accuracy in a 1m3 volume centered on the rotative table is enough. So far it worked well enough in terms of accuracy, for what we do here of course.
2) Yes you're right. The marks indicate the PRE-mastering position.
3) Oh, I understand now why the mastering process passes a little beyond the mechanical zero (bottom of the V-notch). Do you know how the "bottom" of the V-notch is evaluated ? (I suppose this is based on the slope of the notch, because the needle does not look very sharp).
4) Understood
5) To what extent do you think the effect of the payload on mastering has a negligible influence on the (absolute) accuracy of the robot ?
I am still wondering :
Where is the mastering offset stored ?
Is there a system variable for that ?
How is the mastering offset loaded for each tool ?
At the moment we are using a single spindle for all our tools (from very small mills to large steel discs). We're planing to have several spindles (one for small mills, one for medium mills and one for large discs). These spindles will be changed with a Staubli MPS 630 system. The heaviest spindle + tool will weight about 450kg.
=> Would you advise to ignore the effect of the payload and share one mastering for all configurations ? Or should I have one tool for each spindle with proper mastering offset and LOAD_DATA ?
massula :
Oh great, I didn't know that. I found the Mastery.log file. Thank you for the tip.
Hello,
KR500-2-MT (KRC2/KSS5.6)
After reading several times the manual I am still confused about the purpose of the (EMT) mastering process and the impact of the payload on the mastering. Would someone confirm my understanding ?
A) The robot is moved near the mastering position by the operator. For that there are markers on the robot, one for each axis, and when all markers are aligned properly the robot is in its mastering position. For my robot, this position is the inverted L-shape $MAMES={0, -90, 90, 0, 0, 0}.
B) Using the EMT (or dial gauge), the robot is then moved very accurately to the mechanical zero position, successively for each axis in ascent order.
=> Thus, for each axis, the controller now knows what is the value of the motor increment corresponding to the axis angular value given in $MAMES ({0, -90, 90, 0, 0, 0} in my case).
I see mastering as the process of perfectly aligning the zero of the motors with a given mechanical position.
1) Does the payload influence the motor increment values at the mastering position ?
=> My intuition is that if the payload is heavy it deforms slightly the robot parts. Thus, to reach the same mechanical position with different loads we need to compensate a little on the motor increments. The compensation will be different from one load to another and this is the purpose of teaching the calibration offset for each load.
=> is there more math involved at the controller level than "simply" offsetting the motors zero position ?
2) Where is the mastering offset stored ? Is there a system variable for that ?
3) How is the mastering offset loaded ?
For instance calling BAS.Tool(tool_no) will set :
$ACT_TOOL = id
$TOOL=TOOL_DATA[TOOL_NO]
$LOAD=LOAD_DATA[TOOL_NO]1) I am working on a maintenance plan so it's good to know what is precisely behind $ROBRUNTIME and the manual is visibly misleading.
2) I am developing a service that sends notifications when a src program is about to finished. The src programs are generated with Powermill and I get an expected simulation time from it. This simulation time is hard coded in the program when it is exported (postprocessing). My service reads this value when the src program is started and tracks the progress time of the program. The progress time must be 'normalized/weighted' to take into account the current $OV_PRO. When the progress time is about to reach the simulation time (lets say 5 minutes before) a notification is send to the operator.
=> So I was looking how to build an accurate progress time. I was thinking of $ROBRUNTIME but now I think I would better write my own counter timing when PRO_STATE1 == #P_ACTIVE.
=> So the question is still open 
What is the condition for $ROBRUNTIME to count ?!
Well, I still don't fully understand what you are saying.
See my screenshots : the "I" is green (PERI_RDY = true), no program is selected by the robot interpreter, and $Robruntime is idle (at 55809).
So you said "I is green" <=> "drives are on" <=> "$ROBRUNTIME is counting".
But I see that in some cases "$ROBRUNTIME is NOT counting" when "I is green" ...
What am I missing there ?
I am on KSS5.6 / KRC2ed2005
Ok,
So "I" in "SRI" is green when $PERI_RDY = true ... and the question remains fully open.
Indeed when $PERI_RDY is true the $ROBRUNTIME counter can be stopped (for instance if no program is selected).
So the manual (KSS 5.6 END V1 en p67/185) is possibly misleading :
Quote
Operating hours. The operating hours meter is running as long as
the drives are switched on. Alternatively, the operating hours can
also be displayed via the variable $ROBRUNTIME.
So what is the condition that makes $ROBRUNTIME count or not ? Could it be :
PRO_STATE1 == #P_ACTIVE && $PERI_RDY == trueHello,
KRC2 / KRR5.6
The manual states that $ROBRUNTIME gives the cumulated amount of time when drives are switched on.
But I could not find how to determine when drives are effectively switched on in the manual.
I've looked at $DRIVES_ON (pulse) and $PERI_RDY but it does not seem to be correlated as $PERI_RDY could be true while $ROBRUNTIME counter is stopped.
Can someone explain precisely how is $ROBRUNTIME computed ?
Would the time when PRO_STATE1 = P_ACTIVE be a good approximation ?
Nota : my goal is to compute a weighted value of $ROBRUNTIME (weighted by $OV_PRO).
Thanks,
Lionel
Hi Joan,
I am facing the same problem because I am french and I need to display messages in french (see my post here https://www.robot-forum.com/ro…ters/msg123606/#msg123606).
I finally managed to leverage the message database that you can find in KRC/DATA. I now know how to create a new database, register it in the windows registry and use it to display your own messages from Set_Msg / SetDlg in a KRL program in the language of the KRC.
This solution works only for messages. And because I am working on a KRC2 and don't have access to a KRC4 I don't know if this solution is reproductible on a KRC4. Apparently messages are now stored in a xml file but the the access layer is probably not different.
In my opinion, If you want to localize your messages this is the only serious solution you have. Or you'd better drop the idea to display messages with accented char.
If you want to test this solution, I can set up a small (KRC2) tutorial. You'll have to dig in your self to see I you can do that on your KRC4.
Let me know if you are interested !
Hello,
I have recently proposed a patch/update for the great KukavarProxy from IMTS : https://github.com/OpenKuka/KukavarProxy
I am working on a C# rewrite of this tool with enhancements.
At the moment, I only have access to a KRC2 with KSS5.6.
However, I need to inspect a KRC4 with KSS8 system to achieve my goal.
Would someone be able to share (in private of course) the copy of its KRC/ folder for such a system ?
It would be a great great support for me.
Thanks in advance,
Lionel
Hi Spirit532 thanks for your remark,
I agree that version-specific related info should be addressed by such a tool.
At the moment my proposal don't deal with it but I would be happy to listen to suggestions on how to take account for that.
I don't think this is too much work to implement a small filter to hide/show version-specific data.
Internet is a huge mess of (related) informations. But thanks to search engines you can get really fast access to informations. And indeed, it is probably faster for you to google "kuka system variables" to get the corresponding pdf (with a decent internet access) than browsing a 3-levels folder hierarchy on your laptop to get that exact same file !
So I still believe that there is no comparison between something like XPert and a html documentation, much more powerful in terms or searching, indexing and cross-referencing. That said, XPert is a great place to get up-to-date and version-specific official pdf manuals.
Please, try this page https://openkuka.github.io/krl/reference/system.variables/ and let me know if you feel that browsing is more comfortable and efficient on this page than with the good old "System Variables pdf".
Please, note also that my proposal is not to document everything on every subject about kuka... but mainly to provide better access to the language reference. Not to mention that many language functions / variables are not documented at all.
Well, clearly not the same.
I've checked your ref (thanks for sharing it) and it is more like a search engine to get a more rapid access to ... the same pdf documents we all know or datasheets.
Not to say it is 550€ a year. So you buy a 100k€ robot and they (intentionally) let you struggle with poor docs. Probably to sell more training and services ...
HTML doc is much more powerful as browsing and indexing is much more performant than in pdfs. You can also leverage cross ref.
You can see it more like a wiki. It's very complementary with the forum. You can start little and grow it with people contributions.
The website I propose is based on Mkdocs. The website is build from a bunch of markdown files (easy to read/write for every body) and simple YAML files for describing KRL types, variables and functions. Thus, it should be easy to contribute for anybody.
My proposal is to focus on KRL :
* system types (enums / strucs)
* system variables / signals
* system functions
And eventually have a sort of up to date "primer" like the expert programming manual.
