+- RoboDK Forum (//www.sinclairbody.com/forum)
+-- Forum: RoboDK (EN) (//www.sinclairbody.com/forum/Forum-RoboDK-EN)
+--- Forum: General questions about RoboDK (//www.sinclairbody.com/forum/Forum-General-questions-about-RoboDK)
+--- Thread: Milling program cutting corners/deviating from Fusion and RoboDK paths (/Thread-Milling-program-cutting-corners-deviating-from-Fusion-and-RoboDK-paths)
Pages:
1
2
Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-04-07-2022
ccc.rdk(Size: 4.23 MB / Downloads: 172)嗨,伙计们,I am running into a problem repeatedly on both sides of the mold I'm attempting to machine. My cutting tool - (1/4" straight router bit) does fine most of the time, but on occasion decides to cut corners as it is descending (and also occasionally ascending) a parallel pass in the shape of stair-steps. It is cutting off about 5mm of material it shouldn't be removing from the bottom step - on both ends of the mold, often, but not always.
The strange thing is it only does this in some areas.. It also happened on the flip side of the mold (match plate mold, so it is two sided). However, it didn't happen as often.
I have tried playing with the continuous path settings - both turned on and off with my robot, as well as running at fast and very slow speeds, and none of those seem to make any difference. Rounding is set at 1.
There is something happening between the RoboDk simulation and my robot arm that is corrupting the path I need it to take - be that the way the coordinates are post-processed, or the way my arm is reading them. It's as if it forgets or ignores these areas. Perhaps some of the movements are supposed to be arcs but are read as straight line movements?
(In Fusion 360)
Both-way milling with both tolerance and smoothing factor set at 1mm. I imported a grbl nc file from fusion to RoboDk (I don't yet have the plugin for Fusion. Could that be helpful for this scenario?).
There doesn't seem to be much rhyme or reason as to when it cuts these corners, but it is really messing things up for me. It is hit and miss - on the x+ end of my piece it often cuts correctly on the u-cut and cuts the corner on the down cut. But not always. I end up with a straight line cut as opposed to a convex shape.
Using the Adept V+ custom for Staubli post processor. This program is about 22,000 lines of code intended to make refining cuts - not finishing.
Any ideas on what could be causing this? It's quite frustrating and is ruining several days of work.
One thing that is for sure - the path looks perfect in both Fusion and Robodk. Especially when viewed from underneath the model.
Thanks very much,
David
You can see here the 45 degree straight line that should be a convex rounded curve (often it would cut the curve only to cut it off on the subsequent pass).
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-04-07-2022
Ok,
So I suspect it must have something to do with RoboDk or my robot translating what should be good sized arc movements to straight-line movements. Is there a good way to ask my robot to move in an arc? Or is that not supported with the Adept V+ for Staubli post? I know my machine has the ability to interpolate between different joint positions, and to move in arcs, but it is unclear if it can do that while maintaining the tool configuration. I know the moves command will ask it to move in a straight line whilst maintaining the cool configuration, and that the move command may move in an arc - but possibly not the arc we would ask it to use, and thus, not maintaining tool configuration.
Even if RoboDk's post can't make this translation, I would be curious if I can do it manually as an experiment.
It seems the best option I have right now is to create more points in my path. I tried increasing the tolerance in my Fusion path from 1mm to .2mm, and that seems to have taken care of the problem so far. I was hoping to reduce the number of points to keep my programs shorter, and allow the robot to work more smoothly. A friend of mine who knows these older Staubli robots well suggested that a path with a minimum execution step of 2.5mm may help to run my machine faster and smoother.
Will the plugin for Fusion handle this translation any differently? I am sending my file to RoboDk using grbl / nc format.
Thanks!
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-Jeremy-04-07-2022
Hi David,
I did a quick test and indeed the circular moves are not supported by the Staubli Adept VPlus post-processor.
I'm surprised you didn't see this message when you generated the program.
This is clearly your issue, or at least part of it.
Do you have the programming manual of the controller? Or at least an example of what a circular motion looks like with those controllers?
I could try to add this feature for you.
Jeremy
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-04-28-2022
(04-07-2022, 05:25 PM)Jeremy Wrote:Hi David,
I did a quick test and indeed the circular moves are not supported by the Staubli Adept VPlus post-processor.
I'm surprised you didn't see this message when you generated the program.
This is clearly your issue, or at least part of it.
Do you have the programming manual of the controller? Or at least an example of what a circular motion looks like with those controllers?
I could try to add this feature for you.
Jeremy
(04-28-2022, 07:08 AM)davidturnswood Wrote:(04-07-2022, 05:25 PM)Jeremy Wrote:Hi David,
I did a quick test and indeed the circular moves are not supported by the Staubli Adept VPlus post-processor.
I'm surprised you didn't see this message when you generated the program.
This is clearly your issue, or at least part of it.
Do you have the programming manual of the controller? Or at least an example of what a circular motion looks like with those controllers?
I could try to add this feature for you.
Jeremy
Jeremy,
Yes, I get a "circular motions not supported" message.
Circular motions would be really helpful in giving me smoother, more efficient trajectories and no doubt be easier on my robot. How hard is it to implement this kind of motion in the post processor? While it would be really nice for me, I suspect you guys might want to focus on newer machines, as these older Staubli's aren't so common. If you do find the time, I'm sure I'll make good use of it.
Meanwhile,
I think I am getting somewhere with all my experiments.
为cleari得到平滑的运动/小文件ng operations I am using a rounding value of 2. This is fine, provided I leave some extra un-cut material, and the only issue I'm having with that is my speed seems too low. I've tried changing this in various locations (options, as well as in the robot parameters), but the post always gives me the same speed in my program. - SPEED 13.3, 100 MMPS ALWAYS
To avoid the problem of rounding over sharp corners I am increasing point density in Fusion, and checking over the simulations carefully to ensure I don't have any large arcs that would translate to straigh-line movements in RDK. Next I'm using a web based text file splitting tool to break down large files into 23,000 point programs (the most a floppy will fit). ---https://textfilesplitter.com/
This is a pain, as the floppies take a while to load. I just ordered a floppy emulator. Hopefully I can get it to talk to my robot controller. I recently added a flash hdd to it as the original was toast. The upshot to ridiculous files sizes is better detail, thankfully.
While I know it's possible to describe most any arc in V+, my math skills are not good enough to know how to do that efficiently, or in a format that makes sense to the Adept controller.
I did find some language to convert cartesian coordinates to joint positions for the Staubli, but I know it's the shape of the arc we want, in addition to the locations.
The Staubli does want to allow for a continuous path (smoothed corners) motion - but that will only work using a "move" command, as opposed to a "moves" command used in the Adept V+ post. Despite it not being exactly what I need, being able to set the "move" command instead of "moves" might be useful for clearing operations.
These are the two Adept V+ manuals I find most useful. I've added a few snippets from them below.
https://www.engr.colostate.edu/me/facil/ramlab/adept/v_lrg.pdf
http://bdml.stanford.edu/twiki/pub/Haptics/PhotonicRobots/VLanguageUsersGuide.pdf
I have also made some programs to draw spirals, which may or may not be of any use to you, but if if they are let me know and I'll send a few along.
I found this on page 608 of the V+ language reference guide:
Examples
If r is the radius of a circle and angle is the angle of rotation about the circle, then
the transformation:
TRANS(r*COS(angle), r*SIN(angle), 0, 0, 0, 0)
will yield points on that circle.
If frame is a transformation defining the position of the center of the circle and the
plane in which it lies, the following program segment will move the robot tool
point around the circle in steps of 1 degree.
FOR angle = 0 TO 360−1
MOVE frame:TRANS(r*COS(angle), r*SIN(angle), 0, 0, 0, 0)
END
More from the V+ Language User Guide:
Basic Motion Operations
Joint-Interpolated Motion vs. Straight-Line Motion
The path a motion device takes when moving from one location to another can be
either a joint-interpolated motion or a straight-line motion. Joint-interpolated
motions move each joint at a constant velocity (except during the
acceleration/deceleration phases—see “Robot Speed” on page 203). Typically,
the robot tool tip moves in a series of arcs that represents the least processing—
intensive path the trajectory generator can formulate. Straight-line motions
ensure that the robot tool tip traces a straight line, useful for cutting a straight line
or laying a bead of sealant. The instruction:
MOVE pick
will cause the robot to move to the location pick using joint-interpolated motion.
The instruction:
MOVES pick
will cause the robot to move the pick using a straight-line motion (page 197)
Page 199:
Continuous-Path Trajectories
When a single motion instruction is processed, such as the instruction:
MOVE pick
the robot begins moving toward the location by accelerating smoothly to the
commanded speed. Sometime later, when the robot is close to the destination
location pick, the robot will decelerate smoothly to a stop at location pick. This
motion is referred to as a single motion segment, since it is produced by a single
运动指令。
When a sequence of motion instructions is executed, such as:
MOVE loc.1
MOVE loc.2
the robot begins moving toward loc.1 by accelerating smoothly to the
commanded speed1 just as before. However, the robot will not decelerate to a stop
when it gets close to loc.1. Instead, it will smoothly change its direction and begin
搬到ward loc.2. Finally, when the robot is close to loc.2, it will decelerate
smoothly to a stop at loc.2. This motion consists of two motion segments since it is
generated by two motion instructions.
1 See the SPEED monitor command and SPEED program instructions.
Chapter 8 Motion Control Instructions
200 V+ Language User Guide, Rev A
Making smooth transitions between motion segments, without stopping the robot
motion, is called continuous-path operation. That is the normal method V+ uses
to perform robot motions. If desired, continuous-path operation can be disabled
with the CP switch. When the CP switch is disabled, the robot will decelerate and
stop at the end of each motion segment before beginning to move to the next
location.
NOTE: Disabling continuous-path operation does not affect
forward processing (the parallel operation of robot motion and
program execution).
Continuous-path transitions can occur between any combination of straight-line
and joint-interpolated motions. For example, a continuous motion could consist
of a straight-line motion (for example, DEPARTS) followed by a joint-interpolated
motion (for example, APPRO) and a final straight-line motion (for example,
MOVES). Any number of motion segments can be combined this way.
page 215:
SOLVE.ANGLES PI Compute the robot joint positions (for the current robot)
that are equivalent to a specified transformation.
SOLVE.FLAGS RF Return bit flags representing the robot configuration
specified by an array of joint positions.
SOLVE.TRANS PI Compute the transformation equivalent to a given set of
joint positions for the current robot.
Thanks for looking into this! I realize you probably have bigger fish to fry, but I can't tell you how much I appreciate the assistance. If you do find the time to work on it, I hope it improves your product in some way. There are certainly quite a few of these older staubli's around, and I know I'm not the only one who appreciates it.
Best,
David Earle
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-04-28-2022
OK,
Thankfully my speed issue was just an oversight in Fusion 360. Somehow I had accidentally set my speed very very low, which translated to overly low speeds in RoboDk. I should be good to go now. Just need to be careful about the path planning.
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-Jeremy-05-03-2022
Hi David,
I asked @Alexto take a look at the circular motion.
Jeremy
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-05-05-2022
Thanks Jeremy,
That would be excellent if it worked out. It would certainly smooth things out between software like fusion and the robot, with far fewer opportunites for mishaps.
The other thing I am having trouble with: A single good quality finishing pass takes 48 floppy disk transfers (over a million coordinates). Something very helpful would be file splitting that gives each chunk it's own header (or whatever you call the top 9 or 10 lines of code in v+) that names the program, speed, ect, and starts the tool point in the joint pose, then the "above" pose, as well as the tool retracting and an "end." statement. I would just use files after the first one with no header but my controller won't recognize them as viable programs.
The other problem I need to figure out is a drip feed. I can only load 4 of these chunks into my system's memory at a time. I'm not sure if this is how your drip feed works, but I need to load a couple programs, and as soon as one finishes, dump it out of memory and load the following program. This is less critical, but would still make my life easier. It's not a huge deal if I can only run 4 at a time (much better than one), but file splitting that gives each chunk the correct formatting, and ensure the tool doesn't crash in between would be tremendously helpful for milling.
It has been challenging, but a lot of fun to figure out where the limits of my machine are.
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-Albert-05-06-2022
You could change these settings to prevent exporting arcs:
- Select Tools-Options
- Select the Program tab
- Select Avoid Arcs
You can edit these tolerances to reduce the density of points. This will also reduce accuracy.
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-davidturnswood-05-06-2022
Thanks Albert!
That is helpful to know. I am all sorted out in terms of accepting small lines over arcs. I can make it work, it's just a huge amount of data per finishing pass to feed my older robot (a whopping 60mb!).
我要保持试验的有限元方法eding these large files to my Staubli controller. Do you know if it makes sense for each of my "chunks" (22,000 line chunks of the larger milling pass) to include all the info in the header? I would think it's important to keep the program name, define the base, and the TOOL TRANS. It seems less important, or even problematic to include the joint position and "above" move, provided I go from the end of one chunk to the beginning of the next without changing positions.
我仍然用软盘和启动/间切换stopping this program manually I occasionally create a postion with a higher Z number at the end of a chunk. I then use a MOVES (straight line move) to move the tool above the workspace without changing the tool position. This allows me to shut off the router and take a break, ect. I am trying to figure out how important it is to go back and assume the #PPPOINT (joint pose) prior to restarting the next chunk. It either requires a lot of manual editing on my part to make that happen, (to bring me back to the correct "above" location.) I am wondering if the robot will slowly "forget" that original joint pose - or if the moves commands keeps everything accurate?
If repeating the starting pose isn't so important I may try and add to the end of each chunk a MOVES command that does what I do - move the tool up 50mm or so. At beginning of each subsequent chunk I would require a confirmation from me to descend 50 mm down. This would be nice as these simple commands would be relative to the robot's location wherever it is throughout the milling pass and I wouldn't have to manually enter Z coordinates on each of 50 or so chunks.
Below is what Robodk produces (I removed the extra info)
.PROGRAM F1()
BASE 0,0,0,0
SPEED 70.0, 100 MMPS ALWAYS
TOOL TRANS(136.400,-12.630,64.600,-3.396,88.999,57.254)
MOVE #PPOINT(65.52000,-78.58000,200.50000,-21.46000,-32.71000,17.00000)
MOVES TRANS(69,611,0,0.000,180.000,-19.680)
SPEED 66.7, 100 MMPS ALWAYS
(after this point 22,000 lines of "moves" commands and coordinates.)
I imagine you guys support file splitting on many of the contemporary robots, and have clever ways to do it. If you have any advice I am all ears. On the other hand, I feel like ya'll have helped me out a lot already, and I can probably sort out methods to get this done. No worries if things are busy.
Thanks so much for helping teach my classic robot some new tricks :) The scope of what RoboDk is doing is pretty incredible. Once I sort more of this out, and if you guys are interested, I'd be happy to document my wood milling experiments with photos, videos, and a write-up. Although I completely understand if you have enough of that stuff.
David
RE: Milling program cutting corners/deviating from Fusion and RoboDK paths-Jeremy-05-12-2022
We are always interested in new success stories. Thanks for the offer.
Let's see if Alex finds the time before June. We have a tradeshow coming up in June and we are focusing on that. :)
Jeremy