Advertising

Posts by SkyeFire

    Loss of Mastering does not prevent jogging the robot in Joint mode, although it does prevent jogging in any Linear mode (World, Base, etc).


    Your screenshot shows you are also missing General Motion Enable. That is probably what is preventing the robot from jogging.


    Also, WorkSpace Monitoring depends on having valid Mastering. It's possible that, if you have a Workspace configured to stop the robot, you may have to override the WorkSpace Monitoring temporarily (there's a menu function for it, you don't have to edit the WSs) in order to jog to Mastering position.


    It's also possible that, whatever external device is providing your General Motion Enable, it may be looking for the WS signals, if you've set the system up that way. In a pinch, you might simply change $MOVE_ENABLE to 1025 (in the Automatic External I/O configuration) temporarily in order to jog. Make sure to change it back to the correct input before going back into production, though.

    As Panic says, it sounds like, in Teach mode, you are running the program differently than it runs in auto -- you are either hand-selecting a subroutine that would normally be called by a higher-level "main" routine, or you are hand-selecting a line and skipping the INI fold, which is where the INTERRUPT 3 declaration is usually located by default.

    BRAKE, not BREAK. But, aside from that, Mentat is correct.


    You want to pay special attention to the program structure -- when the RESUME command is used, the program pointer jumps to the stack level where the Interrupt was declared. This will drive your subroutine -- usually I use a three-level stack: the "main" routine where the Interrupt is declared, and which calls a motion subroutine which contains just the INTERRUPT ON command, and calls the motion routine which contains just the INTERRUPT ON command, and the motion from A to B, and the Interrupt Service Routine (ISR), which the Interrupt calls. Inside the ISR, BRAKE halts the robot motion, but the RESUME command (which is badly named) is what cancels the active motion -- without the RESUME command, the robot will simply resume the interrupted motion where it left off. If the RESUME command is executed (RESUME is only allowed inside ISRs), the program pointer will jump back to the main routine, one line after the call to the motion routine. This happens even regardless of how deep the calling stack is, which is why it's so important to be careful at what level you declare the Interrupt, and at what level you use it.


    The "motion" routine also needs to end with some command to break the Advance Run Pointer, like a WAIT FOR TRUE. Otherwise, the ARP can get back to the Main routine before the Interrupt is triggered, which will cause errors. This does mean that you can't end an interruptable routine with a smooth approximated "flow" into the next move, which is another constraint to keep in mind.

    Hello, Could please you give me some more information please how to achieve this?


    By soft you mean that it allows for wiggle room? How does this affect the accuracy of positioning?

    Look up $TORQUE_AXIS. This is useful, but has definite limits -- for one thing, it should not be used on A2 or A3, because it's liable to make them "sag" under gravity effects. And its use on A4-A6 is highly situational.

    A Trace should be able to trigger any general fault state -- basically, "if any system fault is active, trigger".


    Setting the time divisions up to record slightly "upstream" of the trigger event, as well as downstream, should let you get very good data for how long each axis takes to come to a full stop.


    One caveat: you'll need to test this with the actual working payload, at the safety-limited speed, and do multiple tests at different robot poses, because the stopping time will change. Hopefully, the safety-reduced "yellow zone" speed will reduce the variance you see in the stopping times, but you need to carry out tests to confirm this. And, of course, use the worst-case stopping time for your safety distance calculations.


    The test needs to trip the robot safeties in the same way that the safety device will -- the difference between Category 0, 1, and 2 stops matters here.


    You also cannot ignore A4-A6. They can take surprisingly long to stop, especially for a heavy payload with a CG well out from the faceplate.

    Doesn't 3d vision have an option to limit that angle automatically? So you don't do calculations yourself? 2d vision from fanuc does.

    I'm not using Fanuc vision, it's a 3rd-party system that can intelligently identify boxes in a stack.


    Are you using a linear or joint move?

    Joint to reach the "Above Pick" position -- basicially, the PR from the vision system, plus a World Z offset. From the "Above Pick" to the "Pick" is a Linear.

    Finally, if you confirmed the problem is related to configuration, you may need to write programs to manually/automatically set configuration filed of P[n] or PR[n].

    Thanks, I'll look into that too.

    There's an option MROT which should do what you want, it should be free, but needs to be activated, at least that's what Fanuc told me, in the mean time I solved the problem otherwise

    Hm! I'll look into that, thanks.

    Being a Fanuc newb, I need a bit of help here.


    I'm using a 6-axis Fanuc in a depalletizing fashion, to pick boxes from a pallet. I have a 3D vision system to get the coordinates of what I'm picking, which provides me a PR containg X,Y,Z, and Rz of the center of the top surface of the box (Rx and Ry are always 0). That all works fine.


    The one fly in the ointment is that, because I'm picking up rectangularly-symmetrical boxes, there's no disambiguation for Rz -- if the box is rotated 45deg, the Rz value I receive could be 45, or -135 -- it's literally 50/50. Now, to protect the cables and hoses, I want to limit the Rz angles the robot uses to (for example) -90 to +90. Since my end effector is also rectangular and symmetrical, all I need to do is line up the long axis of my end effector with the long axis of the box -- I don't care if I pick it up 180deg "wrong".


    From my previous experience with other robot brands, this seemed simple enough: use some IF statements to add 180 to Rz if Rz was less than -90, or subtract 180deg if RZ was greater than +90. Well, the math works, but the effect on the robot's motion is not what I expected. Despite limiting the Rz value of the PR this way, sometimes the robot simply decides to go "the long way around", even though the shortest route (in joint space) from its starting position would be the other alternative.


    What I expected was that, given my unambiguous JPos starting point, the path planner would choose the shortest joint-space path to the Vision location in the PR, but that's not happening.
    I'm guessing that I'm running into some sort of conflict between the Cartesian coordinates and the Configuration settings. But I don't know enough about how Fanuc path planning works to say for certain.


    So, my questions:

    is there some other cause for this behavior that I need to look into?

    If I'm right about the Cartesian/Configuration conflict, what's the best way to handle it? Can I "remove" the Configuration values from a motion command, such that the path planner simply chooses the "least motion" path?

    Can I do any of this in TP, or would it require KAREL?

    Every channel has its own coding. In Ye Olden Days, when single-channel safety was normal, it was possible to jumper out a safety with a single piece of wire. Then dual-channel safety was implemented to make this harder, but there were careless/lazy/cheap people who would wire a single-channel device to both safety channels. So, the pulse-coding was added to uniquely ID each channel. Cross-wiring the two channels would generate a fatal safety fault.


    For a modern safety-rated device, each channel has its own "transmitter" and "receiver," and the only way to satisfy that channel is for the receiver to see its own transmission come back to it with no lag or delay. So even if you had another device that used the same pulse frequency, getting the phase match would be exponentially more difficult and expensive than just wiring the circuit properly in the first place. The entire idea is to make it so difficult to "cheat" that people will bite the bullet and do it correctly.


    So, for a dead-simple E-Stop circuit, you would simply use a dual-contact switch, wire the Test-A to 1P, E-Stop A to the upper 2T, and leave 1T unwired. Do the same for the B signals on the lower half of the switch diagram.

    Of course, using a switch like this for safety is entirely illegal, but this was the easiest-example diagram I could find quickly.

    517edbabce395fd51d000000.png
    One additional wrinkle: modern safety devices check for any lag between the channels, and cheap switches/relays often have too much time difference between the contact pairs. Safety-rated devices are guaranteed to have less lag than the safety standard (I want to say 20ms, but I could be wrong). This is, again, to make it harder for someone to "cheat" the safeties with a couple wires, or trying to use two non-safe switches in parallel.

    What I don't fully understand is why "Peri enabled" is considered a mandatory signal. I'm not trying to correct the diagram, but to know what information it gives and in which scenarios it takes part.

    This is the robot output that the robot servos are active/enabled. This, for example, can detect if someone is enabling the servos with the pendant enabler when the robot is in Teach mode.

    Can you connect two safety outputs of the PLC directly to X11.2 and X11.20 without using a safety relay to connect them to Test Output A and B?

    Not for most typical PLC outputs. The Test A & B signals carry pulse-coded IDs atop their 24VDC "baseline" values, and are intended to be used with "dry contact" closures, with the Test A signal passed back to the "A" channel safety input, and ditto for the "B" channel signal -- simply sending a 24VDC signal from a PLC will not satisfy that. However, some PLC output cards are designed to act like relay contacts (particularly safety-rated I/O cards), and those should be compatible.

    If I try to acknowledge it I get an additional warning...

    Are there any limitations as to what can be confirmed with the PLC ?

    That additional warning is "Active Mode Required," yes?


    Yes. I don't have a comprehensive list, but collision errors generally can not be reset remotely. There are some others. The underlying reasoning is that certain errors should require someone to physically come to the robot and resolve the root cause of the error "hands on."

    You would need a KSS 8.3 image built for that robot's hardware configuration. Generally this requires getting a fresh KSR image from KUKA, and installing it using a KSR stick.

    When the robot was first powered up, did it work correctly?


    Did you download the active project from the robot, make your changes to that project, then Deploy back to the robot? If you attempted to create a project "raw" in WV, that's just asking for trouble.


    If the latter, I would recommend reverting back to a good backup, then downloading the active project, save it under a new name, make changes to the new copy, then Deploy. That should avoid these kinds of issues.

    Oooo... that's interesting. I'll have to look into that in more detail when I can.


    Given that I was kind of in a hurry yesterday, I punted -- I changed my divisor for $FAST_CLOCK to a Register I could manually adjust while the program was running, then pulled up Google Dice. As long as I "inject" a new random number 2-3 times per 25-part run into my algorithm, it seems to get me full coverage.


    ADDENDUM: so, I "found" some time :pfeif: and implemented that algorithm.


    Since I'm trying to end up with a random value between 1 and 25, I ended up needing to multiply the algorithm output by 26 (to get 25 at the top end), and upped the 3.8 multiplier to 3.95 in order to "push" the lowest value down to 1. There's probably a more elegant way to do this, but I was in a hurry.


    Also, I found that if I reset the register to 0.6 at the start of every run, I would get an identical series of "random" values between 1 and 25. So, I had to set the "seed" once, and let the final value of run X carry over to "seed" Run X+1. Definitely puts the "pseudo" into pseudo-random. :icon_mrgreen: But so far, it appears to be random enough for my testing purposes. So, thanks again for that.

    Reviving an old thread, but I'm completely stuck trying to get this function to work. I need to get a random number between (and including) 1 and 25, but I'm having no luck.


    First, I took the 0-9 example above, and broke it down into individual steps, like so, so I could see what each step was doing:

    Code
    R[21] = $FAST_CLOCK
    R[21] = R[21] / 10
    R[22] = R[21] MOD 1
    R[22] = R[22] * 10
    R[22] = R[22] DIV 1

    Now, this seems fairly straightforward -- FAST_CLOCK is an integer (in milliseconds). Dividing FAST_CLOCK by 10 produces a floating-point number whose last digit is changing rapidly. The MOD 1 removes the integer portion, leaving merely the fraction. Multiplying that fraction by 10 produces a floating-point value between 0 and 0.99. Multiplying by 10 produces a floating point value between 0 and 9.9, and the DIV 1 strips off the fraction, leaving an integer between 0 and 9.


    But on my robot (R30iB Mate Plus, running version 9.3), this doesn't work. If I use the code as shown, the result of the MOD 1 step is always 0.


    So I tried changing the /10 to /100. That seemed to work, in that the results looked a lot more random during manual testing. But the more I tested it, the more I saw that the value seemed to just settle on 2 or 3 values, and never really randomized among the others. And this was with me hitting the FWD button at random intervals, so it shouldn't have been a "beat frequency" between my test loop and FAST_CLOCK.


    Changing the *10 to *26 made things worse -- 90% of test cycles returned 15, about 5% returned 19, and another 5% or so returned 3. No matter how many test cycles I ran, I got these same results.


    I've had the test code running in a continuous loop for an hour straight, now, and it just keeps throwing those same numbers over and over.


    The actual code, straight from the robot backup:

    The Flags 101-125 are keeping track of what positions in my 2D grid are occupied, and which have been emptied. The random number decides which grid position is emptied next. So, as my grid empties, I would expect that it would become progressively harder for the random generator to find valid "hits" in between 1 and 25 (or 101-125, whichever). But I have 8 occupied positions in my grid still, and a full hour of looping this code has never "landed" on any of them. Obviously, this algorithm simply does not generate even remotely random numbers.


    The WAIT 0.83sec was added after I started seeing this pattern, in an attempt to force different results from the timer. It didn't make any difference. Repeatedly stopping and starting the program manually didn't make any difference either. Changing the WAIT to different times had no effect either.


    I'm seeing a consistent pattern of 3,6,9,12,15,18,21 -- the pattern is obvious, it's all +3. But nothing I do seems to have any effect.


    So, am I just doing something stupid that I haven't been able to figure out? Or, does anyone have any suggestions as to how to improve the "coverage" of the random number generated?

    I send robot from start pose to goal (only 2 poses) with LIN motion. Distance between them is ~3m and ~90 deg (complex rotation A+B+C angles). No smoothing. Velocity is 150 mm/sec.
    I get ~midpoint from robot while motion to goal pose. And also I calculated all trajectory outside the robot (C++ program). Linearity of XYZ is the best. But orientation interpolation is similiar to slerp but not identical (max difference for my case is 8 degrees).

    First, post actual program code.


    Second, what exactly are you trying to measure? If a LIN motion is programmed for a 90deg rotation, then it will be rotated by 90deg at the end of the motion. Are you measuring actual motion in free space, or just looking at the position monitor on the pendant?


    What "midpoint"? Are you claiming that the rotation distribution is not even across the linear motion, or that the TCP does not rotate 90deg in total?

    Cartesian position has no valid value until a Base and Tool are activated.


    Matching the white witness marks is not valid for Mastering -- those marks incorrect by several degrees. They are intended to be used as the starting position for the EMT motion.


    The EMT works by engaging the mastering gauge (spring-loaded pin) on each axis, and dragging it slowly across the Mastering Target (small flat-topped conical feature with a precise V-notch machined into the top). The pin and the V-notch are machined to match.


    So, the "emergency" method for Mastering without an EMT is not to line up the white marks. It is to use a small plastic (not metal) in place of the EMT to perform the mastering by feel. Start by lining up the white marks, and know that the actual mastering position is in the axis's negative direction. Uncap the mastering gauge, and use the plastic tool (pen, toothpick, stylus, whatever) to push the center plate inward -- this will cause the pin to extend. Very slowly, jog the axis in the negative direction until the pin contacts the outer edge of the target and begins climbing the slope. Keep going until the pin achieves the flat top of the target, and then falls into the V-notch. The actual Mastering point is when the pin touches the very bottom of the V-notch, and you will need to keep mild pressure on the gauge in order to feel this happening. It may take more than one attempt to avoid overshooting. Also, make sure that you always move in the negative direction. When the axis is stopped with the gauge pin exactly touching the bottom center of the target V-notch, use the Dial Mastering for that axis.

    In KUKAbots, these are Workspaces and Axis Workspaces. Defined by the system variables $WORKSPACE and $AXWORKSPACE.


    Should be in either the Programming 1 or 2 manuals in the Manauls Software & Tools sub-forum.