Posts by ShAdOwDrAgOnS

Thanks for the feedback, do you know which pins on the X8 was the issue?

If you bought it through an OEM you could ask them for a copy of the robot manuals otherwise contact your nearest Kawasaki distributer.

Based on the info above and the code it's probably not the deadman trigger as it's not American spec that requires it to be pressed before turning motor power on.

Certain fault conditions won't allow motor power on. But if there are no faults active then I would shift my attention towards the Safety Circuit and the power sequence board (1KP)

Not getting motor power is almost always related to the safety circuit or its components.

It is possible that it could be a faulty 1KP board.

I would check all the connections on the 1KP board for the X7 ,X8 and X9 plugs. You may as well check both fuses on the board while your at it.

If I was in your situation and I have another working robot/controller that is known to be good I would try the following:

Swap the teach pendant. low risk and just 100% prove it's not the deadman switch/estop circuit in the TP.

Swap the 1KP board and see if the problem stays or follows the card. Obviously making sure the part numbers match and any dipswitches and jumpers match the board that's known to be good.

If it follows the card then the 1KP board is faulty. If problem stays then further investigation is required as per @kwakasaki's suggestions:

Quote from kwakisaki

Motor power circuit is huge to track down as it is dependent on the safety circuit too.
Includes:
- Robot arm axis limit switches and links.
- 1KB board.
- 1KP board.
- MC Unit and safety relay module.
- 1KQ board.
- Teach Pendant.

Display More

Also it's worth noting that from the code backup it does look like the 1KA board is from another robot that has been running in production and explains the operation info and the AS/servo firmware not matching the current controller.

I bet. Is that for a C controller? If you're lucky Kawasaki Japan might make you one but it will have a long lead time. C controllers haven been discontinued for some time now.

Might be time to replace your dinosaur with a new robot/controller?

Funnily enough the robot manual does warn not to plug/unplug robot cables when it's powered on. I had a customer that recently unplug robot cables while it was powered up and they blew the CPU board (1KA).

As you no doubt found out the 1KA board has many functions and one of them is displaying and communicating to the Teach pendant.

Quote from tomcat955

Update I swapped the 1ka board this got the teach pendant to boot but is now stuck at the kawasaki screen

Ah yes, the old stuck on simple and friendly screen does point to to an issue with the 1KA card and usually when the memory is corrupted, but not always.

FYI when swapping 1KA cards it's recommended to take a backup first and make sure all the dipswitches are the same as the previous board. Usually when replacing an old 1KA board you would swap the memory module(1KJ/1QJ) over at the same time. See extract from manual below.

Quote from kwakisaki

Ah, I got it now, it's been that long I'd forgotten that the 'search' is not 100% across the download centre and you have to be in specific sections to get successful search results.

Cheers for that buddy...........

No worries, glad to help. I'll admit it took me a while to find after not finding it in the search either.

Quote from kwakisaki

Yes, they have excluded the document in this version zip.
I looked back in my earlier downloads and that document appears in the download zip for:
4.01.00.20
4.01.00.21

Interesting, I missed those version since unless there's a reason to upgrade to the latest version. Why fix what ain't broke. That and when looking under the normal software locations I just didn't see it, so I was never tempted to download it and upgrade.

Interesting, CS configurator is still available for me on the download centre and that's where I recently downloaded it. The only reason we're upgrading to the new version is because one of the newer robots we have isn't supported by version 3 as the robot model is missing.

You'll note CS configurator doesn't have the same note regarding the security unblock.

To find it go to software, then tool and it's on the second page.

Yeah, so we Installed CS configurator onto a new laptop with windows 11 with no prior installs as a test. After copying the Zip file off the server that has the security restriction already unblocked and installing it normally it worked without any issues. Also since the new driver has been signed you can just right click and install it without having to reboot into advanced mode and disable the device drive signing like we had to do in the past.

The thing that got me is that there was no prompt or reason to go into the security settings and unblock the zip file as you can extract it normally without any issues but then the setup.exe won't function properly as we found out.

kwakisaki May I ask where you got that pdf of the security notice from, as i didn't see it on the download centre? I made a copy of it and put it as a readme inside the CS configurator zip file in an attempt limit future issues when I distribute the new copy to other employees.

Might have a potential solution.

After installing and uninstalling CS configurators about 20 times and trying different things I finally managed to get it working.

The problem is since I've tried so many things I'm not sure exactly which actions resulted in the successful outcome.

What I do know is my last set of actions were:

Uninstall CS configurator (for the 20th time)

Install Microsoft SQL Server Compact 4.0 i downloaded from Microsoft and ran the Repair option.

Rebooted PC.

Used the suggestion from kwakisaki to mark the Zip file as Unblocked and extracted it again.

Ran the setup.exe in Compatibility mode for Windows 8, Cancelled when it said it failed installing Microsoft SQL Server Compact 4.0

Ran the setup.exe in Compatibility mode for Windows 7, Cancelled when it said it failed installing Microsoft SQL Server Compact 4.0

Finally Ran the setup.exe in Compatibility mode for Windows XP Service Pack 2, Which doesn't even attempt to install Microsoft SQL Server Compact 4.0 And finally when I opened CS Configurator it is working normally.

Solution:

The main conclusions are that using the Unblock method of the security setting of the zip file prior to extraction were the main contributing factors to it finally working.

Just wondering if anyone have CS Configurator version 4 working on Windows 11?

It seems to have an issue installing the Microsoft SQL server compact version 4. Even downloading and installing the Microsoft SQL Server Compact 4.0 separately from Microsoft it still causes the following when running CS Configurator version 4 where the buttons are missing.

Currently the workaround is to install CS Configurator version 4 on a Windows 7 or Windows 10 on a Virtual Machine and then it works fine but it would be nice if someone has a solution to make it run on on Windows 11 so that we can run it on our host machine like CS Configurator Version 3.

So with the limited information I can suggest is the following:

Take a save/full and look at the program execution log as it will tell you exactly what line of code the robot is executing and why it might be jumping to another line/program.

From my experience things that make the robot code jump steps are:

Goto commands

Program calls

Interrupts to a label or program ( remember interrupts stay active unless Ignore is used)

Programs hitting a Return statement

external reset from dedicated input like priming PG0 on step 1

Operators changing step number or manually priming a program from the teach pendant. ( This can easily be checked by looking at the operator log to see if they are doing this)

Single step checking sounds useful.

You can do Cat 0 and 1 on the current Cubic S. It just looks like they made it an option to set it directly from the AUX menu instead of configuring it in CS-Configurator.

I'll have a look, pretty sure I have Version 1.8.6.19460 with the latest Service pack installed otherwise ill download the latest if there is a newer version.

Oh, I'll have a look. I would have thought the 2BW board would be the same 32pin connection as the current 1TW board for the E controller at least according to the manuals I've read so far.

Regarding the Bluetooth, I don't think it's an option I would use as we run an ethernet cable back to a managed switch running software EIP for PLC communication and programming. It's easy to connect a WIFI router to the switch and access the entire network without being tethered via an ethernet cable . Also the direction cyber security is going at the moment it looks like most sites are looking at locking down and limiting access to robots and Bluetooth probably isn't the most secure.

As Kwakisaki mentioned if you have the option enabled there is a menu that shows up in the AUX advance menu where you can change the Collision/Shock threshold for both repeat and teach mode.

If the menu isn't available then it's likely that the option is turned off.

As a side note you can change the thresholds from within the motion code if you ever need to quickly change between low/high settings on the fly for certain motions but you'll need a way to adjust the settings as it will override any settings people make to the collision settings in the AUX menu.

It's all detailed in the manual.

Thanks Kwakisaki,

As much as I don't like change, it's inevitable. I'm planning on getting an F controller to play around with before we go all in. I'm sure we'll just need to adapt and overcome like we normally do.

- No longer modular for easy card replacement (no internal rack).

It did stand out in the manual that the cards are sandwiched together and no longer modular.

- External safety and IO wiring is not as physically easy as previous controllers.

Probably to be expected with a smaller form factor.

- Small and compact and easier for placement and locations (like under the robot).

We already have the controllers under the robots at the moment so I guess it's nice being slightly smaller again.

- Available with or without Cubic S.

We already put Cubic S in just about all robots so we'll be getting the Cubic S core versions. I guess it will save a bit of time not having to wire in Cubic S retrospectively.

- OS is the same, all though there will be additional options and settings.

To be expected having newer options/settings. Sounds like code compatibility should be the same if the OS is the same. Do you know if the motion planning for the servo board functions the same?

- I think uses HMS CompactCom 40 adapters for fieldbus connectivity.

Just a means to an end. As long as we can convert to the protocol we need it's not a problem. I'm assuming we can still do Software EIP natively on port 2?

- Bluetooth connectivity available (suitable adapter required).

Sounds gimmicky. Sounds like a sales tactic marketed at the uninitiated. Wifi is faster and have better range in my opinion.

General question regarding backwards/forwards compatibility differences between E and F controllers.

It looks like we're getting the nudge from Kawasaki to start changing over from E to F controllers and I'm just wondering if anyone else on the forum had any issues when they changed over from E to F or have any helpful hints or differences I should be on the lookout or should know about.

Is there anything regarding Cubic S core and the old Cubic S that I should be aware of?

I've downloaded all the F controller manuals and started reading so that I can get up to speed, but this will take awhile to go through them all. So far I've skimmed the manuals looking for any changes that stand out.

Generally speaking we've been using E02,E03 and E04 controllers with CP,RD,RS,MX range robots. So it looks like we'll be going to F02,F03 and F04 depending on robot type.

Looking forward on drawing on the collective knowledge and experience of fellow OEMs and integrators.

The good news is that it is possible for Cubic S to work with a robot on a rail.

It's been 6 years since the first time I set one up. I reached out to Kawasaki directly. I had to load a newer version of software and load a file with high-level system switches in the ROBOTDATA that Kawasaki sent me.

I don't remember having to go through the same process on a more recent one a couple of years ago. So it could be that the original one had an issue in the software and subsequent robots now work automatically once you configure JT7 correctly as linear rail with base interpolation.

The system switches were related to setting up the length of the rail and the direction the rail runs relative to robot base coordinate and enabling the external axis to be part of Cubic S.

Word of warning don't play around with high-level system switches as you can brick the robot.

So it sounds to me like it's possible that there is a software issue with the MX350 robots and your best bet is to contact Kawasaki.

Quote from dhindhimathai

We are experiencing a very strange phenomenon. Suppose, the robot is not receiving any communication, i.e. no commands being executed with any JMOVE or LMOVE commands. The robot is in MOTOR ON and is in CYCLE START. We switch from REPEAT to TEACH. Then, we move the robot to another position. Finally, we switch back from TEACH to REPEAT, turn back on the motor, and give CYCLE START. We notice that the robot moves back to the same position it was before being moved in TEACH mode.

I always thought this is normal for Kawasaki robots to do a Joint move back to where it was when it was interrupted. Even if it's not why would you let your robot continue in automatic if it was moved in teach, since you don't know where or why they moved the robot and what path it will take to your next executed motion.

Depending on your application, I find it's good practice in my opinion to be able to monitor when the robot is switched to teach mode and run an initialization routine to deal with people moving robots mid cycle.

I usually use an autostart to monitor for teach and teach lock, then prime PG0 where the robot runs initialization code before running a routine to return safely from almost any position to a known location and then continuing normal operation in repeat.

If it's not practical to recover automatically with a routine then you could add a SOP(standard operating procedure) to make them drive the robot close to a location before going back into repeat.

Why not just use a precision pose instead of a regular transformation to make the robot end up in the exact pose you want.

A regular transformation is a point in space and the robot can reach it in multiple different ways especially if it's a 6 axis robot. It's denoted as X[mm] Y[mm] Z[mm] O[deg] A[deg] T[deg]

If you teach a pose with #location_name then it's a precision pose and the robot will always end up in that location in exactly the same pose since the values are denoted in Joint angles of each joint. eg .JT1 JT2 JT3 JT4 JT5 JT6 -131.550 75.765 -76.967 -138.799 0.000 0.000

Also robot's are lazy, they take usually take the path with the least joint displacement by default unless specifically told other wise.

If you are using calculated positions, just remember the can convert between transformations and precision poses but you'll need to reference it, else the robot assumes you are referencing to #here and creates a precision point closest to it's current position and thus uses the least joint displacement.

I'll just leave this here , happy experimenting:

This has been resolved. Waiting on details from site. It appears to have been wiring related as I first suspected and kept circling back to once we proved it wasn't the Cubic S unit or the servo board.

It's hard checking the wiring remotely as it turns out.

I would start by checking the connections, especially the wiring that monitors the P-N voltage.

Failing that i would go down in order of the troubleshooting manual as they usually list it from most likely cause to least likely cause.

Greetings,

First of all, this is on a CP180 - E03 controller. AS software ASE_010300Z5M (brand-new robot)

Just wondering if anyone has come across this fault before or has any other ideas of what to try next.

I can confirm that the wiring has been checked thoroughly. Have compared and checked all the connections against other known good controllers with the same setup, still getting that same error.

Swapped servo board from a working and running robot that's running the same servo software SVE_08000006C, same dipswitch and jumper settings, still getting that same error.

Swapped the Cubic S unit from working and running robot and used the new wiring harness, still getting that same error.

Background information:

I have integrated in excess of 100 Cubic S units, with this being the first instance of this error. I have 6 other robots at the same site are all from the same batch serial numbers sequentially where Cubic S units have been configured, integrated and working.

Current plan moving forward is to test and run robot without Cubic S to see if there are any underlying issues. Mainly just wanting to see if anyone else has come across this before and might have a lead to point us in the right direction.

I'm also following this up with Kawasaki directly as it's within warranty.