Posts by Robottech

I saw those in the manual, just wasn't sure if they were tied to the Arcon/Arcof instructions.

Hi, I have a DX100 cell and I need to find out what the address of the Arcof instruction is in the CIO so I can map it to a PLC input. Looking through the CIO manual it's not really clear what the address is. Does anyone know what this would be?

Just for further info: I have some other NX100 cells that I have implemented a successful weld length measurement program. I am using the "current flow" bit from the welder to start a timer, and ending it with "ctrl grp run" turning off, so basically timing from the time an arc is established to the time the robot stops moving then doing some calculations to get length. This works well on the NX100 platform, however on the DX100, the "ctrl grp run" bits seem to flicker and turn off mid weld even when the weld is a single linear move, which is screwing up my calculations. Seems for the DX100, these bits are programmed slightly differently in the robot, but I am not privy to the inner workings of these bits so have to find an alternative. I want to use the "Arcof" signal as this should be pretty consistent and always occurs right at the end of the weld.

Thanks,

Hi Guys,

Does anyone know how to change the screen timeout on a DX100 teach pendant? I would like to disable it completely so the screen never goes black. I need to record the screen with a gopro over a long duration.

Looked at the programs and I think I would have to upload more jobs here than is worth it. I will wait until this event happens again and check the log data to see if it actually ran a program to cause the motion. Will update with what I find.

Just curious what your industry is? In my experience, every time I've received programs which were written off-line, usually designed with motosim, they always required at least one touch up pass ie: they aren't perfect.

Also after zeroing out any axis, I usually end up touching up every critical position. I'm not sure if there's a way to avoid this after you re-master a robot. I think there is some kind of sensor based system that records before and after TCP positions and offsets things accordingly, but how well these work in reality I don't know. Is it a big deal just to touch the programs up? Not sure about your facility/industry and how things operate there. I'm sure someone here will have some better answers for you.

Quote from 95devils

That's great that you have the logging function with board. That tells you darn near everything. Most people I see don't have that.

Does the operator side visually move in what looks like normal motion when this alarm occurs? Or is it "where the heck are you going?" The operator side axis moves about 5 or 10 degrees quickly before the safeties detect that it moved in the operator space when it shouldn't have and creates a fault.

Is there a PWAIT SUB after the PSTART in the master task? Yes there is a pwait sub for the pstart

When this occurs are there multiple jobs running at the same time, assuming so since you said they were PSTARTed? The PAGE key will display all running tasks. No, when it is started, the robot was in Master job, and the "starting" is really just the plc external starting the robot after the robot was stopped (from the rear gate being opened in this case). The sweep job should not have started because there were no parts loaded, so the "starting" of the robot should have just started master job running again without jumping to any other jobs.

Can you post the master, sweep jobs, and any other jobs in between these two whether CALLed or PSTARTed? I will post in a bit, just have to take a backup

Just me talking here that may ring your bell. Three robots sitting at a neutral position. Probably a VMH positioner. Sweep job A or B running, cursor on a hard WAIT instruction for the operator to say ok to sweep. Operator opens rear door, does whatever, and closes rear door. Restart system and positioner operator side tries to move. I thought the same but when I actually saw it happen, there was no sweep job running at the time, just sitting in master waiting. Rear door was opened to address a gas issue with the robot, thus stopping the robot. After exiting and restarting the robot, the movement happened at the front, only on that axis. Had a sweep job began, all 3 axes should have moved. It seems like it's running just an S1 job, which there are in the controller, but for it to run that by itself from master, I can't see how that could have happened.

Do the robots try to move also? Not that I noticed, but I will check the next time it happens.

Where is the cursor in the master task when the alarm occurs? Door acts as a e-stop. What are the values of S2C422, S2C423, S2C424, S2C653, and S2C654? Can't recall exactly which line it was at, but only master was running at the time I looked (after it happened), no subs running at that point. But something could have executed before I had a chance to go around the back of the cell.

422:1

423:0
424:0

653:1

654:50

Display More

There is no OP station to allow for jogging. I did however figure out that we do in fact have the logging function and I assume either a JANCDYIF01-2E or JANCD-YIF01-3E card installed as stated in the logging manual.

I figured out that the log will show any jobs called that included motion commands, classified as a "start" event and if you push select it will open up and show which job was run.

Now I have to wait for this problem to happen again (I can't figure out how to create it) and see if there was a job called that shouldn't have been. I looked to see if SIN 65-72, 129-136 were used in the CIO, but they are not, so it is pointing more to a job being called that shouldn't be.

I added answers to your questions below in blue.

Quote from 95devils

Weird. See answers in blue. Do you have an OP Station with joysticks to jog the operator side fixture? No

Sweep jobs being PSTARTed instead of CALLed? Yes the sweep job is a single job which is PSTARTed, I'm not sure why they used a Pstart since it is in a single job. It does work however. What is the danger in using a Pstart for a sweep job?

What about putting an DOUT ON and DOUT OFF at the top and bottom of each job. Individual signal for each. When the alarm occurs you could see what outputs are on to track the job flow. Could be painful depending on how many jobs there are. How often does this occur? Sounds fairly repeatable. Possible to do, but I think the logging function should do the same thing?

Quote from Falgun Vasava

Thanks a lot 95devils

i am not using any Anybus product.

I have directly installed a Siemens Profibus Card CP5612 on the PCI slot of DX100 Controller.

I have no idea how to proceed further. Is it possible to do communication between S7-300 PLC and yaskawa DX100 robot controller using CP5611 profibus card?

If yes than i need some help.

Display More

I believe 95Devils is correct, these products are made by Anybus.

In the hardware config of your S7-300, you should see an anybus node, clicking on this you should see the HMS GSD file listed there somewhere. In here you need to configure the I/O range for the card. Then in Maintenance mode on the DX100, you need to configure the same IO size and configure the profibus address. Make sure you hit enter after this and confirm the settings, then it will go to the IO mapping screen (forget what this is called off the top of my head) where you must press enter again to bring up the confirmation window. This will enable the card in the DX100. After this, you can troubleshoot using the lights on the card and referring to the manual.

Hi,

I'm having a tough issue with a weld cell. It's a DX100 controller, H frame positioner and 3 robots at the back.

The problem is that very occasionally, if the rear gate is opened for any reason, upon closing it, and starting the robot again at the front of the cell, the operator side tooling axis will try to move. It will rotate about 5 or 10 degrees before the cell faults out. When it faults, I get multiple faults from the PLC and robot, which is correct, that axis should not be moving when it's at the front.

After an occurrence, I will look at the pendant and it is still in Master job. I was expecting to see it had jumped to some job, but it is still in Master. I am wondering if it left master, ran some job it wasn't supposed to and went back into Master by the time I get around to the back of the cell to look. I can verify that when this occurred, the pendant was in Master job before the incident, and had not been accidentally left in a different job.

Looking at the program structure, I cannot yet see a way that from Master job, the robot could have gotten to a job that would have just rotated the operator side tooling axis. It may be possible, but I just can't see it yet.

I guess my questions are as follows:

1) Is there an SOUT that I can track in the PLC that will tell me if the robot leaves Master job? I know there are SOUTS for "Top of master", but I want to know if it leaves master job altogether and runs anything else.

2) Is there any kind of logging of which programs ran in a DX100 controller? I looked around the pendant and in the logging function, but it just seems to log faults

3) Is there any way, other than a MOV command in a job, that an axis can be moved? Something in the CIO maybe? I don't think so, but maybe there is a way?

I have looked at everything else I could think of, there are macro jobs but they don't have any external axis as a control group, there is a system task, but from what I saw, it doesn't contain any move instructions (it did create a fault when the front axis moved, as it looks like it has been programmed to do so), the interrupt job list is empty. My assumption is that the controller somehow jumped into an unintended job and got back to master by the time I looked. How I'm not sure yet.

Quote from Robodoc

Do the math in the robot. Moving positional data to a PLC is a bitch.

Next time I'll check out this option, thanks

Quote from Robodoc

Capture the position before and after the weld, do the math to figure out how long the weld was.

That would work using d = ((x₂ - x₁)² + (y₂ - y₁)² + (z₂ - z₁)²)^1/2 if all of the welds were straight lines, but some are circular and the math would become quite cumbersome to do in a PLC (and would also require data about the radius of the circle to be sent and whether it was a circular/linear weld to the PLC, unless I am missing something). The timer based solution using arc established and ending when the above SOUTs go off worked quite nicely for my application and only required speed and the other signals I mentioned to work.

That was exactly what I was looking for. Wasn't aware of those SOUTs before, or if I saw them, the description didn't really explain what they were. Worked perfectly today for what I needed. Thanks!

Hi,

I am wondering if there is an internal bit somewhere that is active when a robot is at a standstill, IE: servos on, program running, at a position, but not moving. Maybe something in the specific output area that I can map to the PLC?

Reason being, I am trying to measure some weld lengths. I already have arc established mapped to the PLC, as well I am moving the weld speed into an output group and reading that in the PLC (this is just moving a constant into an output group, so not reading speed directly as I don't think there's a way to do this, but it works mostly).

Problem is during a crater fill at the end of the weld, depending on the fill time, the robot could be sitting there not moving, just crater filling for 0.2-1.0 seconds. Obviously the arc is still established, so in the PLC, I am still counting this as movement when it shouldn't be. IE I am using the speed that I sent and the arc established to calculate distance. Problem is during crater fill it is not really moving so my calculations will be off (I know that the crater fill will make the weld a bit longer as material is being deposited, but it's not adding to the length as much as if the robot was still moving)

So I am looking for some kind of built in signal from the robot to say it is currently moving, or not moving. Is there anything for this built in that I can map to the PLC? If I had this, I could change the speed variable in the PLC to be a lower value during crater fill and thus have more accurate calculations for length.

I don't have the option to select the coasting screen under the robot menu. I am in management mode. The fsu manual states that this screen will not be shown if there are no external axes. I don't have any external axes, so it makes sense that I don't see this screen, but then how do I get rid of the message popup? And why is it popping up if it only seems to apply to external axes when I don't have one?

I am working on a dx100 controller with two ma1400 robots and whenever I try to either externally start the robot, or start from the pendant, I get a message saying "Immediate stop is valid. Operate?".

I have to acknowledge this message at the pendant before the robot will start which is no good. Does anyone know what causes this message? I can't find anything in any manuals.

Thanks for the replies. I actually managed to figure this out on my own this morning lol

Instead of mirroring in robot coordinates, I mirrored in pulses.

I had to change the value in parameter S1CxG065 to invert just the S, R, and T axes and it worked perfectly.

I'm trying to mirror a bunch of robot jobs from left to right on the robot (around the XZ plane in base coordinates) And I have used this before but I'm having an issue currently.

As soon as I mirror the job, the new mirrored job has "OV" written beside the positions. The OV is because the mirror function isn't calculating the S axis positions correctly (this is an HP20 6 axis robot)

The first few positions should rotate the S axis almost a full 180 degrees (about 160 or 170 actually). So the S axis starts at 0, then the first position goes to about 220,000 pulse counts (going from memory here) in the original job. Now I would expect the Mirror function to put in a value of -220,000 for this particular axis in the mirrored job, however what it's doing is putting in a positive value of 270,000.

I think instead of changing direction from CCW to CW, the robot is trying to get all the way around by going CCW past the 180 degree point.

Is there a way to force the mirror function to go the other way for this particular axis? Set up a soft limit, or some other parameter? Or have I just encountered one of the limitations of the mirror function?

I don't think either of the other mirror options would work for me (pulse, user coordinates) so I'd really like to get this to work.

Thanks!

When running a program, does the controller always calculate the exact same path when moving to a point? I always assumed it did but I've heard guys say over the years that the robot will "try to learn the fastest path" to a point by trying slightly different paths every time it runs through the program. I'm curious about this because from my experience I can't see a difference when watching a robot run a program over and over. Unless it is changing path calculations very slightly every time. I would also assume this could be kind of dangerous if you've programmed the robot to move very close to a fixed object inside the cell.