I have an R30iB controller that is currently set up CC-link IE field to a Mitsubishi iQR PLC. It is set up for 16 read and write registers to and from the robot. I’m wanting to get UTOOL values over to the PLC but every time put the value in one of my read data registers in the robot it gives me a PRIO-703 data invalid error. I’m converting the values to interfere before moving but it seems that the registers in the robot will only hold the max value of a single word. All the other data registers that are not PLC linked can hold anything from real numbers to large integers. The data registers they are writing to in the PLC side are double words so they should be able to hold the values. Is there a way to designate these PLC linked registers as something else other than a signed 16 bit word? Or is there a better way to get UTOOL values to the PLC? I can divide the interger by 10 on the robot side and move them in and then multiply by 10 on the PLC side but that seems like a lot of unnecessary math and could result in rounding errors as well.
PLC link data register designation
-
K_Glide -
September 27, 2023 at 3:45 PM -
Thread is Unresolved
-
-
Fanuc is a little tricky on what holds on the registers.
You can store both integers and reals, and there is a hidden boolean (that you cannot see on tp) that indicates if the value stored there is a float or an integer... you may be running into a problem as the register you are trying to write is flagged as an integer and it fails when you try to write a float with that method...
If you write a value on tp and you add a .0 to the end or you use a / operator writting into the register it will be flagged as float.
If you do the same but using DIV or type the value on tp without putting a decimal place it will be flagged as integer.
The big problem is that if you have stored an exact value that has a .0 decimal like 123.0 it will not show the .0 on TP, it will show 123, so you will never know the datatype stored except if using karel!
You could try to initialize the register data type manually by typing some random value with or without the decimal place on tp and try again.
Lastly, I don't know about the transfer method you are using, on my case when I wanted to transfer tool data betwheen robot and plc I just splitted the integer and decimal parts into two registers and sent it to the plc using two GO, and when receiving it I just have done the opposite.... it's a bit messy and I really hope fanuc adds "analog values" like other brands to transfer signed and real/float data.
-
This is exactly the route I was going to take. I just didn't like how messy it an get but looks like there is no other choice. Thank you for the reassurance!
-
No problem.
Remember that if you want to copy the tool data to a PR in order to read the XYZWPR you need to put $PR_CARTREP to ON, copy the data and then put again to OFF so you get the coordinates and angles instead of the matrix representation.
I also siggest you to add a $PR_CARTREP=OFF at the start of the program just in case you abort program in the middle of the operation.
The same if you want to restore values inside the PR and copy it to the UTOOL.... or you want to modify an UFRAME.
-
I currently have $PR_CARTREP set to on just for this reason. What is the downside in leaving it on?
-
I currently have $PR_CARTREP set to on just for this reason. What is the downside in leaving it on?
Well... you never know with fanuc.... as documentation for the major part of internal variables is non existent.
On my experience, the less system variables you modify, the better, so I got used to only touch the least system variables I can and only modify the ones I know for sure what they do..
And on this case I've read somewhere on this forum that leaving that variable to true all the time has caused unexpected problems on some firmware versions, so just in case to be sure, it only takes an additional step to put it on false again after reading the data you need, and also restoring it on the first lines of your main program is a matter of adding a new line to your program.
So take it as a good practice if you want. I've seen very strange things on fanuc because people just messed with system variables, and on some cases I needed to restore the original robot image to just fix the problem.
With this I'm not saying thet you should not modify unknown variables, modifying them is often the only way to discover new things, but take note of what you modify in case some problem arrises, so at least you will have a clue of what could be happening. Also, if you will modify system variables that you are not sure what they do a good practice is to do a image and backup with all axis at 0, you may never need it, but you will be happy of having it if there is some problem.
-
I see. Yea easy enough to turn it on only for as long as you need it. Thanks for the tip. This forum is actually where I found the variable in the first place. Good info here with people that are more than happy to share and help others.