1. Where is the 24V and 0V lines in your panel from the PSU going to on CN2 and CN4 Connectors
- CN2 requires 24V on VIN1 and VIN2 (18 and 19)
- CN2 requires 0V on COM1 and COM2 (36 and 37)
- CN4 requires 0V on COM1 and COM2 (18 and 19)
on CN2: VIN1+VIN2 are on (+) connecting clamp, after output16 from outputs clips and OV (COM1+COM2) are on the right side of the output connecting clamps..
on CN4: 0V (COM1+COM2) is on (- ) connecting clamp, after input16 on the input connecting clamps.
I would check insider connectors CN2 and CN4
see previously sent pictures..
The next thing, if all your wiring is correct (something is telling me it's not) is to clean out the controller and return ito back to defaults.
Thus removing all data and then trying again.....sounds like overkill to have to do this, but nothing make sense.
Before connecting the wires to the connection clamps I identified wire by wire simultaneously on both the connector and its end ...
Most reasons for IO not functioning is wiring, the connectors are not the best and very easy to create short circuit and connect to incorrect pin numbers etc.
A picture of the inside of the CNx connectors would be nice.
Thus removing all data and then trying again.....sounds like overkill to have to do this, but nothing make sense.
And how to do that, I tried with KIDE and it doesn't work ... it resets (KIDE) and doesn't delete anything
pictures with inside of the connectors...
I don't use KIDE so wouldn't know.
That application originates and is supported out of Germany so I couldn't really comment on it.
I haven't got time today to go through the reset procedure, if you do a search on the Kawasaki board for re-initialization, there should be some information on doing it.
But like I say, seems very overkill..............
Ok, thanks for the time given today ... I will try to check the connections again tomorrow although it is the 4th time i do it ... it is very strange, i think there are some "lint" left in the configuration part and that's why it doesn't work.
Another strange thing is that when I run the FOR loop on outputs 9-15 I hear the relays on 1KP (clamps), which I heard when using the OPEN / CLOSE command.
No that is not strange, that is how the arm io works.
When Aux 0610 has been set for the arm io sensor and valve, the 1KP relays provide the output signals to the XSOL harness which goes through X4 to the internal arm harness.
The current configuration should work as it is, the configuration you have works flawlessly in simulation (without the hardware).
Thanks for the pictures of the connectors.
Not really clear as I can only see one side of them.
It's a very strange problem for sure................
1. Have you disconnected the arm island when you are doing these tests?
2. Can you show me a video of what you're doing when using the IO screen to turn on the signals in teach and repeat modes?
3. Is it possible CN2 and CN4 harnesses are wrong way round - does the input terminals bell through to CN4 connector and output terminals bell through to CN2?
4. Failing that, try the below, but be aware this will remove ALL configured data and make the robot unusable until it is configured again:
(This is done at your own risk, I accept no liability).
- Make a full backup before you do anything.
- Carry out the hardware initialization procedure attached.
- Load in the file I have prepared and attached.
- After loading you should have encoder abnormality error - this can be reset.
- You may have Check Sum error which cannot be reset, so to reset: Go to Aux 0803 and set to enable, this will allow reset of check sum error.
This should now be a completely 'clean' configuration, try the loop test again - BUT execute it in PC Area instead.
Let me know the results or if you have trouble.
Also, disconnect anything 'extra on the arm' that isn't standard.
1. Have you disconnected the arm island when you are doing these tests?
2. Can you show me a video of what you're doing when using the IO screen to turn on the signals in teach and repeat modes?
3. Is it possible CN2 and CN4 harnesses are wrong way round - does the input terminals bell through to CN4 connector and output terminals bell through to CN2?
1. At the beginning of the tests no, I had the actuation relays connected...only when I saw that nothing was happening did I take them out.
2. Tomorrow, I will make a video with the procedure of forcing the outputs, but I can also explain in words how I proceeded ...I set the robot in learning mode, I pressed the trigger key (deadman), I selected one output with arrows, I held down the A key +1 and the output status has not changed.
3. I also checked this, the wires in the series of clamps corresponding to the inputs reach CN4, and those corresponding to the outputs reach CN2. I checked the whole chain, from the electrical panel to the solenoid valve island, if I apply 24V on one of the outputs (with CN2 disconnected, obviously) the solenoid valve corresponding to that output is activated.
I checked wires with multimeter one by one, both inputs and outputs. They all end up correctly in the connectors. What I did not check and I will do tomorrow, I will check the signals directly on the connector on the 1HW board, to eliminate the suspicion that there may be an imperfect contact in the two connectors CN2, respectively CN4.
4. I would leave this point (4) for later, when I exhaust all the verification options ... it's risky but, if I see that I don't have any option anymore, I'll probably try it.
Thank you!
Regards.
Also, disconnect anything 'extra on the arm' that isn't standard.
I don't have anything connected on my arm anymore. The control cable that supplies the island to the solenoid valves and sensors on the gripper is separate from the robot arm, it only transits it, it is not tied anywhere inside - it enters through the back of the robot, passes through all joints directly and exits the arm between JT3 and JT4.
I still think that the controller does not know how to work with the 1HW board, even if the logic part works ..but we don't know what's going on the other side (from VME) and I say this from an electrical point of view not software ...
As for the electrical connection in the electrical panel, from my opinion, the only problem that could be is that the power supply ( Vin1,2 & COM1,2) is not passed correctly to the 1HW board, to activate the optocouplers LED on the inputs or transitors on the outputs...otherwise, that I confused the outputs between them (eg 2 instead of 1 or vice versa) is less important in this phase ...
Everyone troubleshoots differently which I can appreciate, but when I troubleshoot, I remove everything I can possibly remove that could influence things.
As mentioned, setting wise, from what I can see in the backup and simulation testing is solid.
So I suggest that 'any and all' additional cables/harnesses are disconnected completely both ends.
Leaving the controller standalone with just the stock umbilicals connected.
There is an obvious problem on the solenoid island cabling/circuit, as it introduces a VME bus error when it's connected.
There may not be a direct issue on the cable itself, but by having it permanently disconnected - removes the external influence.
Given the time spent already, If I was in your position now and you definitely cannot manually turn outputs on via the teach pendant.
I would troubleshoot this side of things and see if all of these are interlinked (it seems feasible there is one issue that is causing all these issues).
The teach pendant not working like that with the IO's, I have seen something similar to that before (not identical, but similar).
I would swap the teach pendant - to eliminate that and the cable.
Maybe worth trying if you have access to one, at least it will be eliminated as a possible cause if nothing changes.
You could actually remove the teach pendant and operate it without the teach pendant, if you had an X1 jumper plug.
If this still did not operate, then I would have a good session of removing, cleaning, inspection and re-connecting things:
1. Remove ALL the boards out of the card rack, give that bugger a good inspection inside and a good clean out - blast some pneumatic into it if needed.
2. Make a note of all the dipswitch positions on all boards and give them all a good toggle to the opposite state and back a couple of times.
3. Remember to put them back to their original positions.
3. Maybe a blast of air across them too.
4. Inspect the rear connectors of the 1RA, 1RB and IO boards for any bent pins.
5. Locate the harnesses on the side of the 1KX Motherboard, disconnect and reconnect them.
6. Put each card back in - Making doubly sure about 1RA and 1RB connection tabs and that they are secured and locked into place.
7. Power the Controller up and make sure it is still error free and you can jog it about.
8. Power off and remove the IO board and power it up.
9. You should see the E1009 error No.1 board not installed.
10. Power down, plug the IO board into OP4 (furthest away) and leave CN2 and CN4 disconnected.
11. Power back up again.
12. You should not receive the E1009 error (this should mean communication is good).
13. Try manually turning on the outputs again via the teach pendant.
Now if you still cannot turn on outputs via the teach pendant method.
The teach pendant communicates directly with the 1KA/1RA CPU Board.
Which would mean the culprit has to be either:
- 1KA/1RA CPU board is not seeing this from the teach pendant or is not sending the signals out to the IO board via the VME bus.
- AS Firmware is not operating correctly.
The aspect that makes the 1KA/1RA CPU board the common element here is the fact that:
- Teach Pendant communicates directly to 1KA/1RA CPU board via connection made on 1KX motherboard.
- 1GW/1HW board communicates directly to 1KA/1RA CPU board (via the VME bus)
- Arm IO (1KP relays and inputs which come via the 1KB/1RB) are also controlled from 1KA/1RA CPU board.
- Your solenoid island appears to trigger a VME Bus error.
- Therefore it could well be there is a permanent VME bus problem which could answer this strange occurrence.
- VME bus is the common circuits across the backplane 1KX Motherboard on which the 1KA/1RA, 1KB/1RB, 1GW/1HW board are common.
The hardware initialization is actually not that 'risky' when you have a solid backup available to recover it back to, but sometimes people elect to use this method straight away as opposed to troubleshooting it.
So it's still an option (although may not be the cure) and it does sound like you're in a position to troubleshoot it as opposed to just try and get it up and running in the fastest time..........so may as well dig into the realms of locating the culprit.
It would be nice to get to the bottom of this, as I'm running out of possible directions now.......
There is an obvious problem on the solenoid island cabling/circuit, as it introduces a VME bus error when it's connected.
This error occurred only once some time ago, given that the cable from the solenoid valve island was disconnected (not wired to the controller, it was in the air). Since then, this error has not occurred, given that the other day I connected the cable to the IO electrical panel....it was probably also related to the fact that it did not "see" the 1HW board.
The E1009 error was resolved some time ago following the procedure suggested by you ... since then it has not given any error with this code ...
The problem is also in the controller because in the conditions in which I removed the CN2 & CN4 plugs from the 1HW board, I practically disconnected from the arm and everything related to it on the IO side.
In other words, testing the FOR routine for IO checking was done with both CN2 & CN4 connected and disconnected, the result being the same. That's why I tend to think that the problem is still in the controller.
Tomorrow I will try to change the port on which the 1HW board is inserted from OP1 to OP4 as you suggested, and I will run the test programme again to see if anything has changed ...
Please, can you take a look at the jumpers and dip switches settings on the 1KP, 1KB / 1RB and 1KA / 1RA boards?
Thank you!
Regards.
inside of controller...
If the dipswitches on the 1RA board (red bank) were in the wrong position, the controller would be booting up in different modes - they are correct.
If the dipswitches on the front of the 1RB were incorrect, you would get mismatch servo errors permanently and unable to move the robot - they are correct.
The jumpers on the front of 1KP board are correct.
You could remove the links between 9-10 and 11-12 if you want, this will remove the internal 24V and 0V power source used for the arm sensor and valve signals in the arm.........Hmmm, that's got me thinking.....Yes remove them just as a process of elimination.
The logic for the outputs and inputs (CN2 and CN4) is all optocoupled (therefore isolated) from the field.
Any short circuit on the CN2 or CN4 side, would only ever melt field cables/devices or damage the optocouplers, it would never get back to any other board.
The outcome of the FOR routine would never be any different for CN2 (outputs) as there is no feedback from the optocouplers.
When the specific output turns yellow - this indicates the logic is working that fires the output optocoupler.
Whereas with the inputs CN4, that is the incoming logic to turn on the optocoupler.
When the specific input turns yellow - this indicates the optocoupler has switched on the low logic side - ie the input has been received.
Hi,
Today I performed the set of checks suggested by kwakisaki, points 1-12, minus point 13 because I do not have another TP. In addition, I checked again the connectivity on both inputs and outputs, this time directly on the pins located on the printed side of the 1HW board, resulting in the fact that both the cables and the CN2 and CN4 connectors were connected correctly. The result is the same as before, nothing works in 1HW (physical IO).
Also, I removed the links from pins 9-10 and 11-12 from the X9 connector of the 1KP board, I ran the FOR loops again but the result is the same - it does not activate the outputs and does not read the inputs. I reconnected the links and did the next test - I deleted the input check routine (FOR loop) I left only the one on the outputs. I unwrapped the corresponding built-in IO cable and launched in repeat mode (infinite loop) the FOR routine only for outputs in this way having the possibility to check the cable with internal IO.
What did I find? I identified in this cable 6 active outputs (9-14) and 4 active inputs (13-16). Now I wonder if this is normal, when I have a 1HW extension and the controller sees it, which I allocate from the software all the inputs and outputs it has (32 + 32) to actually find that some of the IOs are used elsewhere. Isn't it a conflict? Shouldn't these built-in cable IOs be disabled somewhere to be fully used by the 1HW board?
I'm confused, I don't understand anything anymore ...
Can you tell me, please, where do I find the Aux functions with the necessary explanations?
Thank you.
Regards.
So all your checks are confirmed electrically then as solid.
Can you obtain another teach pendant to borrow, or an E controller teach pendant (the E controller teach pendant will connect and work fine)?
The internal IO you are referring to is the 1KP relay outputs and the 1KB/1RB inputs I've been referring to.
These are enabled in Aux 0610 called Input/Output Signals in Robot Arm:
- User Sensor Inputs are for the inputs. (These are driven from 1KB/1RB board)
- Built in Valve Output are for the outputs (These are driven from 1KP Board relays).
- Link 9-10 and 11-12 provides the 24V and 0V power source to the arm IO harness, which can be removed and replaced by an external source on 10 and 12.
- You can disable these and see if it makes a difference.
- To my knowledge they never differentiated between Arm IO and 1HW IO until the Arm ID board was released (which is not fitted on FD50 Arms).
- They may have changed something in firmware to differentiate.....so try and disabling and see if it comes alive.
If this works I will really be apologising........as from what I recall when using the Arm IO (lets say on output 9), then output 9 would also be active on CN2 reflecting the Arm IO status......which was annoying as hell.
