How does advance pointer affect it, if you send $act_pos to the external PC for example every 10ms and then the external PC calculates the vector?
Posts by Spl
-
-
The other way of doing continuous streams, is to put the eki_send commands in sps and just enable them with global variables.
-
> The problem is that the vision system needs to know where the robot is coming from, so that it has a starting point for the simulation.
If your system needs to know where the robot is coming from, then why not just send current pose in some intervals, and calculate approach vector from the last two poses? And if you need, you could calculate from the vector and the poses the closest point it will cross and make that the target.
-
-
-
Try
DECL FRAME relpos
relpos = {X 0, Y 0, Z 0, A 0, B 0, C 0}...
relpos.X = variable
LIN_REL relpos -
This is just a guess, but if the point density is high in the circular parts of the path, the robot is unable to achieve the desired velocity due to path planner constantly approximating, so setting $ADVANCE higher might help. Or just use spline if possible.
-
I have used binary communication from the sps.sub, so I don't see why it wouldn't work for xml messaging too. The EthernetKRL manual states that you can use the EKI commands from both robot interpreter and submit interpreter.
-
I guess you could put the communication handling into sps.sub, where you put all sent coordinates into global FIFO and have the main program just process the FIFO.
-
At least with KRC4 you can place the EKI calls inside the submit interpreter with no problem.
From the manual:
"Ethernet connections can be created and operated by the robot interpreter or Submit interpreter. The channels can be used crosswise, e.g. a channel opened in the Submit interpreter can also be operated by the robot interpreter." -
-
"The problem" with dynamic collision free path planning is that you need to input environment model, robot model and tool model to the algorithm for it to calculate the path. So it's just not worth it if you want efficiency.
-
Problem "solved"!
So, the problem was that the load check calculation wasn't using the tool / load data that I specified before the motions with $tool and $load. Instead it was using the data specified by the initial inline ptp motion, so I had to add bas(#tool,x) to make it use the correct values.
Thanks to you all for help.
-
I have set the tool with $TOOL = TOOL_DATA[ x ] before the LIN commands, but can't say the tool load data is exactly right, because we don't have the load data determination toolkit. That said we do have a ft sensor mounted to the flange, and we do have our own algorithm to calculate the cog, which we have successfully used to do gravitation compensation for force control. And by setting the inertia values higher than calculated, we at least shouldn't get the overload error.
But I guess I'll just have to recheck everything tomorrow.
-
I just doesn't get it why it gives the error only in slow speeds.
-
Yes we have added the inertia values. Even if we use the ridiculously high default values or we uncheck the 'load data verification', the error still persists.
-
We have played with both supplementary load data and tool load data and both did nothing.
-
Hi,
does anyone know what causes the error "KSS32006 Overload calculated when checking robot load (no tool defined) and the set load data"? We get this error when using LIN motions with $vel.cp set to 0.01 and $acc.cp set to 10. And if we either raise the $vel.cp or lower the $acc.cp the error seems to go away (no extensive testing), but then we sometimes get "Underload calculated when..." warning.
All the load we have attached to the robot is a appr. 8kg mass in the flange.
I know that it's probably not a good idea, but is there a way to turn off the load checking because we will most likely never reach the actual robot's load limits?