Partworks zero and tool change question

[stumpgrinder]

I was looking around the program and can't find how to make the changes I need, so was wondering if anyone else knows how to do it.

First, during the zero routine, I'd like to add a few seconds time between the point I hit enter to start the zero routine, to the point the machine starts to lower the bit.

Second, when doing a tool change, PW asks if the second tool is installed. When you hit "No", it asks if you would like to change the position to install the new bit. I usually say yes, then raise the Z axis to help me get at the bit. When I close out of the control pad, it then asks something like "hit enter when second tool is installed and ready to zero". After you hit enter, it then drives the router to the last position before I rased it. This is problematic if I'm using a bit that is much longer than the first, and one time did actually plunge the bit into the work piece. Is there a way to remove that step, so that it stays at the position it was raised to?

Thanks!

[dana_swift]

Lauri- I suspect you have a misunderstanding about how zeroing and bit changes are set up. The SB3 program does the zeroing not Partworks. So no amount of reading PW docs will make any sense!

When you hit C2 to zero your bit on the ZZero plate, what SB3 does is run a series of files that ends up running the file "C:\SbParts\ZZero.sbc"

You can edit ZZero.sbc and make it do whatever you want. That is where you need to put your delay request.

How to add the delay? The documentation is thick at first, but you will find the file "ProgHand.pdf" in the "Program Files\ShopBot\developer tools" folder. It explains how to customize your machine more than you ever imagined.

There is a pause command, and now you have to study the code (not a trivial thing) to figure out where you need to put it to get the effect you want, then make the change.

You can make it work any way you need. I have heavily modified mine.

Its another level of complexity most people never get into. But fear not, its not all that hard or I could not have done it. And its very rewarding!

Good luck!

D

[stumpgrinder]

Thanks Dana, yeah that makes sense that the delay would be in SB3. I figured it was something that is inported from PW regarding the moving in the Z after changing tools. For the 3D stuff we do, we usually set up the file in rhinocam, then post it for running on the bot. We run each file individually so never have to worry about tool changes and this issue happening. Looks like I've got lots of reading to do!

[mblackwell1002]

Second, when doing a tool change, PW asks if the second tool is installed. When you hit "No", it asks if you would like to change the position to install the new bit. I usually say yes, then raise the Z axis to help me get at the bit. When I close out of the control pad, it then asks something like "hit enter when second tool is installed and ready to zero". After you hit enter, it then drives the router to the last position before I rased it. This is problematic if I'm using a bit that is much longer than the first, and one time did actually plunge the bit into the work piece. Is there a way to remove that step, so that it stays at the position it was raised to?

Thanks!

This is what caused my broken bit! I would love to hear the answer to this one!

[dana_swift]

Matthew and Lauri-

That must be a problem with the manual tool change logic. I just create independent tool paths for each bit. So no problem with plunge into the material.

Try independent tool paths..

Between bits, DO NOT rezero x and y, or you will make a mess of the project, but be SURE to zero Z with the new bit!

D

[adrianm]

I use the manual tool change routines although I've modded them quite a bit to take account of my Z axis prox switch and a few other things.

However when I first started using them "out of the box" I never had an issue with the bit going into the material like that.

When you ran the ShopBot setup routine did you tell it to use a fixed XY location for the Z-Zero routine? That's the only place in the code I can see that would move the tool at the point you say it's happening.

If it's just the Z that is moving then the routine moves the Z to the Safe Z pullup as set in the cutter settings (VC) in SB3. If your current Z is higher than that setting then it will use that instead so it shouldn't be doing what it is for you.

Not sure what version of SB3 you're using but I'm pretty sure some of the earlier versions used the safe Z setting set during the ShopBot setup routine rather than the one set in VC.

[stumpgrinder]

Yes, this only happens when I export the cut files from partworks into a single cut file. As individual cut files, there is just a prompt at the begining to make sure the right tool is installed and that the z axis is zeroed. So all that is fine.

We are running into the issue where say we engrave the top of a 1" thick workpiece with a micro end mill, then want to cut out the piece with a .5 inch end mill that has an overall flute length of 2 inches. We will run the micromill file, then at the end of the file it brings the micro mill up so that it is at the safe Z height, which we have set for .5 inces. So we are then asked by the program if we would like to move the bit to another location to change out the bit. Since there is no way we can install the larger bit at the last place it left the micro mill above the work area we say yes and raise it up enough to change out the bit. We do not move it in the X or Y. If we install the .5 inch bit, and close out of the control pad, a prompt comes up that says something like "install next bit and hit enter when ready to zero". The second you hit enter, the z axis will return to the position that it was in before you removed the end mill. Since the .5 inch bit is much longer, it will plunge the bit into the material. We could run the bit all the way off the materal and zero out there, or we could just run individual files, but I would like to find a way to remove that z movement out of the program.

[adrianm]

Why not just set the safe Z higher? 0.5 inches is very, very low in my opinion. The whole idea of the pullup safe z is that it's somewhere the machine can move to with no risk of what you're describing happening.

Typically I set my safe z to be as close to the maximum height of the Z that I can get.

The Safe Z is only used at the beginning and end of the job so it's not going to slow your job down any.

The safez and clearance Z settings in PartWorks aren't used by the manual tool change routines or zero z routines in the Shopbot software it's the one set using the VC command in the Shopbot control software that you want to set.

If you really want to remove that movement (I would definitely try changing the safe z settings first) the file you need to look at is c:\sbparts\custom\mtc\mtc.sbp

[stumpgrinder]

Hi Adrian, setting the safe Z higher is not an option for us. We're working on a desktop with only 4" of Z travel. Add the spoil board height, work piece height and the length of the bit and your out of real estate real quick! We lowered the Z to .5 inches and sometimes even just .25 inches above the work piece because there have been several times the Z has topped out in it's direction of travel causing lost steps, and a ruined part. I try to use stub length bits if possible, but for the scenario described above, we need the longer length bit. Going to have to go digging around in that programming, or just use seperate files for each bit.

[adrianm]

It might be worth emailing shopbot support directly over this as I can't see how what you're describing can be happening with the standard routines.

In every place that I can see when the Z is told to move to the Safe position it first checks to see if the current position is higher than the Safe position and, if so, it then uses that position as the Safe.

I don't see why the Desktop should be working differently to a PRS in this regard but if it is support would know best.

[Ross Leidy]

I just experienced this issue myself on my first attempt at a sign. There were 3 toolpaths using a V-bit (which was the short one) followed by an end mill bit to cut the outer profile (longer bit). Everything was going fine with the V bit. When prompted to change bits, I raised the Z, changed to the end mill, attached the alligator clip and positioned the Z-plate. I moved through the prompts until it was supposed to run zzero, and it drove the end mill into the plate. Left a nice gouge, but didn't break the bit. Why the dive in Z prior to Zzero? My safe Z was set to 1.0, which should have been plenty. It's like Z is being moved back to the same position as the previous tool was at.

I tried changing the safe Z height to 2.0 and just experimenting with MH and JH to see what would happen. Even though I use SK to position Z lower than safe Z, when I run either MH or JH, it never raises Z - just moves X,Y. SB3 is clearly reporting a Z value under 2.0, so I'm not sure how to fix this.

[stumpgrinder]

OK, we posted a video of the issue we are trying to correct. That's Max in the video. Also note that right after the last prompt in the video, is when the program again asks you if you want to move the bit to a different location, then after that is answered it prompts you to hit OK, when you are going to zero it on the plate. Thanks!

http://youtu.be/QFvxzQdPoWI

[myxpykalix]

I watched your video and i don't have a desktop so i'm going to guess that what it is doing is going back to a "preset" of your X,Y,and Z.

Thinking outloud here, can you go back and (without a bit in) change your
"home/start position Z setting" to a different number (higher or lower) and see if it goes to the exact height you show in your video?

if it is different then your issue is in your "home/start position Z setting".

I kind of have a similar situation where if i hit my JH the bit goes down to Z zero on the surface of the material before moving X,Y and wants to scratch the surface. However if I do a MH the bit stays at its raised height and moves only in the X,Y

What this sounds like to me is a erroneous setting somewhere in the "preset instructions" it uses for the setup of those toolpaths (if that makes sense).

Can you look at your sbp file and find the section of code where one file ends and the next begins?

I have an observation however. It seems to me that just making them as seperate toolpaths is less work??:confused:

[Ross Leidy]

I'm very new to the SB, but no stanger to programming. I did a little poking through my generated sbp file and the custom cut files, and I think I may see the issue. Perhaps someone with more experience with sbp could confirm.

In my generated sbp file with multiple toolpaths, there is call to C9 when there is a required tool change. For me, that's a change from a short V bit to a long compression bit.

C9 runs the custom9.sbc file. Custom9 runs the file MTC\MTC.sbp for manual tool changes.

In MTC\MTC.sbp, there is a subroutine Changebit that prompts you to raise the bit with SK. After you exit from SK, it prompts you to "Change bit to <toolname> Number <n> Then Enter when ready to Zero". If you hit OK, it jumps to the label JustZero.

JustZero immediately calls SAFE_HEIGHTS. For my 3-axis machine, SAFE_HEIGHTS issues the offending command:

J3,,,%(28)

%(28) is the safe Z height, but it's the height based on the previous shorter bit. This jog drives the bit into the work (or Z plate).

I believe that a safe fix would be to modify SAFE_HEIGHTS to check to see if the current Z is higher than %(28) and if so, skip the jog.

[adrianm]

Sounds like you're running an older version of the SB3 software which would explain the problem.

That bug was fixed a few versions ago. The routine now checks the current value of Z and compares that to the Safe Z (%28) and uses the current Z if it's higher.


If %(3) > %(28) Then &SafeZ = %(3)
J3,,,&SafeZ

[Ross Leidy]

I received my Desktop in November and had just assumed it was shipped with up-to-date software. I'll be sure to check the installed version when I get back to the shop.

Edit: I just checked. The Desktop came with 3.6.38 - a couple versions back from current. I checked MTC.sbp in Version 3.6.44, and it does appear that the problem has been fixed.

[stumpgrinder]

Just checked ours and it was out of date. Uploaded the most current version and that solved the problem. Thanks for pointing that out!