Posts by 16000lc

Sorry, completely forgot.
Send me a DM in January and i'll get that for you

Hello!

i could give it to you but i dont know if it will work, because there are some files that are hidden and a copy does not transfer them.

During this week I'll leave here a link with a copy of one of our robots.

Quote from Galet

Hello,

If you have a other SP1, you can try to change it.

Control the connection and the cable between the SP1 and the controler.

What's happen when you stop all the applications ?

Have a good day...

We do have another teach pendant but it’s not in a better state that the current one 🤔

Quote from ElEsgalho

It happens something similar to me once.

Ensure all tasks continually running do have an instruction to cause an immediate sequence, this is, frees the CPU resources to jump to other tasks avoiding a deadlock.

Example of a deadlock task:

Code

do
   ...Something...
until false

Example of a task that sequenced immediately:

Code

do
   ...Something...
   delay(0)
until false

The delay(0) will free the CPU from the task running too many times, allowing resources to run other tasks, like the pendant update internal task.

Inside VAL3 manual:

The VAL 3 instructions that can cause a task to be sequenced immediately are as follows:

• watch() (condition wait timeout)
• delay() (timeout)
• wait() (condition waiting time)
• waitEndMove() (arm stop waiting time)
• open() and close() (arm stop waiting time followed by timeout)
• taskResume() (waits until the task is ready for restart)
• taskKill() (waits for the task to be actually killed)
• disablePower() (waits for power to be actually cut off)
• The instructions accessing the contents of the disk (libLoad, libSave, libDelete, libList, setProfile)
• The sio reading/writing instructions (operator =, sioGet(), sioSet())
• setMutex() (waits for the Boolean mutex to be false)

Hope this is your problem, otherwise good luck!

Display More

That’s a good idea.

I will see what tasks are running continuously and see if I can add that condition to avoid possible problems

There are tasks that are continuously running while waiting for information from the PLC to start the operation.

Maybe If I add an delay(0) to each one of them it can help?

Best regards

Hello everyone!

Has anyone faced a problem where while using the teach pendant it completely freezes?

We can power it( we see the green light turning on when pressing deadman) but other than that the screen doesn’t move.

It happened twice already and we were obligated to turn off the power of the controller( which can cause more harm than good when doing it constantly)

Can it be a memory problem? Too many programs?

Is there a solution other than turning off the controller power? We really need to avoid this problem .

Rx130 CS8

Best regards

Quote from ElEsgalho

It's possible to create your own calibration references on your cell, so you could check the robot's calibration against those. Our cells had that in the past but now we have a global frame to check the robot after calibration and to do small adjustments if needed.

This could be quite good especially if you replace it with a different robot size, just teach the same frame and you should be good to go.

Again, trusting only the robot calibration could not be enough to recover, especially if you move the robot's position within the cell, either for maintenance or replacement.

Got it!

We also have calibration references in the cell but we never needed to use it.

Our only priority right now is ensuring the correct position of the points in case something happens. There's no future plans of changing the robot mechanically

Best regards

Quote from Galet

Hi,

In the folder "Usrapp", you find only the applications. The file where the controller memorize the calibration datas is in the folder "Configs". It's the reason why, in the backup, the controller save 3 folders (Sys = System (Configuration)), UsrApp(applications), and Log (Logger).

The IO confgurations are also in Configs.

What type of controller do you have ?

Best regards

Display More

The usrapp is inside the USR folder.

There's 2 "configs" folders. One in USR, other in SYS, with similiar files, despite different values for configurations. Which one is the correct one?

Our controller is a CS8.

Quote from ElEsgalho

Also, I would strongly recommend in the future to create some calibration reference positions, so you can easily calibrate the robot. As it was said here, having the positional information from the application is not enough to recover, you need as well to make sure the robot is running with the same calibration as before.

What do you mean?

The robot has it's marks used for calibration, which is what we normally use when we want to calibrate it

Best regards

Hi Galet.

Does the config folder include arm and drives configurations?

I figured it might not be enough to save only usrapp as the arm configuration should also influence everything.

Another question. Is there anyway to edit a point through his coordinates on the pendant?

Eg: Point A ( 10,10,10,20,20,20) change to (15,10,10,20,20,20). Is there a simpler way to edit it other than manually moving the robot to the point?

I know through SRS I can do it, I just dont know if its possible on the pendant.

Best regards

Hello everyone.

What files should I save besides the usrapp folder to be completely safe in case something happens?

This week our robot crashed and somehow all the points got deviated like 30mm on the Z axis.

Not even transferring the usrapp backup folder I had solved the issue, as the points continued in the wrong place.

What did I miss?

Best regards and thanks in advance

Hello everyone!

We managed to boot up the controller.

It was this board that was damaged(it's attached to the main one of the drives behind the batteries)

We figured it out through trial and error.

Best regards

Quote from chereandy

... looks like problem with flash/hdd - corrupt OS - try to boot from back-up usb/floppy ...

Hello.

We tried various memory cards and none of them worked. And we tried all of them in another controller and it booted up without any problem. So we are thinking the problem comes from the board or the USB connection between the computer and the back board

Best regards

Board

Controller

Hello my friends.

I'm having some problems with RX130 CS8.

It's stuck on this step

Best regards

Quote from Galet

Probably from the PLC...or direct from the machine.

You are absolutely correct.

I managed to get access to the PLC program and found all I was looking for. The cycle is controlled by the plc with set resets.

The plc decides which routine the robot has to execute. And it receives feedback from the machines. So the method I was thinking to use( ignoring the machines using the robot routines) will not work because the PLC will be stuck waiting for feedback from the machines.

I

Quote from Galet

Some question to help you :

Do you have the SRS (Stäubli Robotic Suite) ?

Witch version is installed on your CS8 (Menu / Control Panel / Version / System on SP1) ?

Witch type of IO use you controller (Menu / Control Panel / IO) ?

I don’t have SRS

The other info I can only give you Monday when I’m back to work.

Best regards

Quote from Galet

Hello,

Plc send order on Digital inputs :

- io:E_Dech_Ader

- io:E_Dec_Der ...

The principal program call different subprogram for each task.

All the subprogram are build on Grafcet structure (typical Switch Case...)

The active Step is contain in output group like io:G7_Chg_Cint__A.

In each step, the Jump to another step is programmed with DioGet(StepVariable,NextStep)

It's very special (to use Output group to memorize the active Step) but I think it's to inform, in real time, the plc

Display More

How does the principal program call the other programs on its own?

For example, the principal program only calls G7_Chg_Cint if io:E_Chg_Cint==true or DioGet(io:G7_Chg_Cint) != 1

Since the program hasn’t been called yet, io:G7_Chg_Cint=1 (right?) so it has to use the other condition. Where does the io:E_Chg_Cint come from? I thought it came from the plc because I can’t find it anywhere on the robot

The program that makes me think the cycle is decided by the PLC

Main application is B5clim, all the other files are the subroutines

Hello everybody.

What brings me here today is a question that I am sure you guys will be able to help me with.

We are working with a Staubli RX130 CS8 that performs a cycle as it follows: unloads a part from one machine, loads the part into another machine, takes it out and puts it in the washing machine.

Each of these loops is a different subroutine, with a switch case format.

I want to try to understand how the robot goes from one program to another, since within these programs there is no call instruction that interconnects them.

The most certain is to be by the PLC.

I ask this question because I want to accomplish a simple task.

The robot only has to pick up the part and drop it in the washing machine, ignoring the two machines inbetween.

I thought of doing the following: Introduce an input with a switch, and in the program of the first machine, do an

" switch Routine(Machine_1)

case 1

if io:ignoremachine==true

movej(washingmachine)

open(pince1)

break

endswitch

else

(continue switch as normally does)

endif

This causes the robot to ignore the first machine. If I introduce this condition in all subroutines, will the PLC and the Robot be able to continue the process without major conflicts and ignore all the machines?

Solved.

We cloned the working compact disk, and copied the programs we had on the broken one( on usr/usrapp). What was corrupted was maybe a boot file or something.

All errors disappeared and the robot is working fine

Best regards

Hello guys!

I'm working with a RX130 CS7 and we had a problem with a faulty cable connecting to the teach pendant.

Somehow, during the time the maintenance tried to fix that problem, it actually got worse. The controller never got on, stuck in " Initialization in progress".

After various attempts, we managed to start the controller.

What fixed it was changing the compact disk(what contains all the programs, and etc) on the board inside the controller, with a spare one from a different robot we had at the factory.

Our problem now is that when trying to move the robot, it immediately loses power and gives us the envelope errors on the motors.

My questions are:

Does using a different compact disk bring problems beside losing our original programs(which is fixable)? Are there robot parameters on the disk who could cause this(since it's a different robot we took the disk from)

We tried formatting the original Disk(broken one) and pasting all the files that were in the one that worked, but it must have deleted some hidden file with the OS and the controller doesn't start, so we're back to the disk that works but we have the envelope errors,

Thanks for the help!

Best regards