Posts by DKirkman

I am not using ethernet but the controller has been starting up fine for the last few days with no alarms.

Thanks for the suggestions Robodoc

I uploaded the old CMOS.BIN file in maintenance mode and the controller now boots up in "normal" mode. However I am getting ALARM 0500 "segment proc not ready". If I reboot, sometimes it is fine and other times I still get Alarm 0500. The maintenance manual says that Alram 0500 is either from a setting error (I'm not sure how to check the "instruction execution cycle" as suggested) or from a YCP01 or YIF board failure. All the LED indicators in the controller are now showing "d".

Quote from Robodoc

You could have had a power spike that scrambled the memory. Do you have the CMOS.BIN file?

There was some new apparatus in action next door to my lab which sounded quite power hungry, so there could have been issues with the power supply.

Yes I have a CMOS.BIN file from late 2019 which should be recent enough. Should I try upload it after backing up the existing one?

It did however manage to boot in maintenance mode. I don't seem to be able to access alarm codes from maintenance mode though. Is there a way to do this?

Quote from 95devils

Of course this is assuming you can get the system booted up to even see the history.

Sadly I can't. I immediately rebooted without checking the error code, assuming I coould have a closer look if the error persisted. Now it won't boot.

Hi all

I have an issue with my DX100 controller and I'd love some help before I call the Yaskawa technicians and use up my research funds unnecessarily. Heres the story:

The (SDA-10D) robot was working fine until it came up with an alarm half way through a job. I didn't write down the code (rookie error) but it was a "Position Error", and the alarm was a major alarm as I couldn't reset without rebooting. I rebooted, but the pendant doesn't get any further than a white screen displaying "Starting up system" in blue and below that "Start Online Process" in black. The 7-segment LED indicator on the JANCD-YIF01 board shows "E", and all of the other indicators show "d" after booting. I'm not sure if there is a way to get the error/alarm code from these indicators?

I had a look over the possible major alarm codes which include "position error" and these are 1332, 1333, 1585 and 1679. All except for 1585 are for "EAXA" board failure.

Is there anything I may have overlooked, aside from writing down the actual alarm code, of course? From my observations it seems quite likely that the EAXA board is damaged.

Any other suggestions would be much appreciated.

Thanks guys. Apparently Yaskawa South Africa falls under Yaskawa Europe, so I am arranging a 3 month trial for MotoSim

If it feels too much like a Chevy Sundance I shall look into the other options

Greetings all

I am a Masters student working with a SDA-10D (DX100) robot, which I am using to execute tool-paths for an extrusion process. Due to the current situation, it doesn't look like I will be reunited with my robot any time soon, so I am looking for a simulation package with which I can check toolpaths offline.

I have a quote for MotoSim and it is way out of my funding. As far as I can see there is no student version for this either?

I have also looked at RoboDK, which seems a lot cheaper (student version). I am not sure what ROS can do in this regard, but it would preferably have to run on Windows for it to work at this stage.

If anyone could give advice on what software would be the best to pursue, that would be greatly appreciated. All I really need is to be able to check toolpaths which I have generated to make sure the robot can execute these without reaching any singular points. And it needs to be student-friendly when it comes to price : )

Many thanks

Daniel

Greetings

I am using my Motoman SDA-10D (DX100) robot for a 3D printing application. The TCP travels through a bunch of waypoints, and the universal outputs on the DX100 tell the Arduino-controlled extruder what to do.

My current setup is a print-bed mounted to the robot arm, and a stationary extruder. This is a bit odd but that's the way it is for now.

My toolpaths are 3 dimensional and quite complex, and the position of the nozzle relative to the bed changes constantly. To avoid a heap of ugly calculations, I am using the SETTOOL function to re-define the tool at each point along the toolpath. The "tool" is sequentially updated and told to move to the nozzle exit with a set pose using the MOVL command.

Here is an example of the code:

MOVL C00002 V=0.500

SETTOOL TL#(11) P0008

MOVL C00002 V=0.500

SETTOOL TL#(11) P0009

MOVL C00002 V=0.500

SETTOOL TL#(11) P0010

Where C00002 is the position of the nozzle exit. The P000X points are the toolpath essentially, and are used to update the tool definition. These points can be between 0.2 and 1.5 mm apart.

Now to the problem: at each point the robot arm hesitates. The delay is about 70 ms. In this time the extruder is merrily extruding because it doesn't know the bed has stopped, and the result is a messy surface finish. I am not sure how much of the delay is due to the tool adjustment and how much is due to the reading of the MOVL command.

What I want is for the robot arm to move like an ordinary 3D printer, where there is no stop at each line in the GCode. Any suggestions for how this delay could be minimised/removed? I may work towards a robot-mounted extruder which would do away with the SETTOOL issue, but then there may still be a delay due to the MOVL function?

Any suggestions would be appreciated

Hey guys

I am running jobs from DX100 with a lot of position variables. I can only squeeze 128 position variables into a job at a time, which is a bit limiting. I'm hoping to run jobs without having to use RS232 or Ethernet. Is it possible to use LOADJ to call a job from a USB plugged into the pendant? Then I could have a master job which uploads jobs with new position variables as needed? I don't have time to get the memory expanded so I can put more position variables in one job.

From my experience if I load a couple of jobs onto the controller at the same time, and using the same position variables, only the position variables of the last job uploaded are kept. So i guess I can't use CALL and just upload a few separate jobs before starting. I am still limited to 128 position variables at a time.

Thanks

Thank you, that makes perfect sense now. I am using MATLAB to generate position variables in a text file which would explain why the numbers are being truncated. I shall just have to stick to TCP speeds that are multiples of 0.1 to avoid rounding errors

I am using the arm for an extrusion process, so the speed is pretty important (and slow).

Looking at some speed tests I did, the controller does automatically round off the speed to one decimal place. Its a bit odd that it rounded 1.667 to 1.6 and 1.25 to 1.2 though. There's not enough readings to say for sure, but it looks like controller is rounding down.

I have a question of speed allocation based on this by 95 Devils: "On a VJ= there are two decimal places. On a V= there is one decimal place. The controller is using mm/sec on the V= regardless of what units you have the controller set for."

I am using slow linear moves between close points and speeds are say 0.4567 mm/s. If I tell the (DX100) controller that V = 0.4567, is it going to round it off to 0.5 mm/s? I have been wondering why my speeds are off but there are no errors when I specify V to 4 decimal places.

If so is there any way to specify speeds more accurately?

Thanks

Greetings

I have an SDA-10D robot (DX100 controller) and I am using it to follow 3D paths. I have no offline simulator, and I am writing jobs offline and uploading using USB. So I program the toolpath, upload it, and hope the arm will do the moves without having any singularities.

When I specify coordinate points, the options are x, y, z, Rx, Ry, Rz and Re. Before I execute the toolpath, I wont know how the arm will move so I am just leaving Re as zero. But this is essentially locking the E axis and making the arm 6-axis. Which makes it more likely that there will be a singularity.

So the question is: Is there a way for the E axis to be "freed up" without me having to give it any extra info except tool tip coordinates? I understand that adding the 7th axis means that there are a whole lot more elbow positions possible and that the controller needs to be told which one is desired. Is there no automatic function to change elbow position if the arm is approaching singularity?

Thanks

Daniel

Solved this at last. I found a manual for the "External IO Signal Allocation Function". I went into maintenance mode and there were no Input or output signals assigned. Apparently this is done in the factory so I'm not sure how it got undone, but at least it works now

To clarify, am I wrong in assuming then that PX001 is the same point as P001 if I haven't registered any external axes etc?

GETPOS PX002 STEP#(1)

CNVRT PX003 PX002 RF

MOVL P003 V=1

Will that execute the move with the data in PX003?

So when I use GETPOS and CNVRT I need to specify the position data variable in the form PX000. If I try use P000 there is a syntax error when I upload the job. But if I try specify a move as MOVL PX000 then there is a syntax error, and it only works if I specify in the form MOVL P000.

This works:

GETPOS PX002 STEP#(1)

CNVRT PX003 PX002 RF

And this works:

MOVL P001 V=1

How can I use the point that I have fetched (PX . . .) and converted into XYZ form with a move command?

Greetings

I would like to be able to fetch the position and posture of the tool at the start of a job, to be used later in the job. Because I will be using SETTOOL to change the tool definition several times during the job, I need the position to be defined in cartesian coordinates. Pulse position coordinates won't help because changing the tool definition will change the position of the starting point.

Is there a way to use GETPOS to store a point in robot coordinates instead of in pulse count position? I am using a DX100 controller.

Thanks

I have the YIU02-E board. Not sure if that is NPN or PNP but either way I'm still not picking up any outputs.

I tried connecting my meter + to CN309 B18 and - to B10. No output. I have also tried using OUT17 (A8 and B8 on CN307) to see if there is contact between A8 and B8 when setting OUT#(17) ON. No contact when I try that either.

In the CIO there is GSTR #10010 which I'm guessing means that outputs 1 to 8 are set to physical output?

Attached an alarm message I got when accidentally shorting B18 on CN 309 onto another pin a few days ago. I have checked all the fuses on the controller and they are fine. No error messages on startup. Could I have fried the IO board maybe?

Thanks for the help

This may be a dumb question from a noob . . .

I am busy trying to get the universal outputs on the DX100 working. All I need is one output to connect to a relay.

I am using the DOUT Inform function and can turn on and off the universal outputs according to the I/O panel on the pendant. Picture attached. The code I used was as follows:

SET B000 255
DOUT OG#(1) B000

This should set outputs 1 to 8 to high if I am not mistaken. User outputs 1 to 8 are pins A10-A13, B10-B13 on the CN309 connector on the I/O box. But none of the CN309 pins show any change when I run a job with the above code. In fact I checked all the pins on CN306, 307, 308, and 309 just to be sure. I am using a multimeter with ground attached to the ground busbar on the controller. The 24V on pins A18, B18 of CN309 picks up just fine.

Am I missing a step in the assignment of universal outputs to output pins on the I/O box?
Any suggestions would be appreciated