Posts by 95devils

Sent you a PM earlier this morning.

But the OP only mentions NX100.

Quote from Reintz

it's also possible to use $PX004 in GETS instruction

$PX004 is in pulse. He is using $PX001 which is XYZ Base Frame. A programmer may not know that they would have to use the CNVRT instruction. $PX007 is XYZ Base Frame minus the shift amount.

Move the robot to the vicinity of the pipe pick up position.

Move the cursor to the address side of the line that has REFP 1 instruction. On the pendant is the 0 key that is also marked REFP.

Press the REFP key. The Edit Buffer Line should say REFP 1. With servos on, press and hold the REFP key and the FWD key. This should move the robot to the currently taught position in the Reference Point.

Jog the robot to where you want. I'm guessing this would be the first pipe pick position based on the program.

With servos on, press the REFP key so REFP1 shows on the Edit Buffer Line. Press the MODIFY key. Then the ENTER key.

If the results of the code are repeatable and with desired results, then it is fine. Does the robot achieve that speed? I have programmed quite a few older cells where I had the speed maxed out. The robot never even got close to that speed due to the distance between positions and the accel / decel factors.

Using servo command positions vs. position variables is preference and depends on the application. They each have their advantages and disadvantages.

What i cant figure out is where he adds approx 270 to the X value each cycle.

GETS PX020 $PX011 // Get the position in pulse of Reference Point 1.

CNVRT PX020 PX020 UF#(1) // Convert the Reference Point 1 position to XYZ based of User Frame 1

GETE D020 P020 (1) // Get the X element of P020 and place into D020.

SET D020 EXPRESS D020 + B004 * 273000 // Overwrite D020 with where D020 originally was + (part number on * 273 mm). This is what you you would adjust for spacing.

SETE P020 (1) D020 // Set that number back into P020

The point you want to adjust in the position in REFP1.

Word possibly of warning. Some people (me) may hard code the reference point in a startup on init job. Changing the reference point itself may cure your problem until the startup or init job is run again.

If you press the SELECT key on the alarm, in the details, it should show [200x]. Farther down the screen it would say X is the axis. 1=S, 2=L, and so forth.

Exactly.

T-axis.

That is one issue. The job appears to be corrupt. I spent about an hour trying to manipulate it by loading only moves and only portions of moves. The controller doesn't like it. I can get maybe 10 or 20 moves to load.

What robot arm is this, a MA1900 or MA3010?

I would not trust a USB communicating all the time from the programming pendant to the controller, even if DCI were possible using USB. I've lost communication many times just from things vibrating in the plant.

You are correct on loading jobs. The last job loaded would overwrite the current position variable's values with the values declared in the job's header.

You may have the ability to expand the position variables yourself, depending on hardware. In maintenance mode, in management security level, under SYSTEM, SETUP, OPTION FUNCTION, is VARIABLE ALLOCATION. Depending on software version you can give yourself 1280, 1560, 1611, etc. position variables. It shows on the screen the maximum number. The depending part is what position variables you need to increase (Robot) may decrease another type (Base or Station) that you may also need.

Changing the number of variables requires you to initialize the jobs, var.dat, varname.dat, and uframe.cnd. You'd want to have this backed up as individual files so you can reload after changing the number of variables.

Using your numbers of 0.4567, if entered into the programming pendant the controller will round to 0.5. If the number is type into a text editor then loaded into the controller the controller will show 0.4. Saving the job back out will show the controller eliminates digits to show 1 decimal.

Quote from Reintz

You're sure you can use local position variables there? Only asking because I can't (on a DX200).

Maybe this will get you there:

You can use LP's on DX200 as long as the Language Level is set to Expanded and the LP's are reserved in the header of the job.

Change your CNVRT from TF to either BF or RF if the surface is square to the robot. Use UF and create a user frame if it is not square to the robot.

Logic looks fine other than the TF tag. LP001 would be taught position +X 20 mm and +Z 80mm. LP002 would be taught position + X 20mm and +Z 330 mm.

Confidence but humble. I've seen a few cocky programmers, and they don't last. The best programmers I know think they aren't very intelligent at all. They are in fact geniuses or borderline.

Quote from WhyDoesMyRobotHateMe

I've found this at times somewhat inaccurate or hard to locate, in some cases it absolutely nails it and in others it lands on what generally turns out to be an innocent line of code close to the problem, and in others like my current situation, it's baffling - the line its suggesting doesn't exist (it's a few dozen past the END statement.)

So my question is - how does the program counter work? What does it count, what does it ignore, does it go into calls of subroutines/jobs and count those too? I'm relatively certain it starts at the NOP command, yes? I would assume at 0 or 1 and go from there. But this job is throwing an error at L:0641, my NOP statement is at 691... So via some absurdly complicated math I did, I deduced that the error should be at 1332... correct?

My END statement, though - it is at 1271.

The NOP is Line 0000. It may be some other number when you are looking at it in some other text editor, like you are. But to the controller the NOP at the top of a job is Line 0000.

The error 3190[4] says It's an Error in Job Data Record - 'Record on the position data section is wrong for the format.' My experience with this error tends to be the number of positions in the header NPOS does not match the number of moves written in the job. When this error occurs the error will say L:******. The controller can't tell the line number because the problem is not between the NOP and END instructions, there is not a line number.

What generation of controller? DX200 or YRC1000 the SETTM instruction would do that. Older than DX200 would be done in the Concurrent I/O ladder program.

The I/F Panel manual has the format in section 5. Relative Job manual has a good section at the back for job structure.

The board then is the YFC. These signals are monitored in the background. Don't have a book in front of me. I believe they are terminals 1, 2, 3, and 4. Should be a sticker around the YFC (right side wall of the controller) that has the terminal numbers. From the factory they are jumpered.

On the MTX or YFC, depending on generation, there are 4 terminals, dual channel, for the safety gates. This input has an 8000 series address that can be looked at or logic written in the ladder program. It could also be written in the machine safety logic circuit, depending on generation.

The terminals could be found in the prints for the controller.