Hello,
I already had a similar problem. It was due to computer drawer loss of 24V on J213.
The controller was powered with an external 24V, and it happened that this external 24V dropped during robot operation. That was causing the "DSI9 board not referenced error" at reboot.
Maybe if you are in the same configuration it is worth to investigate.
But I don't know if we are in the same situation because, in our case, we could clearly see the teach turn off during the loss of 24V and then reboot
Hello,
I use the system variable $MOR_GRP[1].$ROB_MOVE to check if the robot is moving in KAREL
Hello,
I have 2 tools that are offset by 180° on J6 and my positions are difined with Points.
In normal cases, robot chose the easiest path to go in position, but this easiest path is not always the good one for cables.
Is there is a way to choose/force a direction of rotation on joints on movements ?
In relation to this, I'm not exactly in that situation but :
If one tool pick a part with J6 = 0, and the second drop an other part in the same place with only a move on J6. How the Robot choose if it does +180° or -180° to go to a point ?
I already identified 2 solutions :
-use a joint type to fix joints positions
-use a intermediate movement on J6 to get closer to the desired position
I would like to know if i'm right about my statements, and if there is an other solution ?
Hello,
If you want to set UI with Karel program, a solution is to map your UI to Flags using Rack 34, Slot 1
So for exemple, if you map your first 18 flags to the 18 UI signals, and want the UI[8] to be TRUE, you just have to set FLG[8] to TRUE
In Karel program :
FLG[8] = TRUEAre you saying I'm incorrect about the information I provided by Fanuc then?
I'm saying that I had the exact same problem with the exact same error message during installation, and running the install as administrator was the first thing I did, and it didn't solved the problem for me.
I'm just sharing my experience with this problem.
Hello kwakisaki,
I have full administrator rights on my laptop, and running the setup as administrator did not solve the problem for me.
Hello,
I had the same problem. I found a way around by installing a previous revision of roboguide and then installing the current revision.
Error messages still appear during installation, but roboguide works.
@kluk-kluk, @HawkME I realize you are absolutely right.
I'm kinda new here and with robots, so I tried to do what they asked me without really thinking.
Now I understand if they want to get the most out of the robots, they have to adapt according to the brand.
On the other hand, for the moment our applications are not very complex (simple pick & place) and this is perhaps not necessary.
rf103 , that's right, Robots are completely controlled by PLC.
HawkME I used this as an example, as they did not tell me clearly why they need it.
But you're right, that would be the right way to do it.
The thing is PLC side actually handle things with this tracking progress functionality with other robot brand, and the current policy in the company is to standardize the PLC programs as much as possible.
Using TB and DB would require specific development for them.
But they will have no choice if there is actually no solution to get the functionnality they want with Fanuc Robot.
Thank you Nation , I'll take a look to R596 option, but I'm already sure that there is almost no chance people here would want to pay for this feature.
What are you trying to accomplish with the knowledge of the current completion of the current move?
Robot is controlled by a PLC among other things. PLC guys are requesting this. There is no specific application for it right now. But I guess they are trying to do something like : "Cylinder out/Conveyor FWD when robot move 3 is >= 50%"
Try to look at:
1. $SCR_GRP[1].$MCH_POS_X to $SCR_GRP[1].$MCH_POS_R in order to get cartesian position
2. $SCR_GRP[1].$MCH_ANG[1] to $SCR_GRP[1].MCH_ANG[6] in order to get joint position
Before reading above variables set $SCR_GRP[1].$M_POS_ENB = TRUE and cycle power.
Maybe that helps you.
Thanks neighbour1 for the tips, but PLC already receives this information, and it seems that it is not enough and wants more 
Hi,
I'm looking for a way to track progress of the robot on its path.
Staübli has this function implicitly:
Each move performed increment the integer part of a numeric value named MoveID, and the decimal part corresponds to the progression of this movement.
For exemple, a move id of 2.62 means that the current move is the second move, and the robot has performed 62 % of this move.
I am looking for a way to achieve something similar, Is there something similar for fanuc robot or maybe a way to achieve it ?
I managed to get something almost functional with the help of the variable $SCR_GRP[1].$DPOS_DST.
To make it simple,
-For the Integer part ,I increment a variable at each start of move.
-For the decimal part, I save the value of $SCR_GRP[1].$DPOS_DST at each start of move in a variable and then calculate a percentage according to the evolution of the value of $SCR_GRP[1].$DPOS_DST.
This work great for FINE moves but not for CNT moves.
With CNT move, integer part increment way before $SCR_GRP[1].$DPOS_DST reach zero. Also if next move is with a different utool, $SCR_GRP[1].$DPOS_DST is modified according to the tool before it reach zero and that the integer part is incremented
I guess this is normal given the nature of CNT movements, but as a result it seems that I am not able to achieve my goal with this variable.
Ok, @ElEsgalho thank you very much, the explanations are very clear !
Hi,
I am a beginner in robotics.
ElEsgalho According to your image, if I understood correctly, for XYZ it is therefore the same as adding 160 in X and 80 in Y to pFirst point relative to the frame fPallet?
p=compose(pFirst,fpallet,{160,80,0,0,0,0})
Can we assume that on the frame fPallet this calculation is the same as compose():
p.X = pfirst + 160
p.Y = pfirst + 80
p.Z = pfirst + 0
What about orientation Rx Ry and Rz ?
Please correct me if this is completely wrong 
Thank you for this very detailed explanation.
I now hunderstand better how Robots work.
Quote((Why is this a problem?))
At the time you read the input, it had a certain value. And this value is correct at this time.
If you have to keep the value "synchronous" with the PLC, you have to program a handshake.
PLC send a bit stream to the robot with a start command and data for motions instructions simultaneously.
There is the way it works now.
PLC : Cmd bit + Motion data stream -> to Robot
ROBOT: Processing data Ok -> to PLC
PLC : New Cmd bit + New Motion data stream -> to Robot
ROBOT: New Processing data Ok -> to PLC
etc...
We use this exact same data stream and operation on other robot brand and that works well.
The problem is, sometimes with Fanuc Robot , the start command signal is processed before some datas that have values of the bit stream n-1, resulting in wrong motion intruction.
As you explained to me, probably because of some IO refresh cycle interruption.
So For this Fanuc robot, I now have to find a way to ensure that all data stream is refreshed before sending the start cmd:
@PnsStarter As you mentionned, the easiest way would be to add an handshake :
PLC : Motion data stream -> to Robot
ROBOT: Processing data Ok -> to PLC
PLC: Cmd bit -> to Robot
ROBOT: Cmd bit Ok -> to PLC
PLC : New Cmd data stream -> to Robot
ROBOT: New Processing data Ok -> to PLC
PLC: New Cmd bit -> to Robot
ROBOT: New Cmd bit Ok -> to PLC
etc...
Ok I understood, thanks for your reply.
I don't know why, but in my mind, the value of an IO would remain the same from the start of a task scan until the end of that same scan.
Hello,
This is my first post here but this forum has already been very helpful to me over the past few months. Thank you !
There is my problem :
We have a R-30iB mate plus who commuicate with PLC through Ethercat (Rack 106,Slot 1).
Datas are processed with a KAREL program that is running with a RUN_TASK instruction and a "While true" with a Delay of 10 ms.
Overall everything works fine except sometimes, where it seems that there is a gap between KAREL variables and GI. So i wrote a test code to confirm it:
TestIO = GIN[10]
IF TestIO <> GIN[10] THEN
DOUT[145] = TRUE
GOUT[11] = TestIO
GOUT[12] = GIN[10]
ENDIFGIN[10] is a variable from the PLC that increment from 0 to 255.
I expected that TestIO <> GIN[10] would never be true and that DOUT[145] to be always FALSE, but it turns out that, totally randomly, DOUT[145] goes TRUE.
The program can Run 10 minutes without setting DOUT[145] to TRUE, but can also sometimes goes TRUE 3 times in less than 1 minute. In the end, it always ends up going true at some point. I Can't hunderstand why.
Does this sound normal to you and if so how do you explain it ? maybe there is a link with ethercat communication ?
Thank You.
