Ramp speeds, turning corners, odd behavior...

[harryball]

I took one of my bat house groove files and made the ends of the runs round and not square. I expected the bot to turn the corners faster but still on a ramp since the radius of the turn was increased from a square corner.

Now the bot turns some of the rounds BAM! way too fast and jars the entire table. Then it does perfect turning some of them, faster than a square but nice and smooth. Finally, on many others it slows down to a crawl and turns very very carefully and slow.

I examined the nodes and they all look the same. Besides, I thought the bot software should preclude trying to turn these corners at 10 ips anyway. I attached the file.




How can I get it to turn all the curves in the same "happy and faster than a square" manner?

Robert

roost_grooves.zip (http://www.talkshopbot.com/forum/messages/26/roost_grooves-15820.zip) (48.1 k)

[fleinbach]

Are you using the latest software? If I remember corectly some earleier versions had this problem.

[harryball]

I just verified it, I'm running 3.4.27 which appears to be the latest release.

Robert

[bob_lofthouse]

I read recently or someone told me that if you can get away with it make sure the radius of any corner is greater than your radius of your bit/cutter, therefore avoiding some of the ramping issues....

[Brady Watson]

Robert B,
Since you are the builder, do these HAVE to be EXACTLY like you have them? Do they NEED to go back and forth in a matrix-type fashion with only every other end connected to the next? If you could eliminate the ends needing to be connected with little vectors and replace them with one solid line (attach all horiz lines with 2 vert ones) then you will pick up a LOT of time. Also, it is possible to do ALL horizontal lines (multiple parts) in one fell swoop by programming the tool to do an M3 that ramps the tool into and out of the cut at speed. This would allow you to pick up an incredible amount of speed. You won't be doing all of the programming in PW, but since you are making the same thing over & over again, it justifies the R&D of developing a faster method.

Aside from ramping up and down at the extents of the raster, the real speed bottleneck are the Y moves that just tie the horizontal lines together.

Thoughts?

-B

[harryball]

I've tried several methods. I don't need the Y moves but I found it's faster than stopping, raising Z, moving, lowering Z and running another groove. I've run them square and round. The most recent incantation I made the end turns round with a 1/2" diameter circle, not with nodes using the corner radius tool.

With the round corners created from a circle it is by far the fastest and most consistent speed, but the entire table rocks as it turns the corner.

Running full table length is not an option. The ends of the cut grooves would be exposed on the side construction. The sides must be caulked and sealed. My other option is to change the design of the sides and add rabbits to hide the ends of the ply... but that involves significant design changes and my jigs would have to be reworked.

Robert

[Brady Watson]

Robert,
I don't think I explained as clearly as I should have. Run the attached SBP in preview or air cut. It is not ready for prime time since I don't have it totally optimized to raster back and forth, but it will give you an idea of what I mean. It ramps in & out of the work in Z and eliminates software ramping. Also, I did not add lines in the Y direction (this is what I was asking you about) If you added 2 straight lines per panel it would elminate the zig-zag that is slowing you down. It is best to air cut this so that you can see the Z working (it is @ .05" deep, and I see that your design only calls for .015" deep...it'll work for demonstration purposes)

-B


BatTest.zip (http://www.talkshopbot.com/forum/messages/26/BatTest-15867.zip) (21.4 k)

[harryball]

OK... so it's hopping across the table. I didn't think of that. My only turns would be at each end of the table then it would hop back.

Now that's slick... I hope it works... my wife just forbade me from trying it out tonight though I don't know how I'm going to sleep until I do :-)

I was only able to get 15 kits out today. Mr. Bot spent most of his time drawing zig zags.

I will update you as soon as I know how it works!

Robert

[harryball]

Brady,

How did you create this toolpath? I've been trying to create it in PW and VCPro and neither seems to support it. Lead In/Out moves in PW are either at an angle or circular. VCPro doesn't seem to support leads at all.

If my software is not capable... I'm still in the same boat and will probably have to live with zigzags for a while.

Robert

[Brady Watson]

I did some of it in ArtCAM and other parts by hand...So no, you are not going to do that with the software that you have. If you are going to be cutting a ton of these out, then get the coffee and imagination out and hand code one line...then use ShopBot programming to block copy what you have done on one line. It may seem like a lot of work at 1st, but multiply out the time vs. machining time gained.

A customer sent me a PW file that he made to do production work. It was taking him 90 minutes to cut his parts the way he set it up. I hand coded all of his parts (even had to turn off the phone while I did) and we got the time down to about 30 minutes for the same number of parts. A CAD/CAM package is convenient, but not always the most efficient thing to generate code when production numbers become the primary concern. If doing one-offs all day, then a CAD/CAM package is the most efficent. If you cut the same thing over and over, it is not.

-B

[harryball]

Well... I do love a challenge and I will be cutting hundreds of these. I will get my imagination out of the box and dream up something.

One thing I find appealing is the programming like style I can use in sbp files. It is, afterall, just a programming language and that's part of what I use to do, if I can master C... but then does anybody ever really master C?

Robert