K-Roset Error System.AccessViolationException

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 1.8.4.18435 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)

Quote

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.

Quote

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.

Quote

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.

Update,

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 30.0.101.1404

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

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.

Quote

My theory is the rendering process required graphically to keep up with the screen perspective changes are overflowing some internal memory/process buffering within the engine and graphics card and crashing it.

ie amount of facets/faces etc within the STL model itself or graphics incompatibility settings.

Which really Kawasaki are the only ones whom could technically qualify this or not.

Option 1:

Do you use/have you heard of BLENDER?

I use it all the time to reduce STL files when K-Roset has trouble with them and works really well.

It was recommended to me by a Kawasaki applications engineer, specifically to reduce STL file sizes not to fix issues within K-Roset.

That maybe worth a try to whilst using your existing method of adding the STL's to the Null Tool.

If you can get hold of it, I can send you a quick guide on how I adjust STL's if your interested in trying it?

Option 2:

It may just be simply your PC specs need tweaking on the graphics usage side to be made more compatible with K-Roset.

Display More

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.

Quote

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.