I just tried with a switch and I can establish communication.
The switch is tested and works fine.
So what does this mean exactly?
I just tried with a switch and I can establish communication.
The switch is tested and works fine.
So what does this mean exactly?
I just tried with a switch and I can establish communication.
The switch is tested and works fine.
You can then make save and loads if you have a connection now.
So make a file save and attach it to a post, then I'll check the serial stuff and modify it to work and then you can load it back in.
No need to use a floppy then.
Could a sysini fix anything?
I wouldn't advise anything like that until you can get a backup.
I thought you'd mentioned that you'd had previous experience with Kawasaki Controllers?
There is of course a possibility the port on the CPU board is faulty.
In which case I would ask the supplier about whether they tested them as it stands, the only way of saving and loading data is:
- Get a Kawasaki Floppy drive unit.
- Using PCMCIA cards.
PS: original network configuration in the C controller is 10.31.52.150 // 255.255.255.0 // 10.31.52.1
They are 100% ex jaguar spec then.
So... how do i make a backup with a pcmcia?
Is the card placed in the teach? What command do i use to make the backup?
PCMCIA plugs into the slot in the teach pendant.
Use Aux Function 10 (Memory->PC Card Save) and 11 (PC Card->Memory Load).
I have used the cable between 2 computers and I have a ping response from the command console.
So my net cable is ok.
Do you know how many times I have heard that, and then I arrive on site, plug my cable in and it works straight away using the existing IP configuration in the controller.
Not that I am dismissing what you are saying.
Try a patch cable and go via a switch, that will confirm things whether the port is working or not.
This robot is winning the battle for me...
Life would be boring if she always danced when asked.
IP settings appear ok to me.
What application are you using?
Have you set the relative IP address in the connection list and selected the correct one?
In 99% of cases, where people have made their own cable up, that has been the cause of communication issues.
Have you tested your cable?
I don't have PCMCIA, is there any other way to enable serial communication?
There is no way of telling from the front end what has been changed for serial comms.
If a backup can be made, I will be able to adjust the file, for you to load back in.
That's good to know and it seems to follow with what I've seen.
A previous test pick and place I did in RoboDK has a BASE 'T' value of 180 and I know I implemented that and not RoboDK.
I need to get my trial renewed I think, then I can have a play around with it to be certain.
Aux function 189 is where you configure the IP address of the ethernet port on the controller.
Both Rx and Tx pins should be crossed over as per a standard Rx/Tx crossover.
If you use a switch/hub/router which has auto negotiation, then a patch lead will do, but peer to peer (as with RS232) must be crossover.
Obviously via this connection, you will benefit from the speed as opposed to limitation of the baud rate if using RS232 (which can be increase to a max 38400.
May not be as simple as that, ex jaguar controllers used to disable the ports and as yours is 2nd user, it could be ex-jaguar.
Have you got ethernet port on the CPU card available?
If so check to see if Aux Func 189 is available, if it is you can use KCWinTCP or KRTerm Ethernet to go online instead when the IP settings have been set correctly and you are using a crossover cable.
Have you got a PCMCIA card available (max size 32Mb)?
If so, get a backup that way and attach it to a post (you would need to change the file extension to .txt in order to attach it to a post), I could have a look if it has been disabled and then send you a modified file to load in to release it.
Provide further information:
- How is RPS being controlled, set - single command, program controlled.
- At what point you say it turns off - provide evidence - ascertain when it changes state.
Just stating going back & again and saying it is off helps no-one.
What does going back & back again actually mean.
Good man.....at least you haven't been supplied with a goosed board.
Good luck, would be interested to hear of any progress if it doesn't compromise company IP making it public.
Some newcomers assume CN2 (top connector) is for inputs due to the male format and not female and CN4 (bottom connector) is for outputs due to the female format and not male.
When accessing CN2 or CN4 directly, no external voltages are present due to the removal of the external power sources.
What are the probabilities that inputs 1, 2 and 17 are all defective?
Very probable as there is no correlation between input 1,2 and 17,18 as they sit on 2 different COM rails electrically, for 1 bank of 16 bits and another bank of 16 bits.
The fact input 18 works and input 17 does not, suggests one of input 17 components is goosed.
The fact input 1 and 2 do not work, suggests either the COM1 rail is not connected, or one of the input 1 and one of the input 2 components are goosed.
I would test input 15 and 16, if neither of those work, then it could be the COM1 rail is O/C.
I've seen this before when someone has mixed the input and output wiring around without reading the manual first.
Ah, I see where I have misunderstood regarding RHR.
Fanuc and Kawasaki do indeed have different reference coordinates.
This is what I was referring to regarding the base adjustment.
As far as RoboDK representation, it appears to use the null base coordinate of the selected robot in order to place the robot into the environment.
I'm no expert in RoboDK at all, so this is something you will need clarifying with them I think.
KROSET is very similar, origins of STL models are snapped to the world coordinate of the environment, unless you make it a 'child' to a parent object, then it snaps the origin to the origin of the parent instead.
Yes there are dedicated signals that maybe allocated, but the signal numbers you are using are not usually dedicated by any form of default configuration.
You can check dedicated signals using Aux Function 111, 112, 113.
So you have wired inputs to CN4:
Input 1001 - Pin 1
Input 1002 - Pin 2
Input 1017 - Pin 20
Input 1018 - Pin 21
COM1 24V - Pin 18
COM2 24V - Pin 19
Assuming you have wired correctly they should work, so you may have a faulty board.
I would check the jumpers are all correct as per instruction for the 1GW too.
Then I would try the other 6 boards in situ, again checking the jumper configurations.
Well if what you are seeing is correct for you, then should be ok.
I don't think you can select specific controllers in RoboDK, you can in KROSET Lite no problem.
I'm confused...... .......are we speaking about the same thing here?
Standard Kawasaki floor mount with a NULL base as viewed from the rear of the robot and in base mode interpolation in KROSET lite and in real world:
X+ jogs linear right
Y+ jogs linear forward
Z+ jogs linear upward
Standard Fanuc floor mount with a NULL user frame as viewed from the rear of the robot and in user/jgfrm/world modes interpolation in Roboguide and real world:
X+ jogs linear forward
Y+ jogs linear left
Z+ jogs linear upward
Are you saying RoboDK is automatically correcting this so that any robots you use are operating the same?
Really, they were unconfigured?.
I would at least ask the question to the supplier as to why they weren't configured as some sort of testing or reassurance of functionality must have been offered/included as part of the deal, unless it was one of these 'sold as seen' deals.
Which is very risky, especially with controllers that are no longer supported by the OEM in terms of spare parts.
In this case, they could have supplied you IO boards that have some non functioning inputs or outputs, so you won't find this out until you test them out.
Glad I could assist anyway, and yes anything else you come across as you progress, feel free to post again.....
In addition to this.
The procedure to install a single IO board or additional IO boards is:
- Set the required address jumper for the IO board (1st board 1-32, 2nd board 33-64 etc).
- Install the board in the next available option slot in the card rack.
- Set the IO allocation by using ZSIGSPEC command using the keyboard or PC online terminal editor.
Do I have to do some kind of configuration in software or is the card functional when it is connected to the mainboard?
I suspect the IO board(s) installed will be configured and fully functional.
To carry out a quick check, from using STATUS button, you should be able to select MONITOR, this will then display the IO pages and you should see your 32 inputs and 32 outputs available.
If the page is blank, then no signals have been allocated.
You could also use the MENU button and select KEYBOARD, then type in IO and press enter.
This will then display the status of the 1st 32 input and 32 outputs and the internal signals
if not configured, all the input and output signals will have a - by them.
So have i a HW controller with a GW IO board?
No you have a C42 controller with a 1GW board installed.
Don't worry it will be fully functional, just the IO will need to be wired as NPN as opposed to what is normally a default standard in Europe and UK as PNP.
When you order a robot from Kawasaki, usually you receive the correct spec for your location and can optional elect to have either PNP or NPN IO fitted.
In Europe and UK, the usual industrial standard is PNP configuration, that is why I said under a default standard a C42 would have a 1HW board installed.
But, in RoboDK, all the frames on the Kawasaki model are right-hand. But I don't know which generation controller RDK is simulating. And I suppose it's possible RDK is wrong.
This maybe the case.
I haven't used RoboDK in a while (my trial has run out - reminds me I must renew it), but I'm sure I needed to change something in RoboDK to match the Kawasaki and I'm fairly sure it was relative to the base and possibly the kinematic model setting in RoboDK.
I would double check this with Jeremy RoboDK or/and post in the RoboDK board and ask the question, confirm what settings should be used with Kawasaki.
Wouldn't want to steer you down the incorrect path (pun intended).
That said, I also remember when Kawasakis were left-handed. I'm pretty sure that the AD-series controllers worked that way, but from what I recall, when we jumped to the C-series, we all had to relearn Kawasaki coordinates b/c they switched to right-hand to join the rest of the industry.
It's always been left hand rule as far as I can remember from A controller through to the latest F and T Controllers (unless I am missing something).
But funnily enough, as I'm looking through D, E and F and T Controller manuals, Kawasaki do not stipulate ANY information as to whether it's left hand or right hand rule.
References in A and C Controller manuals do stipulate left hand rule.
You have now given me cause to question myself.
You may wish to explore this further before ploughing ahead.
Something I shall have to investigate further I think..........
Kawasaki still don't include 'world' frame references or an interpolation mode on the robot, just the Tool, Fixed Tool, Base.
You can of course create frame locations and set BASE command to set the frame as the base coordinate system and be able to use base interpolation to move the robot relative to it.
Manipulation of the BASE T value ( -90) aligns the coordinate system to right hand from memory, but don't quote me on that.