Check your conversation at robot forum.
Posts by kwakisaki
-
-
Back in the day with D Controller an integrator would either use the Arm IO in conjunction with 1HW IO or just use 1HW IO instead.
Therefore, if they did use the Arm IO and the 1HW IO they were supposed to change the jumpers on the 1HW, disabling the Arm IO from being available on CN2 and CN4.
The fieldbus information is contained within the backup, but thinking about it, I think the information I see is default information as standard.
But the fieldbus is not enabled, so any configuration here is never used until fieldbus is enabled.
Just do a search for FIBUS in the backup, the information is there if you can decipher it.
Did it use fieldbus in it's previous usage - Interbus do you know?
-
In the Operation Manual.
It does not cover every single detail, but contains enough information (in true Kawasaki fashion).
If you re-read post #53, you will see I mention disabling these inputs and outputs via the jumpers on 1HW to prevent common sharing between 1KP/1KB/1RB and 1GW/1HW.
-
If you read my previous reply, I mention this regarding Arm IO and 1HW IO.
Historically this is what CN3 was purposed for, as prior to D Controller was C Controller which used the same IO board.
But C Controller never had the 1KP or 1KB/!RB boards, so they had a physical harness attached to CN3 instead.
This is why I said, don't worry about CN3.
When D Controller came out, CN3 became redundant as 1KP and 1KB/!RB provide the signals instead.
But they still did not differentiate between Arm IO and 1HW IO until the release of Arm ID board (which is not fitted in FD50 Arms).
Try and disable it in Aux 0610 and see what happens.
-
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.
-
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.
-
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.......
-
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.
-
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..............
-
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.
-
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.
-
I would check insider connectors CN2 and CN4
-
Tell me:
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)
-
Yes, that's why KIDE is shite......you're relying on 'beta' application and automatic functions.
Better sticking with KCWin.
That backup you sent is 100Kb greater in file size that from KIDE.
Tell me:
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)
-
OK, so you're connected via ethernet then.....so it will be valid.
What happens when you use CTRL+F9 option then?
-
Personally, I don't think you're wired up correctly.
-
Need to see CN2 and CN4 inside the connectors?
Can you show me a video of what you're doing when using the IO screen to turn on the signals?
So the backup you've been sending is not what's in the Controller then................................so I could be chasing ghosts then....
The error is relating to you using incorrect syntax.
The command should be SAVE followed by a filename not exceeding 8 characters, no spaces and not starting with a number (but can contain a number).
eg. SAVE backup
-
So the logic is being executed correctly then, so that's something.
If you move the red box over a specific output (don't just leave it on No 1, move it and try) in the IO monitor screen:
1. when pressing (and holding A) and then pressing no. 1, that should turn the highlighted output on - go from light grey to yellow.
2. when pressing (and holding A) and then pressing no. 2, that should turn the highlighted output off - if it is on - go from yellow to grey.
Are you saying that is not working?......as that does not make sense.
No I never said CN3 should have a cable in it, it may have a cable in it.
Do not worry about CN3, if the jumpers are set to what I said, it will not be in use.
Can you send pictures of your wiring to the CN2 and CN4 connectors - some good quality ones?
Also pictures of the 1HW board itself showing the jumpers?
So you cannot make a backup from the Controller - is this what your telling me?
-
Ah, lots more emails to put on the spam lists now.......
So glad really, as a lot of people of late have been using their 'conversation' options to exchange emails etc which meant a huge reduction in my spam lists, but now it's starting back up again, I'm back in business.....
Thanks everyone for sharing.....
-
How would I possibly know where this file comes from or in what state of editing it is at?
Therefore the only thing that is relevant when trouble shooting is exactly what is in the controller, not on a PC. unless you are testing in KROSET etc.
Saying that also, without specific information, we have to trawl through reams of data without knowing what programs are being used or tested, so we need as much updated/to date and accurate information as possible - this will always reside inside the controller as that is what it is executing.
Comparing the 2 files, they are different and not identical.....which proves my point.
- Granted, there is nothing that points to what you're experiencing.....But it could do.
- I don't mean it to come across in negative way though, but you could by accident send a file from last year and we'd be chasing ghosts.
- I have spent many hours trawling a backup only to be informed, they'd provided the wrong one...........
- This is why a current backup is necessary.
Ok, So we can ignore the KLOGIC allocations and as there is no LSQ program exist/running then.
Reviewing the 'small' program:
Your inputs from the peripheral sensors providing feedback/status are turning on internal signals, not outputs.
- I assume you are aware of this, if not, then you need to do some research about the Kawasaki IO and Internal Signal purposing and usage.
- Inputs are referenced as 1001 - 1032
- Outputs are referenced as 1- 32
- Internal Signals are referenced as 2001-2255 (these are like internal flags only - no electrical connection to CN2 or CN4).
- So no indication on CN2 will be seen regarding the status of these.
- If you check the INT screen in the IO Monitor screen, you should be seeing these signals reflect the logic your using in the small program.
- These are also being sent to the 2 Data registers (if the autostart.pc program is running) you should see these values in the INT Data Monitor window too.
- This will provide you evidence of whether the peripheral sensors/inputs are working depending on there status.
The outputs in your motion routine (speed and distance between points dependent) will be executed when the robot is 20mm from the preceding target.
This could actually mean they are operating too fast for you to see......I doubt it, but it is possible, you could go real slow and see if this is the case.
The other thing I have noticed, is that the general fieldbus is disabled with an old configuration that uses signals 33-64 and 1033-1064.
However, as this allocation is not the 1-32 and 1001-1032, this should not be causing any issues.
So on the face of it, what I can see, there is no reason for the IO to not function as far as the controller logic is concerned.
If you can proceed with those 2 tests I mentioned, then we will be in a position of whether there is an underlying configuration issue or board problem.