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.
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.
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.
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.
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.
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)
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
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)
The site is telling me this thread is likely obsolete but I will post here anyways because my issue is directly related to this topic.
I get an error message shortly after adding the STL file. The tool model appears but if I move the 3D graphic window in anyway KRoset crashes and I get this error:
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.ReadDepthPixels(Box2i r)
at MoNo.Graphics.GLSceneContext.GetDepth(Box2i rect)
at MoNo.Graphics.StandardViewOperationBase.OnMouseUp(MouseButtons button, Keys modifier, Point2i pos)
at KHI.Fortuna.HisuiViewer.Gui.MultiViewOperation.OnMouseUp(MouseButtons button, Keys modifier, Point2i pos)
at MoNo.Graphics.ViewOperation.OnMouseUp(Object sender, MouseEventArgs e)
at System.Windows.Forms.MouseEventHandler.Invoke(Object sender, MouseEventArgs e)
at System.Windows.Forms.Control.OnMouseUp(MouseEventArgs e)
at MoNo.Graphics.GLViewControl.OnMouseUp(MouseEventArgs e)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.UserControl.WndProc(Message& m)
at MoNo.OpenGL.GLControl.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Has anyone seen something like this before? I have tried the above procedure as well as the procedure provided by Kawasaki found here:
Content embedded from external sources will not be displayed without your consent.
Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
This procedure had me create the .krprj files so i also tried just importing those with the same error.
Any ideas I could try would be greatly appreaciated!
D/E controller you can setup a trend on the data logger with a minimum period of 2ms to gather real time XYZ and other information such as inputs/outputs to name a few.
On the E Controller you can export it onto a USB drive as a CSV file.
I'll just leave this file attached here and you can look into yourself.
Been ages since I have done this on a live controller:
- Try out a sysinit when in Teach Mode and Teach Lock is OFF and see if the message appears or executes the sysinit.
- Then you'll know if it is tied to just the Teach Lock and not also Repeat Mode.
I know this for a fact to be true on a live controller, which is why i mentioned it. Because the only time i come across this error is if I left the Teach Lock ON when doing a sysini. Robot can be in teach or repeat when doing sysini as long as the teach lock is off.
So by definition, in KROSET you always need to be in Repeat to 'force' the Teach Lock off in order to carry out a sysinit.
That's what I suspect is happening when using virtual controllers such as Kroset.
Edit :
When working on live robot , before anyone reading this thread is tempted to do a SYSINI, i always suggest making a backup of your code and only use SYSINI for legitimate reasons to clear the robot memory as it will result in changing high level system switches which could have adverse effects.
I recommend using SYSINI/U to only clear the User data as this will leave the environment data and high level system switches as they were.
On a physical robot "P1020: cannot operate, teach pendant in operation." is generated when the teach lock on the pendant is ON. This will happen when the robot is in repeat or in teach when you try to do a sysini.
My guess is that in the simulator when in teach, it must be virtually turning on the teach lock automatically and turning it off when going to repeat.
If you are using F Controller, you have a selectable stop category between 0 and 1 available under Aux Func 0535 and additional information for this is offered in the relative external IO manual for F Controller.
I haven't had the pleasure of working with an F controller yet. I'm more familiar with C, D, D+ and E4x and E0x variants.
The reason I asked, is I was at a site recently, that was a palletising app and there is a cutout in the safety fence for an operator to lean in and manually place a layer card on the pallet.
This cutout is guarded by a light curtain and is directly wired to the external input.
Yeah no worries,
Ideally what they should do is have a selective prohibited zone with Cubic S. When they enter/ break the light curtain the area where the operator places the sheet becomes prohibited by a dual channel safety input into the Cubic S unit. That way the robot can continue it's normal duties, but if it ever attempted to access the select prohibited zone when the zone hasn't been reset then it would be Estopped by the cubic s unit.
Once the zone has been reset, the robot is allowed in the zone.
Just remember when calculating light curtain entry speeds that if it's for hand protection the entry speed is generally 2.4m/s where as waking speed is considered 1.6m/s and depending on the lights curtain beam spacing you may need to add 850mm due to the chance you can fit your arm between the beams.
If in doubt, best solution is to get it 3rd party verified by a safety expert.
- What deems the external hold (as a standalone input) on the Kawasaki as stop category 2 and not possibly either stop category 1 or stop category 2?
The hold / external hold is just a controlled stop and doesn't inherently remove the potential energy to the motors, thus category 2.
Category zero removes potential energy immediately, Where as Catagory 1 attempts a controlled stop and the potential energy is removed regardless by the safety function a few milliseconds later.
Put it this way, category 2 is like turning off the output from a PLC that commands a VSD/VFD or DOL motor to run. Any malfunction or accidental turning on of the output or cross wiring will make the motor run. But if you remove the three phase energy with dual contractors with an electronic device monitoring feedback means that there is no way that if the motor is commanded to run that it can actually move or cause injury.
Electronic device monitoring feedback (EDM) is there to detect if any of the contractors welded shut and is wired in series through the N/O contacts. Thus The EDM should be the opposite state of the contractor coils. EG. if the contractor coils are de-energized the EDM is ON. If not then the safety PLC/relay can generate another fault and prevent the safety circuit from being reset thus preventing a potential dangerous situation.
So obviously an Estop event or loosing the Safety Circuit input would be an example of a Stop Category 0. Then I'm assuming a External Hold would be a Stop Category 2. What would be a trigger for a Stop Category 1? Looking at the 1Tr board connections nothing jumps out to me with that capability.
Sorry for the slow reply, i've been snowed under with work at the moment.
Yes external hold would be classified as a cat2 stop.
A cat 1 stop can be done from the Cubic S unit or safety PLC where a signal such as External hold dropped when the safety function occurs and the safety contacts of the X7 plug is dropped roughly 500ms later or whatever time is deemed safe by the safety calculations.
Right now our cells with shock sensors have those tied into the safety gate connections on the X8 connections, what would be a better place for those connections?
I haven't personally haven't used sock sensors connected to the safety gate inputs so i wouldn't be able to comment. I generally don't use the safety gte wiring since we use a Safety PLC that drops the X7 safety when our gates are opened.
We have the collision detection option but it was never implemented by the OEM. That along with the auto recovery is one of my long term projects. As far as my experience level I have about five years as a Controls Engineer at a Tier 1 Supplier to the Auto Industry (fanuc,Rockwell PLC's and HMI's). This was a production support role with minor projects sprinkled in. The Rs03N training cell will be the first integration project I've ever attempted. My role now is as my new companies primary robotics engineer. So I still do production support but the electricians are meant to be the first line of defense, with my primary focus being on training, continuous improvements, problem solving. All my Kawasaki experience has been gathered over the last year at my new employer. I did attend a AS Language course back in March which helped kick my skills up a couple nothches.
To be fair collision/shock detection is only there to stop the robot from snapping it self in half. Depending on the application and speeds/payload involved you generally don't rely on collision detection unless something catastrophic happens and the robot crashed. You'll still end up with damage to the tool and other obstacles but at least the robot will eventually stop before breaking the arm in half.
I would recommend having it turned on even if the thresholds are set too high, because at least you know the robot will come to a stop before it breaks in half. Obviously Cubic S is the better solution when there is an increased risk of collision with objects if implemented correctly.
You are lucky to be based in the US and be able to do the AS Language course. I have built up my knowledge of Kawasaki's with on the Job training and reading all the manuals over the past 10 years at my current employer. My previous background was Systems integrator for another company dealing with all sorts of automation.
I have also dabbled with ABB robots from time to time, but i definitely prefer Kawasaki's
In any case, I wish you good luck in your endeavours. Who knows we might even cross paths or already have...
Regular crashes due to operator error. That's more or less how I was able to present this as a justifiable expense, that yes there are improvements needed to the cell but with "untrained" operators being the primary users of the robot then we are just going to be repeating the same mistakes over again unless we overhaul our training program.
Regular crashes does not sound good at all. I'm not sure of your application or circumstances but some operator error resulting in crashes can be mitigated by better robot code most of the time. As with most things if they are implemented correctly it works as intended. Even Cubic S won't solve your problem if it's implemented incorrectly, For example if the tool shape is set improperly or the robot isn't correctly zeroed.
I don't know how much experience or robot knowledge you have. If your robot crashes are due to the robot being driven in teach, then you could use XYZ moving area to try and limit this in conjunction with changing the collision/shock detection settings for teach mode to be much more sensitive.
If it is due to the scenario above then the next thing would be to reduce the frequency of why they need to drive the robot in teach mode in the first place.
Maybe spending some time on having a good autorecovery procedure is worth investigating and implementing. Basically what i'm saying is i would be looking into the root cause as to why the the crashes are occuring, but it doesn't hurt to put extra safeguards in place for the human factor too.
And say for the 10% of the time it can't automatically be recovered due to being outside of certain limits or thresholds then they can still go back to the original method of manually recovering in teach mode.
Either way i'm just speculating since i don't know your situation, but from my experience we don't allow operators to move robots, only trained maintenance staff and even then it's pretty rare that they would even have to drive the robot in teach in the first place.
As this will be the first Robot system I've integrated myself sorry if I have a few dumb questions, for instance when you say category zero stop are you referring to rating from RIA TR R15.306-2016? Or is this a Kawasaki term I am unfamiliar with?
Depending where you are in the world there are different standards but specifically i'm referring to the following:
Stop Category 0: Stopping by immediate removal of power to the machine actuators (i.e. an uncontrolled stop – stopping of machine motion by removing electrical power to the machine actuators)Stop Category 1: A controlled stop (stopping of machine motion with electrical power to the machine actuators maintained during the stopping process) with power available to the machine actuators to achieve the stop and then removal of power when the stop is achieved Stop Category 2: A controlled stop with power left available to the machine actuatorsSo in the case of a kawasaki robot if you don't have Cubic S or any other fancy Safety PLC if you break the safety circuit the robot comes to a violent stop due to the servo motors power and brakes 24 volts being removed and stopping the robot in a fairly short distance this is Category 0 stop.Category 1 is giving the robot a set amount of time approx 500ms to start deccelerate before the safety circuit is opened thus achieving a more gentle stop but with a larger stopping distance. Sometimes due to the distance from light curtain and a robot you will not be allowed to use a Category 1 stop. Catagory 2 is pressing the hold button on the teach pendant or the robot going outside of the XYZ moving limits. The robot comes to a controlled stop and the power is left on ready to continue. The safety circuit is not opened. Clearly category 2 is not used for when humans are in the enclosed space with a robot for obvious reasons.
I did noticed on my K-Roset Simulation that when the Robot exited out of the Moving Area XYZ Limit that it coasted for a bit before stopping but I didn't know it could to that extent. A bigger enclosure or Cubic-S sounds like the only option.
The speed at which the robot moves before pressing hold or going outside of the XYZ moving area will affect how much the robot coasts to a stop.
As mentioned before Catagory 2 stops is not safe. And generally speaking Category 0 stop is default, and Category 1 stop is used in certain circumstances if other safety criteria can be met.
Just a quick disclaimer, everything said is my opinion and my views and when changing or doing anything regarding the safety stopping method or safety wiring on your robots is at your own risk and I highly suggest you have it 3rd party verified by a certified professional and according to your local standards and regulations.
www.robot-forum.com in the WSC-Connect App on Google Play
www.robot-forum.com in the WSC-Connect App on the App Store
Download
This site uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.More DetailsClose
