Posts by ShAdOwDrAgOnS

    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.


    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.

    I agree with keep it simple stupid approach.

    My only comment would be that it's using allot of I/O. If you were constrained and had limited I/O, you can make your code more elegant by multiplexing the signals by using the same 13 bits for the data and say 4 bits to identify which data is being sent and then finally 1 input and 1 output to do a 3 way handshake for the data exchange.

    So basically you'll end up with the same result using 18 outputs and 1 input on the robot side.

    You would have to verify that you can do the data exchange within 500ms but with a fast enough RPI on PLC and robot side in the order of 1-2ms or less, I highly doubt it would take longer than 500ms to multiplex the data.

    Just a thought for your current situation as a temporary solution, you can setup a user safety output in Cubic S that that passes that status of your safety input. You could grab that output and take it back to the PLC or back to the robot as an input and then pass it back to the PLC over comms.

    I know for my application the safety logic controller(SLC) passes that status of the Safety output it sends to Cubic S directly to the PLC for visual display on the HMI since our SLC and PLC communicate directly to each other already.

    - Debugging works only in simulation, not with a connected real robot.

    - So it is not possible to single-step your programs from the PC

    - You need the Pendant and a Terminal, where you have to type STEP for each line.....

    - On-The-Fly changes of code is not possible, you have to stop debugger, make code-changes, save them, and freshly restart the simulator and debugger at line 1 of your code.

    Maybe it's just me, but have you guys considered that you can do online edits using the EDIT command and make on the fly changes and then continue or just going back a couple of steps. Why start from the beginning?

    Also you can start any program on any step number. EG: prime pg0,,40 Primes program 0 at step 40.

    Also there is a KRoset license version where you can be connected to a real robot or simply test offline.

    Seems to me like you guys could benefit from doing a Kawasaki training course or two. Maybe even spend a couple of hours with an experienced Kawasaki robot integrator to show you the methods and short cuts to commissioning robot code.


    E4024 is a connection time out.

    Typically in industry, robots are setup as client side since you can have multiple robots communicating to a single device which is commonly setup as server side. The basic communication structure is outlined in the picture below for robot as client side. Your code doesn't appear to have used the TCP_CONNECT command to establish the connection first before trying to send data.

    Have a look at the manual 90210-1248DEA-E Series-TCP-IP Communication as this contains examples and goes into detail how to use the commands and what the error numbers mean.

    The data storage option is a great tool for diagnosing problems as you can trend signals and other robot values down to 2ms intervals and then export the data onto a USB as a .CSV file.

    I've attached the manual.

    It's an option that can be enabled on D and E controllers. However I don't know if this a paid option or not and therefore I would refer to the post above regarding contacting Kawasaki directly.

    I have noticed that the data storage option isn't always enabled by default and out of the last 50 robots that has come through the factory I'd say about 50% came shipped with the option on from factory.

    I'm aware of Blender but I haven't used it. However i think we're narrowing down the root cause if you look at what i've written below.


    Collision detection in K-Roset (as you may have experienced) slows the graphical rendering down, due to increased overheads to monitor facets on the STL models with other STL models, which could have an impact on this error IMHO if you were using it, but you are not, so eliminates that side of things.

    No, i didn't know that the collision detection had that big of an effect. But that would make sense.

    But this made me think about disabling the collision detection. Then when testing i couldn't replicate the fault. When i enabled collision detection it faulted almost straight away when moving the view while the robot was moving.

    So I've been working on the project yesterday with multiple grippers "attached" TCP as simple shapes and the STL files. Then using the show model function to hide the STL models when doing motion testing and moving the views around. Then only showing the gripper STL model when required.

    Doing this resulted in zero crashes which definitely seems to confirm that it's the STL grippers causing the rendering crash.


    How are you adding the gripper models, are you adding them as STL's or creating KRPRJ files and then adding them?

    I've been adding them as STL directly onto the tool. I know of the possibility of creating KRPRJ files but it's been a while since i've looked into it. loading them directly as an STL is quick and convenient.


    When this is crashing, are you in the process of changing perspective with the mouse?

    ie. rotating the view, zooming etc

    Yes, it happens exactly when changing/rotating perspective and it also happens when zooming in and out.


    Are you using any of the K-Roset collision detection options?

    i have collision detection plugin is enabled but i'm not actively using it for this project.


    Can you explain what you mean by overlaying grippers?

    I mean attaching two or more STL grippers in the same location but one is an STL file with the gripper in the open state and the other is in the closed state. Then i make one of the two grippers transparent to give me a ghost image of what the closed state would look like.


    Any chance you can 'zip' the project and post it (via conversation - via a download link) without compromising any IP?

    It would be good to be able to replicate the errors

    That would be difficult without comprising IP. I can possibly send you one of the STL files for you to mount onto the robot to see if you can replicate the issue.


    Using wire mesh view instead of shading doesn't make a difference.

    So I started making new grippers from simple shapes and have been using it for hours. Decided to add an STL file so I could take a screenshot with the "real" gripper instead of my simplified shapes and within 1 min as I was rotating the camera around the error occurred.

    Also i did double check again and graphics card drivers are up to date and also openGL is running version 4.6 which appears to be the latest open GL version I can get for my graphics card.

    [OpenGL Version]

    - 4.6.0 - Build


    Not 100% sure, but I remember speaking to K-Roset support about file size limitations, but they could not provide exact number, but they say limitation is usually based around administration rights, graphics capabilities and settings on PC and PC performance and upto date drivers.

    I have upgraded to a new PC recently and I have gone through the process of updating all drivers. I also do have admin rights. Since this is happening on other PC's I'm thinking it's not graphics or driver related.


    Have you tried building project sequentially until error is produced?

    Yes, i've been working on a project for several days. started with 1 robot that has a gripper attached to the tool on an stl file with a size of 8.7mb and it's been fine. Duplicated the robot and got a crash approx. once per 3 to 4 hours.

    Added a third robot with a different gripper in the open and closed state of 2.16mb each and overlayed them and made one transparent. Error appear to happen approx. once per 2 hours.

    Duplicated the third robot and I can get the error anywhere from 10min to an hour.

    I have other projects with static stl files that are 73mb in size and I don't have any issues with it.

    Starting to think it has something to do with overlapping grippers or being on the end of the tool and the lighting/shading when rendering in openGL.

    Today i'm going to try and only rotate or zoom the view in mesh view or moving the robots and only change to shade for taking static screen shots and see how that goes.


    Have you tried reducing the size of the STL file(s) to be used?

    Yes, I have stl files of the same grippers that range from 10mb down to 1.2mb.

    Generally the more complexity the larger the size.

    If i really need to get my testing done without crashes i've added simple shapes like rectangles to the tool if i can't be bothered dealing with the crashes.

    Hi all,

    I'm getting a System.AccessViolationException on K-Roset. Just wondering if anyone else are experiencing these and know what the cause or solution is.

    I've been intermittently getting this error on different computers running windows 10 and windows 11.

    It seems to be more frequent when I have an end of arm tooling loaded in as a .stl file.

    it becomes even more frequent when I have several robots (4 or more) with end of arm tooling open on a project.

    The fault usually occurs when moving the view or zooming in or out.

    Is there a limit to the detail allowed in the .STL file? The less detail in the .stl file generally the longer I can use K-Roset before it crashes.

    I have played around with the shader options by switching between wireframe and shading. Seems to only happen when I'm on the shading view. I'll be experimenting a bit more using wireframe and only switching to shading when needed.

    I am running K-Roset version but I have experienced the same error on version 1.8.2 and 1.8.3

    Full fault details:

    System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

    at MoNo.OpenGL.GL.glReadPixels(Int32 x, Int32 y, Int32 width, Int32 height, UInt32 format, UInt32 type, Void* pixels)

    at MoNo.OpenGL.MGL.ReadPixels(Box2i r, UInt32 format, GLDataType type, Void* pixels)

    at MoNo.OpenGL.MGL.ReadDepthPixel(Point2i pt)

    at MoNo.Graphics.GLSceneContext.GetDepth(Point2i pt)

    at KHI.Fortuna.HisuiViewer.Gui.MultiViewOperation.FocusToPosition(IView view, Point2i screenPos, QuadViewPanel panel)

    at KHI.Fortuna.HisuiViewer.SceneViewerByHisui.MouseClicked(Object sender, MouseEventArgs e, Boolean snap)

    at KHI.Fortuna.HisuiViewer.SceneViewerByHisui.<>c__DisplayClass23.<View_MouseClick>b__1f(Object sender, MouseEventArgs e)

    Good afternoon,

    I have a quick question. Does anyone know how to enable the use explicit messaging on software EIP on an Econtroller.

    So far I have concluded that the Filedbus boards on D and E controllers with an Anybus daughter board is capable of using Implicit and explicit messaging. Simply put the EIP uses the Common Industrial Protocol(CIP) to encapsulate the messages as TCP/IP or UDP/IP. TCP/IP being explicit messaging and UDP/IP being Implicit messaging. The Kawasaki manual does list TCP/IP and UDP/IP for the anybus EIP daughter board field bus.

    Until now we've only been using Implicit messaging on software EIP to communicate I/O signals to our PLC but one of our client's site standard is explicit messaging and since we have migrated to software EIP it appears that explicit messaging does not work on software EIP. The Kawasaki Manual doesn't mention anything about the Common Industrial Protocol(CIP) to encapsulate the messages. There is just a disclaimer saying that connectivity with all Ethernet/IP Products has not been confirmed and that they don't guarantee it will work with all Ethernet/IP products.

    Anyways, just thought id ask the question here to see if anyone knows if there are any "settings" or zswitches (experimental or otherwise) that will enable explicit messaging on software EIP.

    I'll be in contact with Kawasaki directly but i just want to cover my bases.

    I've only seen this error twice. It was a corrupted CF card and was on an old D controller. ( like nearly 20 years old)

    And once on an E Controller with and RD80 (5 axis), think from memory it was due to a singularity and playing with FSPAL and CONF_VARIABLE. (Modes that changes interpolation of the 5th axis and dealing with singularities)

    I put the settings back to known good settings for my application and the problem was resolved.

    So the question is, what happened lately leading up to this error? Has anyone been making any changes?

    Do you have a backup? Can you take a current save and compare to the backup to see what changes have been made? What program do you currently have selected in the motion program? Also what type of robot do you have?

    I'm not sure about your specific application. One thing i really dislike is when people change base and tool coordinates without considering the consequences.

    For instance as a rule we always leave our robots with a null base. That way everyone knows the base coordinates instinctively when looking at the robot and where the plugs come out the back of the robot and apply the left hand rule.

    And since the new guys don't know any better and don't double check things before making changes it avoids the chance of mistakes happening.

    For example, years ago someone change the base coordinates on a robot by 90 degrees so they could work in the positive quadrant because they thought they knew better. One of our other service technicians went to make changes and didn't realise. They ended up damaging the tool and surrounding conveyors as a result.

    So having a standard and enforcing a standard is another challenge in it's own.

    The only other thing i would say is that the less things you change from default the less thing can go wrong or forget to change when replacing existing equipment with new equipment or copying it for a future system.

    For example. Say you have a VSD/VFD and the default setting is for the motor to run forward. but when you install it you see the motor runs in the opposite direction. You could change it in software thus changing it from default. When the VSD fails and gets replaced the person doing it might not realise they need to change the direction setting from default and potentially cause damage as they will usually wire it the same as the drive they are replacing.

    But if they installed the VSD correctly and swapped any of the 2 phases so that the motor went the correct way in the default setting this wouldn't have been an issue.

    I have a sneaky suspicion that the USB_load command has similar file name restrictions as C,D and D+ controllers where the name can only be 8 chars long and can not start with a number and also no spaces allowed. Even though USB connections are mainly on the newer controllers. I wonder if it has something to do with backwards compatibility?

    I did a quick test doing usb_load on a file name longer than 8 chars and it failed. Less than 8 chars worked fine. On an E-controller doing it through the teach pendant through the AUX menu it doesn't seem to mind what length the file name was.

    FYI the Kawasaki manual for USB_load and USB_save doesn't mention any file name restrictions

    You are not alone,

    I get a very similar message. It only happens when i use .STL files that are not native to K-roset

    My work laptop is a 2016 zbook with an AMD firepro 2GB graphics card and Intel HD graphics 520. The laptop has shared graphics and I thought originally the problem may have been because of that. But after disabling the shared graphics is still get the error.

    I find i usually happens a couple of seconds to 5 min after adding the tool. It happens when I pan or rotate the view of the robot. Sometimes it goes for an hour or more without crashing. It's very intermittent.

    I have experimented with reducing the detail of the stl model with varying levels of success.

    Next on my list is to try and see if i can update OpenGL or at least make sure i have the latest version.

    I am currently using DirectX version 12. and i'm also on Windows 10.

    Usually i just restart K-roset and carry on. The only problem is that you need to save constantly so that you don't lose your work.

    On a side note, my home PC doesn't have this issue. But that's running a coffeelake i9 9900k with a GeForce RTX 2060 super. So plenty of grunt and then some.

    This is my error that I get below:

    System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

    at MoNo.OpenGL.GL.glReadPixels(Int32 x, Int32 y, Int32 width, Int32 height, UInt32 format, UInt32 type, Void* pixels)

    at MoNo.OpenGL.MGL.ReadPixels(Box2i r, UInt32 format, GLDataType type, Void* pixels)

    at MoNo.OpenGL.MGL.ReadDepthPixel(Point2i pt)

    at MoNo.Graphics.GLSceneContext.GetDepth(Point2i pt)

    at KHI.Fortuna.HisuiViewer.Gui.MultiViewOperation.FocusToPosition(IView view, Point2i screenPos, QuadViewPanel panel)

    at KHI.Fortuna.HisuiViewer.SceneViewerByHisui.MouseClicked(Object sender, MouseEventArgs e, Boolean snap)

    at KHI.Fortuna.HisuiViewer.SceneViewerByHisui.<>c__DisplayClass23.<View_MouseClick>b__1f(Object sender, MouseEventArgs e)

Advertising from our partners