Robot controller -> FD11
I edit the USRPROC.INC file using Notepad++ on PC, and then copy it to the WORK/PROGRAM folder.
Then I want to convert the language from source to exe. But I can't find this file in the PROGRAM folder.
So, what's the problem?
Thank you.
You have three choices for sending positions to the robot: DPM (software package), Stream Motion (software package), and Socket Messaging (uses KAREL and TCP).
If all of your pick and place operations are pretty much the same, DPM might be the way to go. It's designed to dynamically modify a previously taught path based on real time sensor data. However, if you want to give your machine learning algorithm more flexibility to create the path the robot follows, then you want either Stream Motion or Socket Messaging. Stream Motion is a fairly new package from Fanuc. I've used it a bit but haven't had much luck with it (frequent OS crashes, often complained about jerk or acceleration limits). Socket Messaging is essentially Fanuc's prototype of Stream Motion. It is essentially what you described -- the idea is to fill a buffer of positions using data from your controller, and then have a TP program loop through those positions. My company uses this approach for our own application -- I was doubtful that we would have the fine control we wanted over the robot, but it actually works really well. From our own experimentation, we found that using a circular buffer of three position registers with high speed and CNT values works really well. Fanuc has example programs for this, but they're more complex than they need to be and use unnecessary features that break compatibility on robots that do not have those options installed. All you really need to do is have a KAREL loop fill position registers and set an output indicating that that position is valid, and a TPP loop waiting for each position to become valid and then move there.
The fastest you'll be able to update is every 8ms, that's a limit imposed by the controller itself. Someone mentioned a specialized software packate that ran every 2ms, but honestly you probably don't really need it that fast. Play around with the timing of your position streaming and how far apart each point is.
Are you asking if streaming positions has all of the same capabilities as a TP program? The answer to that is probably not: since you are dynamically streaming positions, you are necessarily taking away Fanuc's ability to plan it's path. You will still have good motion, but you might not be able to do precise path planning -- for example, a TP program could move in a circle by using several Arc instructions. If you wanted to stream the same path, you might send several hundred points on that circle. However, there is no guaruntee that Fanuc will move in a perfectly circular motion (still, it would almost certainly be essentially the same path). That's the tradeoff you would be making, but I don't think you'll run into any issues because of it. As for other capabilities, it would be pretty easy to expand your system to be able to set IO, read and set system variables, etc, so in that sense you aren't losing anything.
The robot is pretty responsive, so if you're sending and consuming points that fast I don't anticipate you seeing significant lag. Do be aware, however, that if you're using the Socket Messaging approach, the robot may not always be right where you command it to be by the time you send your next point. It can be easy to plan a motion and stream points from that path, expecting the robot to move along the path at the same rate you sample from it -- get position feedback from the robot so that you can handle cases where you get a little ahead of it. This isn't a huge issue, but it is something you should be looking out for.
This is not the way you want to go. This is going to be significantly slower and have higher latency than any other method.
You could, however, generate TPP scripts and FTP those to the robot, though I would budget a couple extra seconds for this transfer. It might be interesting to do a combination of TPP and KAREL position streaming: you could have a general TPP program that abstractly performs the task you want (eg. move towards object until the object is reached, attempt to grab object until successful, move object, attept to place object until successful), then communicates, via KAREL, with your external system to determine where to move, whether an operation was successfully completed, etc. I haven't tried that myself but it would be pretty cool if you got it working.
As some of the other posts have mentioned, KAREL training isn't really necessary as long as you have the KAREL manual (having the Programming Instructions manual (for TP programs) is also helpful). There are some weird KAREL quirks that you won't find in the manual, but I doubt you'd learn about them in a training; you just have to pinpoint the issue yourself and then be conscious of it going forward. For example, yesterday and today I was struggling with a stack overflow error, even though my call stack was only three routines deep. Turns out, it was an issue with KAREL trying to pass robot IO values by reference to my routine. I'm still not even sure what the robot thought it was doing, but forcing the IO to be passed by value fixed the issue. My point is, KAREL isn't that difficult of a langauge and can easily be learned without training, and any issues you run into would probably not even be in any training you take.
Still, if you own a robot, it's pretty easy to get TP programming training from the customer portal.
Is there more detail about the stream motion software?
Thank you.
Some like servo robot, meta, scansonic, of sensor and intelligent laser.
I found it in a manual on Motoman's website. It's part number 178939-1. MotoPlus New Language Environment, Programmer's.
Yes, I have find it in this manual who is for Motoplus YRC100, but there is just in a list, I can't find any detail for this API include in the manual and samples found in the Motolus YRC1000.
Maybe we are a step closer to the truth.
Thank you very much.
If I were you, I would like to use EthernetKRL. I think it can help you finish your application.
As for OPC and RSI, I think OPC is more suitable for communicating with PLC, MES or Cloud system. And the RSI is commonly used for real-time application, for example, you want to control the robot motion in real-time.
Hoping this helps.
M-registers are a 16-bit variable used in the concurrent i/o ladder. Depending on the generation of the controller there are M-registers that contain the current position of the robot in pulse or XYZ.MotoPlus, how about the mpGetJobStepData API.
I can't find the mpGetJobStepData in the reference manual, there is only mpGetJobData whose name like what you said.
The mpGetJobData can only get the job name and the system time. Where you can find the API you said?
Depending on generation you could use the GETPOS job instruction. You may also be able to use the M-registers that have the pulse count values or the tcp position.
If using the GETPOS instruction, I must modify the JOB program and insert so many GETPOS.
What's the M-registers. Where I can find it? Can I read the next point in this register?
The only way to do this is to make your program in position variables. This way you know where each position is in either pulse or X,Y,Z.
Yes, if using the position variables, I can calculate the current position in motoplus, but the number of the position variables is not enough for using, even if I extend to 1024.
Hi guys,
I want to get the taught point in advance of moving to this point.
For example, I have a program like shown bellow.
MoveL C00000 V=10
MoveL C00001 V=10
MoveL C00002 V=10
MoveL C00003 V=10
When the robot is moving to the C0000, I can get the position data of the C00000, also, when the robot is moving to the C00001, I can get the position data of the C00001. I want to implement this without modifying the INFORM, it can run in the background task or in the motoplus.
Is there any function in motoplus can achieve this? Or is there any system variable I can read out this data? Or any other method?
Thanks a lot in advance.
The 32-bit version can also run on your 64-bit system. You can try to run it in compatible mode. Windows 7 and 10 both support this mode.
You can refer to the ERROR Handler of Rapid in the RAPID Instructions, Functions and Data types. Then, when an error occur, you can send the error number to your PLC.
Look at this manual, you can find some examples here.
Sorry, I don't have this option(R535). I think it's not free.
If you have this option, you can contact your local FANUC for help.
Step1, Set your robot and your PLC in the same IP segment.
Step2, Select PLC as a client, then the robot as a server, it is also ok if you want to swap the two.
Step3, In the MENU-SETUP-Host Comm, you can find that you can configure a client or server in the list, select one, and fill in the IP address of your PLC. In you karel code like above, you can find the following line.
MSG_CONNECT('S3:',STATUS) S3 indicates Server 3.
MSG_CONNECT('C1:',STATUS) C1 indicates Client 1.
Step4, Input your code and build it in your RobotGuid, it will generate a *.pc for you, you can load this file in your TP.
Step5, Program your PLC in TIA for receiving and sending.
Maybe, there will be a lot of problems, but you have to figure it out by yourself.
I think you can read the manuals regarding karel and socket message first. And then, if you have problems, you can search in this forum.
Hope that helps.
Please check your robot whether there is a R648 option in your order file, you can make a AoA backup where you can find this file.
Yes, if you select the first way, you should create your own socket using karel, you can refer to the example above.
If you just want to transmit some simple signals, you can use physical IOs. It is easy for you to configure and implement.
You can look for a maintenance manual for controller where you can find the answer which you want.
Hi,
There are several communication methods for you, but you should check that what options you have bought.
1, Siemens PLC can communicate with your robot through TCP/IP, but your robot should have User Socket MSG option;
2, If your robot has a PROFINET I/O option, you can also communicate with Siemens PLC;
3, If your robot has Ethernet IP option and PLC has a Ethernet IP gateway module, it is possible to communicate through Ethernet IP.
Hope that helps.
You can try to use KUKA.Encryption Tool to encrypt your src and dat files to a techpack. After you installing this techpack, you can run your code using single step mode. By this way, the pointer will not step into your functions. But you also can not see your code, because of encrypting.
Do you have the document of Universal Sensor IF?
How did you test it?
If you want to save the variable in the CMOS, you should declare your variable using IN CMOS like the shown below.
bVar1 IN CMOS :BOOLEAN
eVar2 IN CMOS :INTEGER
sVar3 IN CMOS :STRING[99]
iVar4 IN CMOS :INTEGER
rVar5 IN CMOS :REAL
I hope that helps.
