R[x]=PR[i,j] in non-motion macro

  • What I'm trying to do:

    Read several PRs from the robot to my CompactLogix PLC on demand so that I can display them on an HMI (budget is $0, so can't use SNPX HMI unfortunately). The robot is running HandlingTool 7.70, so it doesn't support PRs via explicit messaging.

    My thought was to break each PR into 3 registers (only care about position, not rotation) and read those via explicit messaging into a REAL array in the PLC that the HMI can access. I'm using a DI over Ethernet/IP to trigger a macro that copies the PR positions into the registers.

    My problem is that if I give this macro a motion group *, I get an INTP-214 "Specified group not locked" error. If I give it a motion group of 1, I get INTP-105 "Run request failed" and PROG-040 "Already locked by other task" messages. I understand why this is happening, but am scratching my head trying to figure out how to get around it. It seems like there should be a much better solution than what I'm trying.

    Any suggestions?

  • TitusLepic

    Changed the title of the thread from “Reading from PR in non-motion program” to “R[x]=PR[i,j] in non-motion macro”.
  • Hi

    have you tried

    No motion PR operate mode --> true

    (inside config menu)

    That would be awesome and a great use of that feature, unfortunately that didn't come out until recently.

    If you want to run your program asynchronously, you could just use lock and unlock preg in the foreground and then jump over your code in the background if it's locked.

    Then there's always Karel...

  • Hi TitusLepic,

    another way might be to set a motion group allocated in your program again.

    And then setup your program to run as BG_LOGIC.

    This works! At least at R30iB(V8.20 5Groups,32Axis) and V9.40(only virtual tested;1Group,6Axis)

    Inside your BG_LOGIC you can handle the plc requests...


  • Yeah, it's not very known but you can read and modify PR data values if you do it on BGLogic... for some reason it doesn't lock the group, but you must take care and ensure you will not be trying to move to that PR while you are modifying it or before the complete data has been transfered!

    I've used this a lot on vision equipments to get part coordinates from the next piece while robot is doing other stuff, that way robot does not need to wait before going for another piece, also to transfer GI data to registers after converting it to reals and use that data directly from registers on the motion program.

    Hope they never "fix" this behaviour, it is very handy, if this behaviour was not intended I still haven't found a single problem doing PR edits that way, and as far as I know, there are not another way to do PR edits and reads in second plane without stopping the robot motion completelly and then locking, doing your stuff and unlocking the group again.

    Sometimes coding on fanuc feels bad, as I am using hacky ways to do things that on other brands I just do not need to, but hey... it works, it's like when some languages or apis make a function deprecated but doesn't give an alternative way to do what the function does.

Advertising from our partners