It's impossible to answer this without more information. Controller? KSS Version? What kind of I/O card is it?
The short, uninformed answer is that the robot needs to be configured to talk to your I/O card via Work Visual. Once that configuration is complete and operable, you should be able to see your output over your network. And no, you don't need any option package for this, generally speaking.
When using GUI mode, you must connect a monitor, along with a keyboard/mouse combination. Depending on the controller, you may need to open up the cabinet. The pendant WILL NOT connect, as the recovery stick has a bootable Windows installation that runs instead of the normal robot software.
The first thing I see is that your variable msg[] is declared as a single character. You will have to declare this as a character array of some size - maybe 40 characters?
So instead of
DECL CHAR msg[]
it should be
DECL CHAR msg[40] (or whatever length you require)
Even with it only being declared as a single character, you should still see it populated with the first element of the message text. Unless the first character of the message text is always a space...
Glad it worked out for you! I'm not familiar enough with the WinCE settings to speak intelligently on how the backlight settings might affect your application.
Hmm,
The SmartPad runs a version of Windows CE and there are some display and power settings that you can play with, but do so at your own risk. I'm not willing to play with them on any of the robots we have.
To access, hook a keyboard up to the SmartPad. Turn the mode select key switch and hit the 'Windows' key on the keyboard. The WinCE taskbar should pop up on the bottom of the window. Tap in the lower right corner and you should have the option to display the desktop. This will be the WinCE desktop running directly on the SmartPad, not the RDP'd display of the Win7 session running on the controller. You should be able to find the settings there. Let us know what you find out!
Panic,
For one reason, screen burn. I've seen it with robots after not running for very long at all (a matter of months...) I'm sure there are other reasons.
The first thing I notice is that the Input and Output Sizes are configured differently between the robot and the PLC. That size should match. You've got the robot configured for 32 bytes and the PLC configured for 256 bytes. Take care of that issue first. The other thing that may cause an issue is the Scanner IP Address in work visual. If I remember correctly, you'll want this set to the PLC IP address. I may be wrong on that - I can't remember off the top of my head.
If I remember correctly, the Workspace Monitoring simultaneously monitors both the active TCP and the flange. If either of those points violates the settings of the workspace, then the corrective action is taken. Could it be that your flange is outside the workspace while the TCP remains inside?
I don't like that element of the workspace monitoring, as it forces one to open up Cartesian workspaces to accomodate the actual working tool, but I haven't come up with another way around the problem. I wish at least it were a setting one could toggle.
Try setting $APO.CDIS to 0 (zero) prior to your move. This will force the motion to be executed without approximation. Remember though that if you do this, each ensuing motion command will respond to this variable as well. So you may need to reset it back to some other nonzero value after your LIN REL command.
Glad you got it figured out! 
Display More
Use the SIGNAL command to declare the outputs in $CONFIG.DAT.
SIGNAL TEST $OUT[22] TO $OUT[23]
Then TEST acts like a 2 bit word.
1=Out 22 is true
2=Out 23 is true
3= both true
Posted with Tapatalk
That seems like a lot of work - having to keep track of integer representations of how he would want his outputs set. I would probably just add a section to the SPS that monitors your variable and sets the individual outputs to match it.
Inside the SPS loop...
$OUT[22] = TEST
$OUT[23] = TEST
...
$OUT[N] = TEST
When TEST goes false, all affiliated outputs go false. When TEST goes true, all affiliated outputs go true.
Menu > Startup > Service > Maintenance Logbook
Create a logbook entry for the basic service. In my experience, every robot comes from the factory like this. When you create the log entry, it will start the clock on the next service due.
Have you tried changing A6 to an endless rotational axis? I'm not sure if this is an option on the KRC2, but I know it is on the KRC4.
Just make sure you do this outside of the Submit loop!
If I were to run into this problem, the first solution I would try would be to pass the cartesian values into the INVERSE function to convert them to a series of axis values. Then, take that solution and run it through the FORWARD function to re-convert it to a cartesian solution, complete with S and T values appropriate for the axis solution.
See the attachment for more details.
In the config.dat file, if you initialize the value of an output, it will maintain its value after a restart.
Example:
$OUT[1] = *VALUE OF YOUR OUTPUT*
Holy smokes I forgot about this thread! We've been pretty busy with setting up some new cells. Thanks everyone for getting back to me.
Regarding our particular application for this requirement, we don't really have one. I was developing a Fanuc application where we used a Background Task and that got me wondering about how to do it with a Kuka.
The state machine programming in the SPS sounds like the best way to go for us since we don't have any 8.3 robots yet.
Thanks again!
What do you want the robot to do once it gets there?
I think foliagelx was close, but I'm not so sure it would work the way you would like it. In KRL, Timers are simply system variables with an index number. I don't remember off the top of my head, but I think there are 20 of them by default, thus the index number.
First of all, KRL timers operate in milliseconds. Second, yes, his/her code would wait for the specified period to expire and then check your input.
All of that being said I think you could adjust that code and get it to do what you want it to do. I might try something like this:
$TIMER[1] = 0 ;resets the initial value of the timer to zero
$TIMER_STOP[1] = FALSE ;starts the timer
WHILE $TIMER[1] < 10000 ;Cyclically evaluates the timer until 10 seconds has passed
IF $IN[YOUR_INPUT] == TRUE THEN;If the value of your input becomes true, jumps out of the while evaluation
GOTO ACTION
ENDIF
ENDWHILE
MSG_NOTIFY("Enter your message here.") ;If the timer expires before the input comes true, this line will generate a message.
HALT ;stops the running program
ACTION: ;If the Input comes true before the timer expires, the GOTO statement will jump to this line.
;Enter code here for whatever you want to do when your input becomes true.This was something I just threw together without testing, so your mileage may vary. Give a try and see how it works. Let us know.
Edited to include the proper syntax for the IF statement.
Hey all - I'm hoping I'm just overlooking something really simple here. Fanuc allows for multiple asynchronous tasks to be executed using the "RUN" command. This allows for logic handling in the background without interrupting the active robot program. Is there any way to do this with KSS that doesn't involve the SPS? We have an application where we need a background task handler that would include some WAIT statements, so obviously I don't want to call those in the Submit Interpreter. Anybody have any ideas? KRC4s with KSS 8.2.
