Posts by SkyeFire

    Have you tested this using a "raw" browser command first? Typically, for a RoboGuide virtual robot, you should be able to point a browser directly to "http://localhost/KAREL/prvi?object=DOUT", and see that the string variable Object becomes "DOUT". Any errors in the KRL will be shown on the virtual pendant, so make sure you have it active.


    For testing this way, it would also help if you set up a return string to the browser, as shown in the Internet Options manual.

    Another item: the truck that carries the KR and KRC should be an "air ride" trailer, or something similar. The robot is fairly robust against vibrations, but the RDW board in its base is more fragile. And I've had KRCs destroyed by shipping only 200km, on good roads, using a "normal" trailer.


    If you can't get an air-ride trailer, then the KRC should be supported on some kind of shock-damping cushion. Something like these Pallet Pillows -- they should be arranged such that the weight of the KRC is carried on the pillows. KUKA uses something similar when shipping KRC2 from Europe, as I recall.

    Well, your detailed telnet appears to show that the device has 3 bytes in and out. It's possible that the unit on MAC Address 10 has some diagnostic/control bits on the first byte. I would try expanding your x1 to x3 in IOSYS.INI, do an IO-Reconfig or cold reboot, and see what happens. If this does not generate any Devnet errors, then your I/O might be mapped somewhere between 9 and 24.

    One issue I saw a lot when $OV_PRO was being controlled from the SPS was that, hitting the +/- keys on the KCP fast enough would "decouple" the displayed speed from the actual speed. So the playback speed on the +/- softkey would not longer be correct. But, if you monitor $OV_PRO using the VarCor, you should see that it's always limited to 30, no matter what the softkey display shows.


    Basically, the SPS code works properly, but somehow the refresh between the KUKA HMI and the actual runtime gets broken.

    I have created a GLOBAL variable INT. I want to read and write to that variable remotely via an ethernet connection.

    "Ethernet" is a cable type. There are literally hundreds of protocols that can run over that cable. Which one do you want to use, and which ones does your robot support? As Panic says, each protocol will probably require a specific option package on the KRC4.

    Other robots i have(KR210 2000series) don't have that limit switches...

    It was an optional package, a way of getting safety-rated axis range monitoring before SafeOp was available. The aluminum arc would carry pairs of small "rails" with bevelled ends. These rails would be cut and positioned such that each rail would trip a single safety-rated safety switch whenever the axis was between two particular angles. These switches would then be wired back to a safety relay circuit or safety PLC.

    Does your robot have EIP adapter, or scanner? This is important. If the robot has the Scanner option installed, then it's fairly simple to connect it to an EIP I/O Adapter module that, basically, converts simple hardwired discrete I/O to/from EIP.


    I generally like the Turck TBEN modules, they're nice and simple to set up, but WAGOs aren't bad.


    If your robot only has the EIP Adapter option, then you'll need to upgrade the robot, or use a PLC to act as the Scanner.

    You absolutely DO NOT need RSNetworx to to configure an Ethernet/IP module. What you do need are the input, output, and configuration assembly instances. You may need the vendor ID, product type and revision, but I have successfully left those all set to "0" and the device still worked.


    RSNetworx is a nice piece of software to aid in configuration, but is in no way needed to implement the Ethernet/IP protocol.

    That was kind of my gut feeling, but trying to build the robot scanlist for this module by hand just got me nowhere fast. That said, I think it's an information problem -- all the docs for connecting this module were written around using RSNetworx, and I was unable to find a source that could describe what I actally needed to type into the EIP Config to get the communication working.


    Now that I have those settings, thanks to RSNetworx, I should be able to just hand-copy those settings into another robot for the same module. Or, for a large-scale deployment, copy the IO config file out to multiple robots.


    EDS files are nice, but I feel like vendors have taken advantage of them, and the tools that use them, to get "lazy" about actually describing the scanlist settings for some modules in a clear, concise fasion.

    Also no details, like version numbers, how the weld parameters were set up, etc.


    Brute-force method? Open up the /TP/ArcTechBasic directory, and change the Properties of each module so that they're visible. Then see which line the program stops on generating that message, and work backwards from there.

    Well, I haven't run into a KSS 8.6 robot yet. I suspect not a whole lot of people have.


    Do the new robots come with the KSR stick "free", or do you have to buy them separately?


    I would be annoyed that the older sticks can't be upgraded, but backwards compatibility can only stretch so far.

    I'm guessing that since there is a <= for the fast clock evaluation, it is evaluated true immediately.

    D'oh! I should have realized that. Of course, that raises the question of why the original programmer used any of this logic anyway.

    Is DO[111] set to the complementary for DO[112]?

    Nope, completely independent signals. DO[112] and the Flags are controlled by the foreground task, but DO[111] is only controlled from the BG. The idea seems to be that the foreground task could trigger this handshake cycle with a remote device by setting the Flag and DO[112], then the BG would handle turning on DO[111], then turning it off once the handshake came back on DI[102].

    I work in the automotive industry, and our plant management has asked me about it before because of all the downtime we experience due to cables being cut and tangled together. We already have cable reels installed on all of our controllers but that doesn't really solve the problem. The operators and process techs still leave them strung out to be cut and damaged, and we have no way to track who is leaving them in that condition to discipline them. I explained to them all the reasoning as to why they don't make wireless pendants for industrial applications, but they didn't seem satisfied.

    Wireless teach pendants have been in the RIA safety specfor ten years now. But none of the "tentpole" customers appear to have been willing to be the guinea pigs for the first actual release. Your managers may want wireless TPs, but I'd bet your corporate safety office would have a very different reaction if anyone asked them -- that's been my experience in the industry.

    Is there any possibility to cancel actually chosen program?

    No. The CWRITE Run/Stop/Cancel commands work on interpreters, not on programs. So "CANCEL 1" clears the entire active program stack in the Level 1 (Robot) Interpreter, the "foreground task" where your motion programs are executed. "CANCEL 0" clears the original SPS. On newer robots that have Multi-Submit, there are additional numbers available, one for each added interpreter.


    Note: as far as I'm aware, interpreters can CWRITE command each other, but not themselves. I'm not sure if Multi-Submit has any extra limits on this, as I never worked with it much.

    Hey, all. I've inherited an R30iB Mate that has some BG Logic I'm trying to figure out, that makes use of $FAST_CLOCK:

    Code
    IF (F[7]=ON AND DO[112]=OFF) THEN ;
    GO[1]=6 ;
    IF (DO[111]=OFF),R[9]=($FAST_CLOCK) ;
    IF ($FAST_CLOCK<=R[9]),DO[111]=(ON) ;
    IF (DI[102]=OFF),DO[111]=(OFF) ;
    ENDIF ;

    F7, DO102, and DO112 are controlled from the "foreground" program.


    Now, if I'm reading this correctly, DO111 will only turn On once $FAST_CLOCK rolls over the top, which seems like it would be a huge time delay. However, I can't find any references on $FAST_CLOCK's max and min values, and how/when it rolls over -- the System Variables manual shows all these as "Not Available" :icon_rolleyes:.


    But watching this program run, DO111 is coming on almost immediately after F7 is set On and DO112 is set Off. So there must be something about $FAST_CLOCK that I'm not understanding correctly.


    I have done a full program dump and confirmed that DO111 is not turned On from any other logic in the controller.

    It's working fine with no PLC -- just the robot as the EIP Scanner and the Balluff as an Adapter.


    But all of Balluff's documents are about connecting the module to a AB PLC. I did get a tech note about using RSNetworx to set up a Balluff device with the R30, but after doing it, what I saw leads me to think that RSNetworx may not actually be necessary. That's the question I'm looking to explore.

    Anyone have any manuals for using the KUKA CodeSys Tech Package for KSS 8? Preferably KSS 8.5, but 8.3 would probably be helpful. The last time I used it was on a KRC1A back when they were the New Hotness, so I'm pretty sure that the manuals I have from then are a bit outdated now. :icon_rofl:


    I tried the KUKA download portal, but (as expected) found nothing.


    (obviously, only the "open" manuals, not the restricted KUKA College manuals)

    I recently encountered the use of Rockwell RSNetworx to create an Ethernet/IP scanlist for an R-30iB (v8.3). This happened b/c I needed to connect a Balluff EIP-502-105-R015 directly to the robot's EIP Scanner, and Balluff's tech support told me this could only be accomplished by using RSNetworx.


    After getting it done, though, I'm not sure Balluff was correct about this. Dowloading the scanlist from RSNetworx into the robot completely wipes out any EIP settings that were already present, but once that was done, I was able to see the module parameters in the pendant's EIP menu the same as if they had been entered by hand. And I was able to add an additional module (a simpler Turck unit that didn't need RSNetworx) by hand via the pendant afterwards, without causing any issues with the RSNetworx-created entries.


    That said, the Balluff unit shows up in the robot as 4 different adapters (only the first of which was activated). I'm not sure if this was just "cruft" created as a side effect of RSNetworx, or something else.


    I don't have the time to experiment with this robot, unfortunately, but I'm curious what other people have encountered. Are there I/O modules which must have RSNetworx to connect to the R30, or are these modules just so complex (or so badly documented) that trying to extract the correct settings from the EDS file to enter on the pendant just becomes nearly impossible?