How about something like:
IF IN[1066] == TRUE THEN
WAIT FOR ($MODE_OP == #T1) OR ($MODE_OP == #T2)
ENDIF
How about something like:
IF IN[1066] == TRUE THEN
WAIT FOR ($MODE_OP == #T1) OR ($MODE_OP == #T2)
ENDIF
You can configure your robot such that certain bits are on when the robot is in T1, T2, AUT, and EXT. Set those bits such that the PLC knows what mode the robot is in and then set the PLC-controlled $MOVE_ENABLE bit to be on when in T1, T2, and whatever your conditions are for EXT. See the attachment for an example.
No its not. The tool is lined up with Z axis. Do you want me to put a picture of the setup or anything else to verify this?
No picture necessary. If you say it is, then I have no reason not to believe you. Weird, however, that my quote was edited to make it seem like an unconditional statement rather than a purely subjective one, and upon that you offered "proof" that what I "said" was false.
Full disclosure:
In other words, if the tool is not perfectly lined up with the Z axis, rotating around Y will inherently force some rotation about X.
Oh well. I hope you find a solution.
This is purely speculation on my part, but I'm guessing that your tool isn't perfectly perpendicular with the axis about which you're trying to rotate the tool AND normal to the other two axes. In other words, if the tool is not perfectly lined up with the Z axis, rotating around Y will inherently force some rotation about X.
Just a spitball though, so it could be something else. Good luck!
I would think you could accomplish this by simply block selecting the line that contains the desired motion before putting the robot back into EXT.
Hmm... Not sure either of these will work, but they're the first two things I would try:
1. Shut down the controller. Hook up a monitor/keyboard/mouse combo to the robot controller PC. Start up. If you can access the HMI (which I don't actually think you will) then change the IP address back there.
2. If that doesn't work, through windows, navigate to C:\KRC\ROBOTER\Config\User\Common\VxWin\knet.config and find the following text in the file:
[HostTable]
"Windows" = 192.168.0.1 (I'm thinking yours will read 192.168.1.1)
Change the IP address to the correct address. Save the file, shut down the controller and power it back on. I'm hoping that this file is one of the files that gets read on every start-up. If it is, I think you will be good to go. If not, someone else may have to chime in on how to force a "Reload Files" start-up via the configuration files rather than the HMI.
Good luck!
Put the robot in T1 with no program running. Menu -> Startup -> Calibrate -> Tool -> Tool Load Data.
Select the tool you want to edit.
Uncheck the "Load Data Verification" box on the lower half of the screen. Click NEXT and then SAVE.
Be aware that this may have unintended consequences, particularly if you're running other options like RSI.
What menu items are you trying to restrict? I'll have to look through the code to see if I can locate them.
If you're comfortable with XML, check out C:\KRC\SmartHMI\SmartHMI.exe.config.bak - I was able to change the availability of menu items through this file.
Edit at your own risk. Save a copy of it somewhere before tinkering with it. And as with all XML files, a Reload Files restart will have to be done for any changes made in this file to take place.
Looks good to me!
OP, I think maybe you meant to say "shift?"
Greedy,
Are you sure that will "offset" the tool in the #TOOL Z direction?
I'm sptiballing here: If 'v' is the offset frame, the reference there is $WORLD. The line $tool = $tool:v essentially "shifts" the TCP up, in $WORLD coordinates 4 mm. At this point, LIN xvorpos would reposition the TCP to the original position, thus shifting the whole tool down in $WORLD 4 mm.
Maybe I'm wrong - it would be an interesting experiment to try. Too busy right now...
I don't know what model robot it is, but based on the XHOME position our robots have "out of the box," I would guess that, in order to reach the position of your last move command, A5 will have to exceed its positive maximum value. In other words, A5 will have to be too "folded up" to reach this position. Kind of like how you can't (probably) touch your forearm with your fingers on the same arm.
Execute the module. After the fault occurs, look at the actual value of A5 and then look at $SOFTP_END[5]. If the actual value is at or slightly larger than the system variable, then you know you've reached the limit of what A5 can do. Inserting a middle point won't solve this issue.
DO NOT change the value of $SOFTP_END[5], as doing so may produce unwanted results or damage to your robot.
Another thing you can do is disconnect the SmartPad and connect a monitor (if your KRC4 has an HDMI port). This will allow you to see what the robot is doing without the SmartPad connecting. If there's a boot error in the robot, you'll be able to see it this way.
Our robots have DVI ports on the controller PC. This works as well. Just know that most DVI Ports aren't hot-swappable, so most of the time, you'll have to connect the monitor before you power up the robot.
That all being said, using this method has allowed us to stumble through many failed robot startup attempts.
As an aside, Zeev, you can change the native Smart Pad language. If you're interested, let me know.
Flag evaluations trigger an advance run stop. If the robot is in the middle of a move while this advance run stop occurs, you may see a momentary stop in motion.
Try writing a CONTINUE on the line previous to any IF... statement in this routine.
So it would look like this:
CONTINUE
if $flag[28] then
H1pour8()
endif
CONTINUE
if $flag[29] then
H1pour9()
endif
The CONTINUE forces a continuation of the advance run pointer, thus allowing your motion to continue.
That tick box modifies a line of XML in C:\KRC\Roboter\Config\User\Common\CabCtrl.XML.
The line is:
<TrafoTemp monitoring="off" />
(Of course, if the check box is ticked, then the option is "on.")
We have had success with changing this option inside the XML file itself, eliminating the need to bring the project into WoV just to change one little thing. Just make sure you use lower case letters and remember that the changes won't take effect until you do a "Reload Files" restart.
You can force digital/analog output from the robot in T1/T2 mode with deadman pressed.
Digital/Analoh inputs cannot be forced.
In T1/T2 mode while running a program and for example you have condition "wait for input 1 and input 2" it offers option to "simulate" so you can continue with the program (but it will not force input true) Just simulate the condition to be true.
To clarify, the "Simulate" option is only available while the Start key is being pressed in T1 or T2 mode.
Please copy INI folds from template or another program and paste to your program.
If you want start with LIN command, you can use "PTP $POS_ACT C_PTP" before LIN command
We use this technique at the beginning of many of our operations. The approximation "C_PTP" isn't really needed after "PTP $POS_ACT" in the above solution because the robot stops after a BCO anyway - there won't be any motion blending in this case.
Otherwise, the above suggestions were good, I think. The INI line and a BCO are needed.
Virtual pendant is a great way to take screenshots if you have it available.