Posts by bagged2drag
-
-
The deadman switches are part of a safety system. That said, the switches can work, but if they are not opening/closing within the allotted time, they will cause the channel 1 fault. They are likely wore and need replacement.
-
-
I did expand the folds, i think the issue is more that the new changes didn't upload to the robot for whatever reason. I was also doing some IO symbol renaming at the time, and those changes did go through.
Is there a way to "go to" the error?
-
Thats why I was confused. I already corrected the error and re-deployed a couple times. Even revised my rev name in the deployment. Still didn't take care of the issue until I manually deleted the files, and redeployed it again.
What good is a line and column # if it doesn't match either workvisual or a text editor? Seems odd. I get it; it will get you close, but sometimes close isn't real helpful.
As always, I appreciate the help though. You guys are super knowledgeable.
-
I just deleted it on the pendent and redeployed it. That took care of it. Any reason why this would be the case?
-
I have attached the files.
I have expanded all folds. The error display only on the pendent only lists line 192, column 1, error 2135 "Name not declared as subprogram." I double checked and the subprogram does exist, is spelled the same. In Workvisual, I have a green box in the upper right hand corner - no red box or marks in the bar. I can deliberately manipulate the code in workvisual to make an error, but get the green box when I correct it there. The error on line 192 is an EXIT. The subroutine is called at line 196.
-
Environment: Work Visual V4.0.30, Kuka KSS 8.2.14 (I believe, or a bit higher)
Issue: After loading some new subroutines, one of them returns an error on the robot "name not declared as subprogram" for both .src and .dat.
I looked in the manuals for both workvisual and the 8.2 programming manual for SI, and I didn't see any mention of this, or differences in how a main program or subroutine should be defined. I don't see anything drastic between the routines that did load correctly and the one that didn't either.
Am I missing something here?
Thank you,
-
If you have access to fanuc training on CRC, there is a section on robot math. It goes into detail on how the robot calculates positions. It is a bit snoozy: I warn you, but it is very informative.
-
In addition, you can look at the current joint position as well by similarly entering the logic PR[n]=JPOS. you can then set registers to the value of the stored positions such as R[x] = PR[n,1] This would set the value of the register to the value of element 1 in your position register. There are numerous other ways as well, but this is probably the simplest.
Be careful with LPOS, as your user frame can affect that. Example being, if you taught a point at 0,0,0 in uf1, and you also had a point of 0,0,0 uin uf2, your logic would not necessarily be able to differentiate between the two, and you could take a drastically different path. Its advisable to either set your uframe prior to grabbing your current Cartesian positions, or look at your current user frame and jump to a section of code accordingly before looking at your positions.
You can look at active frame by setting it to a register. Example R[n] = $mnuframe (i'll have to look to see if this is exact).
D_DeVanney, in your program, you can read the actual position to any position register, by PR[n]=LPOS instruction.
Before programming this, ensure, in the the system variables menu, that $PR_CARTREP is set TRUE. -
Interesting. I know safety regulations differ between the two regions, so that could be part of the hardware differences. U.S. is generally considered more lax on safety than EU, but many of our standards are moving toward EU standards now.
Fanuc America also sends flash drives with the Core Software Backup with the new robot, Fanuc Europe does not seem to do so. Also E-Stop boards are different even between the same model controllers, and they are not compatible. There is an option with parameters that is also different between the two.American robots get the R650 FRA Params option, European instead have the R651 FRL Params option. -
I don't know if I would call the path changes "issues" per se, but if you are not aware that the path can change, well, then I guess it can become a bad day. The path difference isn't always that huge, but in tight spaces it can be an issue. I just try to spec the robots with certain options automatically to make life easy.
Yep, Romania here. I've worked with quite a few FANUC robots so far and the issues mentioned on this topic are basically news to me. Even the older models of FANUC that I service from time to time - RJ3s mostly - don't have path issues even if the factory where they were installed is on the poorer side. -
I could not agree more. V9.2 leaves nearly as much to be desired. Buying a pendent may be one of the most cost appropriate things to do for these robots. In my opinion, the web interface is horrible, at best! The mechanical unit does seem nice however.
I end up going back and forth between Chrome and IE when programming. Even though I text edit a lot of programs and ftp them to the robot, I have found that it takes me 3-4 times the amount of time to program/configure on the web pendent vs using a traditional pendent. Fanuc has a lot of room to improve this. I do think they should just include a pendent.
Make sure they ship it with version 9.10 / 12 or greater. If it comes with version 9.10/7 request a reburn. And don't take no for an answer. There are some errors that will never be corrected even with an autoupdate.This is still a new product with them. There are multiple issue with their new HTML5 interface. I would talk with them about a reduced cost Teach Pendent as it will be faster than using the new iNavigator interface. If you need BG programs you can not select the program with the HTML5 menus. Most advanced functions will need to be done using the Jog pendent, like accessing variables. -
Are you and bidsej from Europe then? I am curious about this.
Here in the U.S., we need to pay for nearly every Fanuc option. The advantage is that a base model robot is almost cost competitive with many "cheaper" brands, but it is cumbersome to those who are "not in the know."
I don't think I've ever installed a FANUC robot that would behave differently based on set speeds or overrides...and we never ordered any special features aside from what we generally needed. I was actually confused as to why people were having this issue with FANUC, but if it's different for the US than EUROPE, then it makes sense. -
Couple notes based on personal experience on the path repeat-ability depending on general override speeds: Right out of the box (IE, no special options) I agree the fanuc path varies more than most other companies-kuka included. However, if you purchase the advanced constant path option, they will indeed take the same path regardless of the general override - they then become the best. A very nice feature and well worth the cost in my experience (there are other helpful features included in the package, depending on the configuration).
The fanuc is, from my experience, the "easiest" to program, but also has the most limitations because of it. There are many items in which you need Karel (option) to do which can be done on many other robots for free. Also, when using Karel, you need to have the original source code if you want to modify the program. Only the compiled program resides on the robot. These are tradeoffs that I think are worth it, however.
iRVision is very nice, but not the most powerful out there. I don't think any other robot company really competes with it though. Its easy and relatively cheap.
Mechanically, the new iD series (lrmates) leave a bit to be desired- i have seen and heard of a lot of mechanical failures. The previous iC series were much better.
I have worked with ABB quite a bit. They (in my experience at least) seem to be more reliable and generally better built, at the expense of space. Their programming language is pretty easy and much more structured than a fanuc. The control panel is also better laid out (fanuc's is not very impressive), and the pendent (and cable) seem to be much higher quality (I see burn-in often on fanuc displays). I do not like the motion planner in the ABB as much though, as it is not near as fluid as the fanuc.
I have worked with Kuka only a bit. Coming from Fanuc and ABB, I don't find it nearly as intuitive, although it is getting easier as I go (I only touch our robot once every 6-7 months, as it is at our other facility). It is a well built and reliable robot though. Support here in the U.S. is limited though.
As a whole, I prefer the Fanuc. They are becoming very cost competitive as well, as they are (or appear to be) going after market share in the U.S. Importantly, support (both manufacturer and field) is about the best there is.
Not sure if I understand you correctly, but from my experience KUKAs are a PITA when it comes to continuous motion, as the paths change with the override, not with the programmed speed.
With Fanuc, if you program a motion, the robot will move identically in T1 at 10% and in AUTO at 100%. With KUKA - no way, you won't know what the path is until you run the program with override set to 100%.That thing about being accurate... Well, I can't really agree on that too, especially that it's possible to increase the accuracy of Fanuc robots using "absolute accuracy" option/procedure. The difference here is negligible in most cases.
There is a couple of things that I find as KUKA's advantage:
1. some heavier robots' designs - without the additional arm in the back, which substantially increases the work envelope. On the other hand, the smaller, hollow wrist robots by KUKA are quite bulky and clumsy.
2. easier setup of many functions and options. This is mostly because the controller is Windows-based, which allows it to use many features of a "civilized" OS. But, again, on the other hand - it can be a cause of quite some problems with KUKA controllers (of which being laggy is the tiniest one). -
If you are looking to do what you originally wanted, you can use the high speed skip condition (if equipped). It is also more accurate if positional accuracy of the skip condition is imperative.
-
Does each input work independently as they should? Can you describe how the two devices are connected (discreet through built i IO, model A, model B, ethernet i/p etc)? Robot IO configuration may help to look at, as well as some sample code.
I still am steering toward an electrical issue, especially if it is built in io (crma58/59), as it is easy to make mistakes wiring that up.
Regards,
-
Check your wiring. Something is backfeeding on your IO card likely.
-
The devices have static IP's, which I would expect, but if it is an un-managed switch, the switch is going to be DHCP. Again, with such few devices, I wouldn't expect this to be a problem, but it is a possibility.
What are you using for Ethernet cable, per pdl's question? Is it shielded? Cat5 or Cat6? Cat6 is recommended.
Addendum to first post: UOPs are mapped to rack 89 Ethernet.
Fabian - thanks for your suggestion. There is a heartbeat but it is of no use in this situation: the UOP IMSTP is getting dropped.
Bagged - it is an industrial un-managed switch, with nothing on it but the PLC and three robots. All four devices have static IPs.If I can figure out how to insert an image here, I will post a screen-shot of the network configuration: I added img /img and tried to paste my clipboard image, but it is not showing . . .
-
I have seen switches set up using DHCP cause this problem (usually a MUCH larger network of devices though, based on your description). We had a similar problem once. We would randomly drop connection, and anytime someone powered down a piece of equipment on the network, it would take out a few PLC and robot connections as well. We ended up setting static IP's on the switch (you need a managed switch). Each port was exclusive to a specific piece of hardware then. This completely eliminated the issue. The biggest drawback was that you HAD to make sure you plugged everything in to the appropriate port.