Posts by yogene

    Hi there!
    I have the similar task, the topic appeared right on time. The problem is to implement AVC function on TIG welding system. During the arc burning the piwersource tramsmits real voltage to RC via interface - it's standard feature.
    The difference is that I have the correction parameter as 16 bit digital value, not an analogue. Seems kind of online value converter has to be written.



    OK then, back to fiddling with IOSYS.INI to get that analog input working.


    Thanks again !


    Please do not leave the topic, place any results here. So I'll post mine too.

    This is the robot system installed in a welding laboratory, not a production. It never works in full auto mode, usually the welding tests are performed in T2 or "run once" mode.
    I've used ArcTech before, while I dealt with GMA welding. Even if I has specific tasks, I had been always able to use a20 subprograms and variables in my own constructions. But recently I've reequiped the robot with TIG welding and got a lot of troubles with high frequency arc ignition (touchless start being performed by high voltage discharge). Besides interface freezing from time to time, Kuka had even reset the axis mastering once. I've grounded the torch body, so the situation had got better.
    But the bug with ArcTech I've never fought off: during weld start the arc strikes for a moment, stops immediately and controller displays "Arc ignition fail". Most cases the second ignition try is successful, but not always. Surprisingly found that if the arc is switched on manually with corresponding output, reliable ignition appears. Thought it's my old robot bug, but recently I'd met the same behaviour of a customer's KR5. Their application allows to just program several tries of ignition with automatic error reset between.
    I'm in touch with local Kuka guys, but the only thing they adviced is to increase maximal ignition time in $config.dat, but it had been first I'd done just after the problem had been discovered - never helped.
    For me I'd found the only way to write own arc handling library. I use a_hot_weld_enabled variable to handle the Weld on/Simulation button, $PRO_ACT for arc off if the program stopped. The last thing is hot start after resume the program run.
    Today I've finally found the KSS 5.x system variables alphabetical by lot of scroll down of google search results.
    You're right, the $PRO_IP contains SNR and SNR_C fields, which represent current advance and main pointer strings numbers accordingly. By just saving the number of string the program interrupted at and comparison it with active string on running resume the problem is solved.

    I agree with previous reply. I met the same by one of the customers, so local Kuka representative suggests to replace entire pendant, but perhaps the background lamp could be replaced separately.
    As the temporary solution the external monitor can be plugged to controller PC.

    Hello,
    I'm trying to compose the solution of restart of the tech process (arc welding) after the program was stopped on the process path and is resumed again. At the moment I trace $PRO_ACT to stop the process with the main program interrupted event.
    The problem is how to determine if the program resumes from the line where it was stopped at. It is necessary to avoid the situation when operator puts main pointer to some else program line during program deactivated and robot goes away from the process trajectory, but the $PRO_ACT flag gets up anyway.
    E.g. Fanuc controller reminds if user tries to launch the program not from the "stop-line" and I'm pretty sure there is some binded system variable which could be caught. Kuka doesn't care if the runtime pointer has been moved by operator manually and dispays no warnings concerning, but I hope the flag exists.
    If so, what's its name?


    SI: KR5 Arc robot, KRC2 controller, the ancient 5.5.7 KSS version

Advertising from our partners