K-ROSET Lite Help!

Good man....glad the hints helped......

My test program is made up of many subroutines and is by far not complete or debugged as there are more things I wanted to do (but ran out of time), but it is not what I would class as a 'novice program', as I do not use a single global variable, I only use local variables which I pass through between subroutines, so error checking is always difficult.

I very rarely post any full code, just snippets as it's easier to follow.......However, I've attached the complete file save so you can dive into it and see how you get on.

You can load this into KROSET (LOAD tcp_client_v2.txt) and then just execute it as a PC task......eg..PCEXECUTE 1:tcp_main and the program should run.

See how you get on with it and if you have any questions, comments then let me know......but trust me, it is not a complete solution.

That number relates to how many times that program has been executed and completed.
- That number will only increment if the program gets to the end.
- If you have a goto at the end, then the program never completes, so the counter will not increment.

This number will not prevent it from loading into the simulator/controller/have an adverse effects except if you try and load it into a D or C Controller (those versions of controllers did not have that feature, and therefore will reject it if you try and load in).
You could just delete them from the filesave and it will load in no problems too.

Yes, I can't direct to where/which manual it is in......so I think it is not documented.

ah so you need to do some further reading on this......

The 2 Program windows you can see on the terminal are:
1. Main Motion Routine Area (can contain any program command/instruction).
2. Process Control Program Area (PC - Motion instructions are prohibited from use).
- That includes any CALLED subroutine which contains a motion instruction like HOME

However, simply put you can use monitor commands that allow some instructions by using the prefix of MC.
- In the Terminal, if you type in HELP/MC and enter, you will see a list of the common commands available.

If you wanted to load/prime a program into the main program window you would write from the command prompt:
PRIME program, cycles, step no.
If you wanted to load/prime a program from a PC Program, you would write in the program:
MC PRIME program, cycles, step no.

If you wanted to turn on or off the motor power you would write from the command prompt:
ZPOWER ON, or ZPOWER OFF respectively.
If you wanted to turn on or off the motor power from a PC Program, you would write in the program:
MC ZPOWER ON, or MC ZPOWER OFF respectively.

Also you have other variations which you can include in a PC Program such as:
MC HOLD - to hold the robot motion.
MC CONTINUE - to continue the robot motion.
MC EXECUTE - to immediately execute the program.
MC KILL - Clear the main program stack.
MC SPRIME - to prime a String referenced program, cycles, step no.

So you could write a simple PC Program to PRIME or KILL a program (and this is just an example of function).

.PROGRAM testprime.pc()
IF SIG(2001) THEN
MC PRIME test1
ELSE
MC KILL
END
.END

If the internal sig 2001 is on at the time of execution of the PC Program.....it will prime the program commanded in the main program window.
If the internal sig 2001 is off at the time of execution of the PC Program......it will empty the program stack (remove not delete from the window).

Nice progress..............

What you are saying about the SETHOME is exactly correct, the same is applicable to many other commands too, like POINT and HERE.
Look in the AS Manual and you will find these commands have more than one function.
SETHOME is a Monitor command AND also a Program Command.

When you type that command in the terminal window on its own you are using it as a monitor command, so what you are asking the controller to do is RETURN (Display those values)......nothing else, the 'question' you get is a function of the command being used as a monitor command.
However, if used as a program instruction, then there is no function applied to the command in order to display the terminal window and wait for a user input.

Absolutely possible, just depends on how you look at it (I've never done it though), but just looking at the fundamental of the received message.
- The received message is just a packet full of ASCII values.
- So simply you could decode the string and if it contains a specific ASCII value(s) then a simple PC Program containing the $DECODE command and a couple of IF statements which contain the motor power on and possibly MC EXECUTE/MC CONTINUE and the other IF for motor power off and MC HOLD/MC ABORT.
- Remember though, on a live robot, you would need to consider the safety factor and therefore manage it effectively, but in simulation you can test the process.

So, a little bit more reading for you - $DECODE........in the AS Manual there is a very good example in decoding a string and pulling the relevant information out.

I just had a quick thought without using $DECODE and do a quick test with that program you have from me.
I've just squirted something additional as a quick test into the tcp_main_recv program to toggle motor power on and off via the commands:

Motors On
Motors Off

Very simple, so you could do something similar, have a look at the attached video and also the program attached (compare it with the other on to see what I've added)......just replace the existing subroutine with the attached one and type the above commands in Hercules......case sensitive, so EXACTLY as it's written above.

As I say just a quick test, not what I would do as an application, but gives you something to tinker with........

Good man...…...

Yep, you don't need the send part of it, if you are just going to 'connect and be driven' by messages.

Hi

1) 'Login' is just 'as' (lowercase and without the apostrophe's) - this is the same throughout all Kawasaki Robots when using a TELNET connection.

2) Yes, the code would assist me in trouble shooting that as SOCK ID 0 can be a number of things.
- I have ONLY seen this when using the Kawasaki as a server and Hercules as a Client.
- But I've always thought it is related to the fact that 127.0.0.1 on a PC is basically accessible from anywhere, so I think the Kawasaki gets a 'false' connection handshake. (like an auto connect) from the software without being able to bind correctly and results in a '0' for the SOCKID...which is not valid, but I've never got to the root of this.
- If you use an actual Controller with a different IP such as the usual 192.168.0.2.....then it doesn't seem to occur.

*** The code in the TCP Manual is not the best for an example of a working program ***

Cheers for that, I'll take a look and let you know.
- Don't worry about 'primitive code'.....all programs can be written with many interpretations, if you can understand the mechanism and flow then whether a program is complex or simple....if it does what you intend then it's valid in my opinion and a success.

I'll also try it connected to a live controller too........

...................Ah I didn't quite read your post correctly.

Port 9105 accesses the Terminal Editor.
- This is directly connected to the Controller as the Command Line Interface.
- Hence the login/command prompt.
- If you change the PORT No. in your code and on Hercules to something like say 12345 and try it.
- Also, in your tcp_recv you have spelt a variable wrong, max_lenght...........should be max_length.
- Also in your tcp_send, you are passing in undefined parameters, so it errors out, so could do with looking at that as you can't exit without error unfortunately...........But I'll let you resolve that.....

However, it does successfully connect and receive as you can see in the attached clip.

One suggestion though, whilst your playing around with it, if you do get ANY errors that forces the program to abort, it means the socket will not have closed and if you just reset and attempt to execute it, you wont be able to create a socket.
So have an autoclose program so during your testing if you get any errors....then just squirt the auto close program before you run your main comms routine.....

I have attached my 'squirt' routine for you and included the CALL to it at the start of your main routine to help you.......
- It runs silently at the start and wont impact on any of your code you write............

But well done...............