Advertising

Posts by dexterv

    Well if this is the PILZ safety controller and this is the case, why not follow their solution and restore the program from the memory chip? But I am guessing that there are more reasons possible for the error LEd since you didn't change the chip card. Most likely it is a wiring issue check if the light barriers have output indication and if the trigger the corresponding change in the inputs of the PILZ controller.

    Well PILZ make safety relays and you have an error about safety. We don't have all the information we need so it is just guessing but you can have the barriers working fine and still have messed up signals at the relays/controllers. When did the error occur did someone do some work on the robot/wiring?

    I have made the connection between the KUKA.sim and the real robot.

    It works for the axis but when i want to add a digital input or i put it doesn't want to.

    Does anyone have experience with connection the real robot I/O's with the ones in KUKA.Sim?

    You connected the Sim to a physical robot? You need to provide quite a lot more info I think.

    As I already said, nothing has been changed on the OPC. There've been no updates to VRP, either. It could perhaps be a Windows issue, but one laptop is running Win7, and the other Win10. Both are throwing the same error.

    I was thinking exactly for something changing on the windows side of things... I hope you find a solution.

    So it looks like you are making a non-safety rated PLC deal with safety in EXT mode, which is by description not safe. In order to match the STOP categories of the enabling switch - for a release of the switch you can remove the $MOVE_ENABLE signal which will cause a STOP2, If the key is presses (panic mode) you can change DRIVES_OFF to have a STOP 1. Again this is not recommended.

    This will not work as this is just a comment. What you need to do is edit this block by using the SmartPad. Alternatively the newest versions of WorkVisual can edit ILF but you haven't specified any versions of the KSS.

    Well, no, since there are initializations and declarations that take place in the beginning of the file hence the error. You can create a new program with all the declarations and just the welds you need. You cannot cut corners I am afraid.

    Without the actual code it is difficult to tell but you seem to be missing the interrupt declarations, you are either not running the program from the start or this src is meant to be called from another or the declarations have been deleted. I may be wrong but this is as far as my Polish and Italian can take me.

    Hi, I'm having trouble running KukaVarProxy on WinXP KRC4. I get an error when I try to register .ocx. And when trying to run Kukavarproxy the error: Win32 Accees denied. I was logged on the admin. Someone had a similar problem? KukaVarProxy running on KRC4 with WinXP?

    So you decide to spam every thread mentioning KUKAVARPROXY instead of making your own? Not the best way to get help, even if you are in a hurry. Also look at the read first page you are not giving almost any information...

    Fubini Thanks for the info. That is a lot of documentation for 5 people... You spent 15 years there, nice. I gather you were working on KRL development or control systems by your deep knowledge of the internals.

    panic mode I didn't realize you were with KUKA at some point - KUKA USA I presume. I was certain for fubini, just not for yourself. In which general part of the company if you don't mind me asking?

    Re: KSS 8.x: C_DIS vs C_PTP


    Here is a table I posted quite a while ago when which criteria is used. Maybe this helps.


    Fubini

    It does help, so does the post afterwards, which I have read but just know figured out after I have come to the same conclusion. Just a shame it is not well documented. I will get someone who speaks German better than me to double check the table just in case I read something wildly wrong.


    panic mode Sure the function is not published. OL can be used with KUKA.Sim to compare trajectories and see what is generated to some extend, but surely the parameters of approximation must and can be explained better in the documentation.

    PTP type motions support CDIS and CPTP

    CP type motions support CDIS,CVEL,CORI


    motion instructions support up to two such parameters and will respond to whichever happens to be the first one encountered along the path.

    The supported types are well documented, no questions there, can you elaborate a bit more on "and will respond to whichever happens to be the first one encountered along the path."


    What I observed is that around the approximated point during a PTP>LIN move the approximation uses two $APO parameters for both CPTP and CDIS I have attached some ss from KUKA.Sim: it goes CPTP 100/CDIS 100