I made just this in a YRC by cube interferences. You can also setup an output when the robot is in/outside of them. If you control the SVON signal from an outside device you can use this output to control it.
But I don't think it's necessary to turn the servos off since the controller already blocks the movement if you tresspass that area.
The last resource I have in the basket is changing the IMOV for a MOVL with a temporal fixed end point. Instead of calculating the offset from the current position, calculating it from the previous fixed point, which is certain. This way the macro can restart but the end point will be the same.
Nevertheless I'm going to try what you said, putting an IMOV in a job and stop the cursor on it, see if it does it twice as well. If it does, it's.. really surprising.
Also, I changed that parameter to 1 just hoping a bell rings, but no luck. So I can confirm the parameter doesn't work in this NX.
Thanks devils
NX100 NS4.16.01A-00 version 3.51. CPU 4.16
I'm looking at the manuals that came with it and I'm not finding that parameter. I thought about just using a regular job but jobs in this specific controller don't accept arguments either.
I have a macro that contains an IMOV but, if the operator happens to press the emergency button while the robot is doing this macro code, the job line holding this macro call is restarted. The robot ends up doing the IMOV twice, restarting the IMOV from the position the robot was when the emergency was pressed. This obviously leads to collisions.
I need the macro not to be restarted or, if it's not that, preventing the IMOV from executing the logic twice. It would also work if the robot could go backwards to the last fixed position, and restart from there. But I guess that's not out of the box.
I can use fixed positions in most of the program but I need IMOVs at least in two points. Naturally I want to keep the macro code but I will get rid of it if that's the issue.
I recall I saw in a manual a way to let the controller show the macro step, instead of just the line containing the macro call. Would this help? There's also some parameter that might be helpful but I'm not so sure.
S2C324, S2C325: OPERATION AFTER RESET FROM PATH DEVIATION
These parameters specify the method of restarting the manipulator that has deviated from the normal path such as an emergency stop or jog operation.
0: Move to the indicated step (initial setting).
1: After moving back to the deviated position, move to the indicated step.
2: Move back to the deviated position and stop.Thanks
No, they are all in the same coordinate system. As a matter of fact I made a new program with recorded points - no macros or realtime calculated positions - and it displays the same behavior.
I sent a video to support and they said it's singularities. Even though I don't see them myself - the joints aren't aligned at cero and the arm is not twisted nor twists in any way, and it goes up and down in manual just fine. But they said it's normal that it only shows in auto mode (I did not know this). Though I'm still scratching my head over why it only does it when reaching just slightly above or below the original point, as the trajectories are identical. Or when it goes up but not down, the path being the same.
I will upload the video in the next days
I'm going to contact local support next week, but I want to know if any of you has encountered this behavior.
It's a NX100. I made a macro to do offsets and it works except when one coordinate of the offset position variable is set within a random range. If the coordinate is in this range, the fifth axis starts to move - even though its offset coordinate is 0,000.
Macro code
GETARG LD000 IARG#(1)
GETARG LD001 IARG#(2)
GETARG LD002 IARG#(3)
GETARG LD003 IARG#(4)
GETARG LD004 IARG#(5)
GETARG LD005 IARG#(6)
GETARG LI000 IARG#(7)
CNVRT LPX000 PX000 BF
SETE LP000 (1) LD000
SETE LP000 (2) LD001
SETE LP000 (3) LD002
SETE LP000 (4) LD003
SETE LP000 (5) LD004
SETE LP000 (6) LD005
IMOV LP000 V=LI000Calling job code
OFFSET 0 0 -1700000 0 0 0 500If I set the Z around that mark the V axis starts to rotate halfway through the trajectory. I don't know how much it tries to move since the robot will collide if I continue, but it goes one degree up each second. The starting and ending position are safely inside the robot range though.
What's making me go crazy is that I can move the Z manually all the way down no problemo; the offset WORKS by testing INTERLOCK+FWD, the offset FAILS by INTERLOCK+TEST START, and the offset WORKS in both if the value is LESS or GREATER than -1700,000.
I thought maybe it had to do with the macro, so I put the code in the job - nothing. Maybe it's the variables, overflowing or something that's not giving an alarm, so I got rid of them and set a constant in the SETE command - nothing. I checked the local position variable being built - it's correct. What's going on here? How can it work in FWD and not TEST START? Is it a bug in the interpolator program?
X: 0.000
Y: 0.000
Z: -1700.000
U: 0.000
V: 0.000
W: 0.000
COORD: BASEIf you need to stop it during movement you could use the HOLD input.
If you do not, you could just duplicate that WAIT line in before every movement command. It is not very elegant but it works. I have a feeling this is not what you are looking for, though
It makes sense that it belongs to the concurrent job functionality, and it's so useful and sometimes essential that it should at least be mentioned in the manual, even if it's not included by default.
Case solved I guess
That's a great idea, but I can't find those commands in my controller. I have the INFORM EXPANDED option enabled. Are them available in the YRC1000? They don't even show up in the INFORM manual.
I managed to solve it. This is what I had:
WAIT IN#(SERVO INPOS)=ON
PULSE OT#(SERVO TURN) T=0.1
SET var var + 1
This is what I have done:
WAIT IN#(SERVO INPOS)=ON
PULSE OT#(SERVO TURN) T=0.1
WAIT IN#(SERVO INPOS)=OFF
SET var var + 1
This way I increment the variable with the actual servo movement, instead of supposing it is moving. I'd like to use the rising edge, and count when it stops moving instead, but as I said earlier there's no where in the program to check for that. But here I can be sure the falling edge will happen since I'm actually sending the signal to move.
The robot picks and places some plastic stuff inside the holes of a turntable, just like a revolver.
In the master job there's a WHILE that keeps checking different signals so the robot can make a different subtask based on them. The cycle time here is TIGHT, so the robot has to make whatever it needs whenever it gets a signal to do so. This is the cause.
One subtask manages the servomotor, sending a pulse. Whenever the servo finishes turning I need to increment a variable. Since I have to keep going with the rest of the cycle I can't wait for that. Instead, there's a WAIT IN#(SERVO INPOS) in every subtask. But they may not be executed. So, right now, I'm incrementing the variable with each pulse, leading to errors.
I need something that is constantly checking, like PLC ladder. But the controller's own ladder editor doesn't let me touch variables. Can I use this? This controller does not have the system/parallel job function.
I thought of maybe waiting for the servo input before sending the pulse, but - I confirmed this - the robot controller can cycle faster than the PLC turns the input off. So there's times when the robot sends a signal twice (and increments twice) before the disk hasn't even begin moving. I programmed a timer that stops the robot from executing that subtask if it goes too fast, but it's kind of a half assed solution and doesn't work flawlessly either.
I could also make it work if the controller let me turn off that input by myself before sending the pulse. Is this possible? This way I wouldn't need to synchronize the controller and the PLC.
Thanks
In the end I didn't have to do anything. The controller had mapped all these IOs already, both external and E/IP, with the POWERON signal. I got the first row of E/IP IOs starting at [33].
I ordered the controller with E/IP installed, so most likely those rungs in user ladder were loaded in the factory.
Is it possible to access an on/off value directly over ethernet/ip in the YRC1000 controller? The base data type is BYTE. I don't want to use arrays, can I map those 8-bits into individual inputs in the ladder editor or something? What is the proper way to do this?
Necroposting, but I want to post this for the record.
Thanks for the suggestions pyrioun; unfortunately they didn't work. Most, since there were some I was too afraid of trying 
They moved the robot cell and I had the time to test these. I still don't know where the problem was, but I recreated the original TP program line by line in a fresh new program, and the continuous path worked. I discovered this since a simple two point program did use interpolation so, clearly, the controller was capable of using it.
There must be some property sheet that was permanently changed and excluded that program from using that path processor.
I have had the same problems with unmanaged switches in the past - systems where multiple PLCs were connected where the Ethernet/IP and TCP connections would drop. I replaced the two switches with one Dlink for home and it all worked perfectly. That's the first thing I would try.
I would also consult the documentation for your PLC. Is it using a ETN21 card, or a built-in RJ45? What model of PLC do you have?
The suggestion of using Wireshark is great - you simply have to plug your computer to that network and let Wireshark monitor your ethernet adapter. You'll see the list of connections and you can examine each packet sent from an IP to another - there you can see if the PLC, for example, is sending the command to end the connection.
The R-2000iA/165F that was carried to my place was attached to a regular 1200x800mm wood pallet, but the head exceeded one side around 300mm. Weight of 1210kg.
AFAIK, looking at the specs, both models are alike.
I did test that before, with no result. CNT0 is the same as CNT100. I'm thinking Accupath or whatever it is isn't considering these PRs.
As I said earlier, changing PR to P works. Motion gets interpolated and changing the CNT curve changes the movement, so CNT with fixed points work as expected.
I will try setting that variable tomorrow, although it is not very safe to do that, right? Take into account I'm using registers as height offsets.
Robot is fully in production mode. RSR startup with UOP if it matters.
I wish I could upload the whole program, but it's currently lacking the PCMCIA card. 
To clarify, if I switch these PRs to Ps, continuous path works. Maybe it is just not possible in this controller?
What kind of controller do you really have? There was an RJ3 and a RJ3iB, but no RJ3iA.
Sorry, mistake. Rj3iB dated 2001.
Do you have the constant path option installed? Without that, the robot will take a different path based on speed. At 2 mm/sec, you may not see any difference if you don't have constant path.
Why are your speeds so low?
No. R[2] is a register in which I hold a global speed for certain movements. It is 2000mm/sec in this case.
What is the mechanical unit? (Is it a M-410 or an LR Mate?)
R-2000i 165F.
Try changing from R[2]mm/s to a constant value.
Thanks for this. No luck though. I removed R[2] for 2000mm/sec, and enclosed these in between LOCK and UNLOCK. It still goes for a FINE movement.
