What you saw was the actual code the controller will execute when you start the job. All IFTHEN, WHILE, etc. instructions are actually JUMP-LABEL under water.
Posts by jejbr84
-
-
I have also wondered why the robot sometimes stops between moves and at other places merges the moves fluently. I couldn't find a real pattern, so it is just trial and error for what lines you can insert between moves.
My observations are this:
- Comment lines slow down the robot and if you insert enough, make the robot stop (why?!? comment lines shouldn't be parsed...).
- A few simple GET, SET, etc. instructions are no problem.
- IFTHEN can also be used, but do not use ELSE.
- WAIT IN#1=ON always stops the robot, even if the input is already on.
- The stop behavior also depends on the path: distance and direction change between to points. Two points very close to each other make the robot stop sooner (less calculation time?) -
-
My reply is a bit late, but maybe it could still help you.
If you write 'advanced' instructions like IFTHEN, you see IFTHEN on the screen, but under water it is actually a JUMP to LABEL instruction. My experience is that when you just create a job and add instructions, it works correctly. However, when you start moving lines around by copy-paste, it could be that the under water JUMP-LABEL instructions become corrupt. You don't see this, because you only see IFTHEN.
You could try to save the job to USB and open it on a PC with a text editor (e.g. Notepad). Check if the contents are as expected and if correct, delete the job from the controller and load it from USB again. Then it should work again, because it will convert the IFTHEN to a working JUMP-LABEL structure.
-
Losing the ability to 'clone' controllers would be a bad thing for us. We use it to simplify the software installation on multiple identical machines. Just reload the correct ABSO.DAT afterwards and you are up and running. I hope a similar thing is still possible with the new controller...
-
And? Want to share some first thoughts? What are nice features that you see? What is the main difference from user perspective between DX200 and DX100? Some disadvantages? I know that I can also compare specs, but you only really get to know the machine when you start using it.
-
How about the ATAN instruction? The only issue is that it does not take the quadrants into account, so you have to correct the result for the quadrant the point is in. You could create a job for that with 2 arguments and a return variable.
Example:
LB000 = quadrant (calculated from sign of x and y)
LD000 = x
LD001 = yIFTHEN LD000=0
IFTHEN LD001>=0
SET LR001 90
ELSE
SET LR001 -90
ENDIF
ELSE
SET LR000 EXPRESS LD001 / LD000
ATAN LR001 LR000
ENDIF
'
'Correct angle for each quadrant
IFTHEN LB000=2
SET LR001 EXPRESS 180 + LR001
ELSEIF LB000=3
SET LR001 EXPRESS -180 + LR001
ENDIF -
My reply is a bit late, but I've seen the same behavior in the past. Did you update the controller software version by any chance? The solution was to initialize all data (jobs, parameters, etc.) in maintenance mode. After that I re-installed my program and the problem was gone.
-
You are right. DX100 and S4C287.
I didn't know about the other parameters, but the advantage of the input group is that you can easily change the speed. Even from the robot jobs when the program is running. Or from the IF-panel, or from an external PLC, etc.
-
You can do that quite easily:
- Set S2C701 from 0 to 1. This enables the speed override function.
- Set S2C287 to an input group number (e.g. setting it to 10 will use universal inputs 00100-00107).
- Set the speed you want in the input group you selected in binary format (or link it to a register in the CIO for easy change). -
roboprof: A corrupted card can always be restored by writing the controller software to the card, but let's assume I do not corrupt it. What does the CF card contain? It seems to me it contains all the data, but there is another memory unit in the device. Does this contain the same data and is the CF card a kind of mirror? The controller seems to compare the contents of the CF card with the internal memory and if it doesn't match you get an alarm.
motoexpert: OK, that could work, but it seems I need the Yaskawa code to load the CMOS.BIN. Or is there another way? Because using the Yaskawa code is not an option.
-
You can restart everything with the 'master job call' input (SIN#0049). Just couple it to an output in the CIO and set the output from your job if you want to reset.
Then clear the stack. What I use is this at the top of the master job:DI
CWAIT
SFTOF
CLEAR STACKThe answer to your question about concurrent jobs:
There can be only one robot job (per robot), because otherwise two jobs could move the robot at the same time which is obviously not desired. All the other jobs should be concurrent. For example a concurrent master job that calls/pstarts a robot job and another concurrent job. -
Hi, I am not sure if what I would like to do is possible, but here is what I had in mind:
I would like to move software from one robot to another in the easiest and fool proof way possible. Is it possible to remove the CompactFlash card from one controller, insert it in another controller and start it up? Of course the controller and robot are exactly the same type (DX100, ES165D). I know I would have to load the correct absolute data. This approach would only be 2 steps and is very easy to explain to someone who doesn't know much about Motoman robots.
Has anyone done something like this before? Or does anyone know a better way to accomplish what I want?
-
We have also encountered the same freeze bug Potis. Reported it to Motoman, but it does not look like they will fix it. Seems like a multi threading issue to me. We also solved it by using I/O.
And to setup a background job: create a new job and configure it as 'concurrent'.
-
I've got a list of CIO functions. It seems to be part of a larger manual, but I don't have that. The easiest way to program the CIO is to use the offline ladder editor that Motoman has.
-
I think the active tool number changes only if you do a move with a certain tool. You could do an IMOV of zero distance to change the tool number without moving. Create a Cartesian P-variable with all zeros and set the tool number with the CNVRT instruction. Or derive the P-variable from another P-variable with the correct tool.
-
For the MULMAT to work you need to have all P-variables in the same coordinate system. You cannot mix robot and tool coordinates, that wouldn't make sense. P-variables are not simple points in space, but points with a rotation (a kind of coordinate frame).
In your example you have got a "coordinate frame" P1 and P2 will be shifted in P1 (so if P1 has rotation it follows the rotated axes) by the values in P3. I am not sure about the order of translation and rotation though... Just try it, like Robodoc says.
-
You could make a custom user interface with the 'PP customization' option, but that would be overkill for just editing a variable.
Besides the I/F-Panel you can also use the DIALOG instruction. You can ask a question and set a variable.
-
We have seen the same alarm on one robot, with no apparent cause and at different positions in the program. I am sure the robot was not close to singularity. Controller version is also 3.00. There are 10 robots doing the same program and 1 of them has the problem. Motoman advised to change S1D262.
Doesn't anyone else have alarm 4400 with version 3.00? -
To go back to the original question: yes you can switch on an output. But the trick is that you first have to read it in a variable.
For example:
DIN B000 OT#(1)
IFTHEN B000>0
'Do something when output is on
ELSE
'Do something when output is off
END