Ok so when I go to aux 111 dedicated input signals, this is what I see so I'm not sure what you mean...
Nevermind, I just saw there were other pages...
After going to the next page and following your instructions I was able to move the robot in auto mode (initialized the robot as well). I made a simple block teaching program and it executed it properly 
I'll start learning and then look into my options for I/O capabilities.
Thank you again 
Here's a save from the robot after a system initialize. Whenever I initialize it I can't clear the interbus error and become unable to move it even in teach mode.
I also managed to get and rs232 connection. The connector was just a little rusty, preventing me from screwing the plug in.
Ok so when I go to aux 111 dedicated input signals, this is what I see so I'm not sure what you mean...
In the meantime I tried uploading my modified handler, it did get rid of the error in auto mode, I can now put get motor power and cycle start on. But when I toggle the switch to run the robot still doesn't move. I'll attach a picture of the tp screen. I guess the robot is expecting an external signal it doesn't get from the interbus to allow it to move...
Still a little improvement in my opinion 
What I'm trying to do now is make a basic program (block teaching) and test is on the robot.
In the future my aim is to re-equip the robot with a welder so I'll definitely have to follow one of those routes to get some I/O.
Here's a copy of my save, thanks for the help!
Not entirely sure what you meant, I tried going to functions -> aux 118 signal allocation set, set everything to "loc" and 0, re initialized after stopping all PC programs, restarted the controller but the error is still there and not clearing. I guess that's not what you meant since it didn't work...
I don't, I only have one robot and no plans to get another at the moment (might change my mind if I see one for sale though 😅). Do you suggest I simply remove the board entirely and keep it stored just in case ?
Hello,
Slight update; yesterday I also ended un trying re-uploading all variables, strings, and pc programs using Kide (eth mode ofc). I restarted the the robot noticed I now had PC programs running again however if I remember properly the PC program that used to be displayed was "*autostart" I think. However it now displays "autostart". Not sure this is valuable information but at least it's here.
I had understood yesterday that the inter-bus error was handled by the PC programs and this morning I took a deeper look at my save file. I did find a "MASTER INTERBUS ERROR HANDLER" that is part of "autostart3.pc" if I'm not mistaken, I'm still far from proficient at understanding AS 
My understanding of the handler, based on my previous interactions with the robot is; this handler allows the robot to run it teach mode despite the interbus error, but not in auto mode. This would conciliate my previous experience with this error handler.
My guess now is that there was no change when I uploaded the PC programs because they call on programs I did not upload? I'll dig deeper...
I think what I'll try now is to reupload my complete save file, with the interbus error handler modified (see attached txt file) in such a way that the signals and errors are handled in auto mode as they were in teach mode, hopefully allowing me to run the robot despite the interbus error.
I wanted to return to robot to a "factory setting" fast so I could start from a blank page. I now understand this might not be the simplest option as the robot controller itself is equipped with boards that require PC programs to handle them.
I'll keep you updated as usual about the results.
Have a good day
Hello again,
I'm trying to learn programming for the robot and today I wanted to run my first program; a simple 3 points cycle via block teaching.
However I ran into an issue, once I recorded the steps and tried to run my program (tp teach mode off, controller switch on repeat, status repeat 10%, repeat once, step cont then motor power, cycle start, and Switch on run) the robot doesn't move. I then tried repeat continuous and the inter-bus error pops and doesn't clear.
I also wanted to reset the data on the robot since I had a save file and had found the initialize function in the list. I had to exit the program and PC kill then was able to initialize but now the inter-bus error doesn't clear at all, even in teach mode.
I'm also not able to connect to the robot via Kide via rs232, despite it appearing on device manager. Although ethernet still works with both Kide and KCwinTCP.
Is there a way to get rid of the inter-bus error ? Should I reset the robot from my computer, I was hoping to be able to connect via rs232 but it's not working and you had mentioned I'd lose the ethernet connection if I did so...
Have a good evening 😀
Thank you for the manual and praise, I wouldn't have made it without your help! I'll be performing the maintenance tomorrow I think, I'll also be plugging the robot to my computer for the first time in a while.
Hello everyone !
I have great news ! I replaced the 1GB board after swapping 1GM and resoldering a condenser that had been torn off during shipping and the controller started with no errors other than the missing interbus connection. I re-zeroed the robot and I'm able to move it with the teaching blocks menu. I also have not had that jt5 over current error up to now.
I'll now be performing a maintenance, is there a manual where I can find the procedure ?
I'll also bring a computer to plug in so I can get everything set up to start running programs.
Again, than you a lot to everyone and especially you, kwakisaki !
Hello Kwakisaki,
I had that idea as well 
so I went ahead and did that yesterday, I moved the controller really close to the robot and with a bit of difficulty I managed to test for continuity and no shorts from 1FG-CN3 to 1GB. I have the troubleshooting manual but did not see the pinout on there, is it in another chapter than 3 descriptions ? I see the connectors and their roles but not the pinout.
Anyway I managed to find them with the DVM and put a little dot next to the corresponding solder points. There's a friend of a friend that's apparently really good at testing PCBs, so I'll hand it over to him.
I also jumped on a 1GB board I found for pretty cheap and not far (scheduled to arrive next Monday at the latest). However I was at home and during my compulsive order and realized I had ordered one with a different serial number 
I ordered 1GB-74 50999-1806R10 instead of 1GB-74 50999-1650R10 hopefully that doesn't matter as long as the switches are in the right position 
I'm getting really eager to be able to move the robot and perform maintenance. I want to make sure I can trust the robot before starting to experiment and learn to program for it.
I received the batteries and they are now installed, no more encoder battery error on startup.
I noticed I had not entirely followed the test procedure you advised so I test again today and this time swapped on the encoder end, had the same results; encoder registering movement as jt4 when I moved jt3 and nothing on jt3 when I moved jt4.
I did have the encoder data abnormal jt4 again after testing today, so I guess that was due to the swapping test which makes sense.
Sidenote: I went ahead and bought an rs 232 null modem cable.
As I mentioned yesterday, I went and tried the swap and move. I swapped 1FG-CN3 and 1FG-CN4, cleared the error, it remained on jt3. I zeroed jt4, released the break on jt3 and moved it. I observed the angle on jt4 moving up and down as I physically moved jt3.
I then checked the voltage on the jt3 encoder cable, measured 5V.
I also tested for continuity between the encoder plug (yellow and white wires) and got continuity and no shorts to X3 control box side. As expected after the swapping test.
So unless I'm mistaken this removes any possibility of a problem on the robot side and pretty much points to 1GB being the culprit doesn't it ?
I hope you have not been 'hot swapping' as this can spike the encoders and permanently damage them and possibly damage the 1GB board too.
Nope, I only ever swapped them with the controller unpowered.
Have you actually measured the supply to the encoder at JT3 end?
No, I only tested on the 1FG board, as I was convinced a problem after the 1FG board on the robot side was unlikely after the swapping test.
Have you swapped JT3 encoder harness at the encoder end and carried out a brake release and moved JT3 arm and seen the encoder/position values change on the axis data you have swapped to?
No, I only tried swapping the connectors with the controller unpowered. I then powered up the controller and noticed the error stayed on jt3. Tried to clear the error a few times, which would not clear and remained on jt3. The powered off and put the connectors back in their original positions. I did this two times to to be sure.
I guess I'll be trying that as well to make sure the jt3 encoder works properly. Also checking the voltage directly at the encoder plug.
Other OEM's do something similar but choose to use completely separate cells instead of an assembly. Which introduces possibilities of single cell changes at infrequent times.
Kawasaki choose separate cells, but assemble them in a pack, so they are ALL replaced at the same time when ANY battery alarm is triggered from the servo board CPU's to ensure regular maintenance for all encoders and reduces the downtime.
Yes I've noticed they are wired in parallel anyways, my first assumption was there was two seperate circuits for unit-A and unit-B battery. Which would be a bit of a d*** move, forcing you to replace both batteries whenever one of them was low voltage. But since they are wired in parallel they discharge at the same time so it's just the low voltage detection that's seperate between A and B, so if any of them pick up the low voltage error, it means both batteries need replacement anyways.
I've now tested 1FG-CN1-6 (pins 1 and 2) and I have continuity and no shorts to X3 control box side. Maybe the error was caused by the extreme battery discharge state ? We'll see once I've replaced it.
So here's a quick status update on the state of the jt3 encoders error at this time:
Therefore, the remaining possibilities would be either some weird errors caused by the extremely low battery voltage or a defect on the control box side, likely the 1GB board as the unit-A error led lights up. Let me know if you have other suggestions.
Thank you and have a good day.
Well my batteries are definitely dead, like 10mV dead. I've checked the board for continuity between cn1-6 an cn8. I also checked the voltage on cn1-6 with the controller powered on and had 4.9v so nothing abnormal there. I have a few test points on the board, I tested the obvious ones and voltages in the expected ranges. The voltages on tp4(bat) and tp3(+5B) I could not make sense of but knowing the state of the batteries it was to be expected.
Also there is one more thing I've tested and that's moving jt3 by hand with someone releasing the break to check if the position would still change on the teach pendant. I had zeroed it prior to moving and had absolutely no change after moving in about 20 degrees.
I'm now going to test the continuity between X3 and the 1FG-CN1-6.
Can't wait to get the batteries set up for further testing.
Yes that is the batteries I have ordered but the fastest delivery I found was 1-3 weeks other than ebay that I can't use anymore.
I ordered some lithium batteries and I'll do the same as you, will be a great saving in the long time.
FYI - Encoder low battery voltage warnings:
- Servo A warnings relate to major joints 1,2,3.
- Servo B warnings relate to minor joints 4,5,6
Yes I had guessed that was related to CPU A on 1GB, it's interesting to have separate batteries per 3 encoders but have to replace both batterie at the same time 
I'll keep you updated when I've done my probing tomorrow.
The batteries have an awfully long delivery time I ordered some but is there a workaround or alternative to replace the cells and re-solder ? The cells themselves seem to be obselete and quite hard to find...
What was pushing me towards 1GB is the testing done between 1GB and the robot's connectors + the connector swap on 1FG, but that doesn't exclude a fault between the connectors and 1FG or on 1FG itself... I'll focus on testing that as well.
What somewhat pushed me to be suspicious of 1GB is the previous overcurrent issue, but I'll exclude everything else first. Altough I do still think of buying a replacement...
