Judging from the docs I have, it looks like OPC-UA is not supported prior to v9.10. On older versions, you are stuck with the SNPX protocol.
Posts by Nation
-
-
-
While word is fine for the merge and search method described above, I'm seconding hermann. Don't use it for editing .ls files. Only use a text editor for that, such as notepad, notepad++, ultraedit, or equivalent.
The reason is that word will add additional meta data to the file, making it unloadable.
-
Isn't the analog channel of which scale you can change?
No, its the scale of input to the DPM schedule. It could be analog, or in your case a Karel var. In my case it was a group input sent from the PLC. My pitch correction wasn't responding quick enough, so I dropped the scale, and that solved the issue.
-
I personally asked JT for the source back when he was active, but he didn't want to give it out.
-
Well, JT hasn't logged in in 2 years, so I have my doubts that he will see your request.
However, even without the source code, you can hex edit the karel file to make it work on v9 controllers.
This is what I did, and I tested it with v9.30 Handlingtool, and it works.
Modified .pc file is attached.
-
What are you using it for?
-
I assume it would be 1-$IDL_CPU_PCT.
-
Are all the parts circular in nature? You may be able to get away with just teaching a circle as your gpm, and opening up some of the parameters so it finds anything circular. I did this in a foundry with a ton of various castings.
-
You could change the scale of your channel inputs. Increasing it will cause the robot to respond slower.
-
Could be inertia mismatch. The load the servo is driving is not supposed to be more than a factor of 5 greater than the servo's motor inertia. Otherwise jerky operation occurs.
-
Do you have filtering enabled after the offset on the DPM screen? Also, have you played around with the $a1 and $a2 filter vars in each channel? The manual lists them as exponential filters, but fails to go into more detail.
-
Close, but I suspect there's one extra link in that chain: CNC controllers. I don't know for certain, but what I've seen strongly suggests to me that Fanuc robot controllers and CNC controllers are almost the same beasts, under the skin -- the robot controllers are just "CNCs" with lots of extra axes, and a more complex kinematic model. CNCs came along first, and Fanuc is pretty big in the CNC controller space. And CNC controllers started out a lot closer to early microcontrollers than computers -- G-Code still looks a lot more like Assembly language. I'd be willing to bet that, when Fanuc decided to get into robots, they grabbed their existing CNC controller and just added more axes. There's obviously been some divergent evolution since then, but the roots still show.
Its the reason they changed the naming pattern from RJ3 to R30iA, to commonize the naming scheme with their CNC line. One of the Fanuc salesmen told me this though, so take that with a grain of salt. Now it is diverging again, as the CNCs are up to 32i, while the robots are still at 30i.
-
That is one of the nice things about Fanuc. They haven't really changed their language or their pendant in the last 25 years. They have added onto them, yes, but all the stuff that was there 25 years ago is still there.
-
I think that is a mechanical arm number. What arm is your backup using?
-
Sorry for my lack explanation
By the way, do you have explanation of every karel program explanation?
I want to study about it.
No I do not. I found the INVERSE explanation in the iRvision manual, under section 8.1 Vision Support Tools. For GET_HOME I figured it out after someone ran it and blew out PR[1] on a cell I was working on.
Thanks
then, do you have ever tried this function?
if yes, do you have some example for me to learn?There is the R798 DRAM File Storage Option. It allows the controller to fetch tp files from locations other than CMOS. I haven't messed with it, but it looks like remote locations are possible.
-
There is some wiggle room. I personally have taken a RJ3iB Ipendant and used it on a R30iA controller. The operator had left the R30iA's pendant on a chain conveyor and it got sucked in and destroyed. It just needed a firmware update to work. I would call Fanuc before attempting such swaps though, and I did in that case.
-
You don't. Leave the jumpers in and use the Safe I/O area under the DCS menu to connect the safety level input/outputs appropriately. The DCS manual goes over what the bits do.
Here is an example I've used on a past job:
Code -
There is the R798 DRAM File Storage Option. It allows the controller to fetch tp files from locations other than CMOS. I haven't messed with it, but it looks like remote locations are possible.
-
My theory:
I believe Fanuc modeled portions of their TP language on assembly, because it is simple.
I think the reason they use registers, and the reason they are named registers, is because registers are used heavily in assembly language. A typical CPU has various registers that can store values, and are always at fixed address, so that is why I believe Fanuc went this route.
This makes the barrier to entry for the average plant guy on the floor pretty low. For example, they don't have to know about the various types of data types, or what a variable is, or how it is scoped. Here are your registers, you get 200 of them, they store numbers, you can get to them from any program, have fun. Same for PRs, but they are positions.
This is a double edge sword though, as while it easy to understand, TP lacks (or lacked for a long time) some of the more basic program flow structures virtually every language since the 70s has possessed. This also makes doing anything complicated in TP a pain, since you have to have work around the limitations of the language. This also tie's into SkyeFire's point where you need to buy an option to do anything complicated.
