Thank you for pointing me in right direction… much appreciated.
I’d like to get deeper into custom programming the Masso post processor to see if I can gain any efficiencies for batch production work, such as using multiple fixtures/jigs, etc. Since Masso can more gracefully handle manual tool changes, can you think of any pros/cons of running a single gcode file with multiple manual tool changes vs running them as separate files, one for each tool change?
Great to hear! Thank you.
Hey Mike,
usually you would say, if your program is well-tested and mature for production, one g-code program with all the tools saves time.
Many forum members here say the advantages of one g-code program per tool is that you can change the program for a certain tool easier or re-run a pass easier. They put the name of the tool into the file name, and the pass that it is for.
Thanks again… that was very helpful.
Yes to this. I used to be in the camp where I wanted to keep all tools in the same program. But because I don’t have an ATC and am not running production on anything, I find it more convenient and flexible to actually program for separate tools. So even though I can program for tool changes, I prefer not to.
I was in the “one program per tool” camp until I implemented the tool setter then I found it was easier to and more accurate put them all in one program and use the tool change to measure T1 Z height, switch to tool 2, then measure T2 Z height and automatically reset the Z offset accordingly. This also works well if your Z axis zero point no longer exists after running the first tool path.
Now Available:
So looking at all of this. I do basically understand what your trying to do here mostly, however its still very confusing to me anyway. So just to clarify, and again im still fairly new the cnc. What exactly is the purpose of doing all this setting change? What Im asking is, what exactly is it doing to or for the machine that makes such a big difference/ OR noticeable difference?
Also!! By doing this settings change. What does it imply that I can do compared to the previous settings? Am I now able to use the group together tool path saving option without having to save everything separately? Or what does this exactly mean?
Just want to fully understand exactly what im doing so I can fully understand. In other words im asking all this to learn more about it. Now questioning your settings
Thanks!
Im not buying another Oneinifty product!! In my opinion this is just another excuse for you guys to make even more money off your customers when this could have or a different option could’ve been given with the machine to begin with! I’ll also ad that I SPECIFICALLY asked Onefinity about a newer machine coming out right before I purchased the x50 and less than a month later a new machine was released!
So, of this specific reason alone not only do I tell everyone who sees my machine and asks many questions about it, unlike everyone else who tries to sell people on them. I tell them exactly how it is and how big of a learning curve it is on average of months or more of not only the machine but the software to learn. And the issues people have and having to come to the forums does help and thankfully everyone here is very nice and helpful. I feel I should not have to come here as often as I do. But this is my opinion and im sure there will be some sort of reply you will have to make it seem im in the wrong or other and im sure someone else on this forum will have a comment or 10 to make as well. I still stick with what I wrote here.
I personally probably would think twice before I ever bought another product from onefinity again me personally and would go with someone else.
Hey Sean,
If you leave the faulty code that is in the ‘tool-change’ field when the buildbotics-derived Onefinity controller is delivered, then on a ‘tool change’ event you won’t be able to change the bit because it will not raise the router/spindle to allow it. You will be stuck and be forced to abort the program. I don’t know who put this faulty g-code into this field, but it seems not to have been someone who knew what they did or had good knowledge of g-code.
Therefore you need a working ‘tool change’ routine in this field. My Aiph5u’s ‘tool change’ routine provides that. That is a short g-code that instructs the machine on how to behave if it encounters a ‘tool change’ event. It is something you need if you have multiple tools in one file and it is something the Onefinity manufacturer didn’t provide.
In detail, Aiph5u’s ‘tool-change’ routine will do the following:
When the machine encounters a ‘tool-change’ event in your g-code toolpath (i.e., a M6 command), first the ‘tool-change’ routine will save internally all modal states of your running program.
It will then stop the spindle or the router.
Then it will move the router/spindle to leftmost, frontmost and topmost position which is the most comfortable position for you to change the bit.
It will then pause and popup a window that says “Please insert tool Nr. #<_selected_tool> and tighten the collet with both wrenches”, and it will wait until you click “Continue”. (The variable “#<_selected_tool>” will be inserted automatically by taking the tool number from your g-code program that is selected for this pass). This is the moment when the operator changes the bit, and when ready, clicks “Continue”.
Then the ‘tool-change’ routine will move the router/spindle to a position 1½ inches above your last workpiece zero position.
Then it will pause and popup a window that says “Please connect the touch probe to the controller, place the touch probe underneath the bit and attach the magnet end to the collet of your router” and it will wait until you click “Continue”. This is the moment when the operator puts the XYZ Touch plate into a position underneath the bit and attaches the magnet end to the router’s collet, and when ready, clicks “Continue”.
The ‘tool-change’ routine will then very slowly lower the router/spindle until the bit’s tip just touches the touch plate (that is the Z probing step for making the machine know the length of the new bit)
Then it will move the router/spindle upwards again and pause, and popup a window that says: “Please remove the touch probe and start the router” and it will wait until you click “Continue”. This is the moment when the operator removes the XYZ Touch plate and the magnet end of the touch plate from the router’s collet, and, if the router is not wired to start automatically, switches the router manually on again, and when ready, clicks “Continue”.
Now the ‘tool-change’ routine will restore the modal states of your running program that it saved previously and start the next pass with the new tool.
If you don’t use my ‘tool change’ routine or a routine with a similar functionality, the machine will do none of the above, or useless behaviour, and leave you stuck with a program where you can’t change the bit because it doesn’t raise the router/spindle.
I suggest you try it out. It is always difficult to understand such things in theory.
Hey Aiph5u,
This is all very interesting and informative. Thanks for taking the time to share. Do you know if the moves for an ATC could be programmed in the same section?
M.
Hey M,
yes, but as far as I know, no one wrote one for the buildbotics-derived Onefinity Controller yet. What you need for running an ATC, is first to populate the tool table with tool data. You can do that manually with g-code but it would be wise to implement a tool setter routine first to automate this.
And of course you would still need an ATC spindle like the Jian-Ken JGL-80 or the Mechatron ATC-8022-42-HSK25 (watch unboxing and test run video), a tool magazine, and the pneumatics to run it. See all this in action here.
The Masso G3 (used in Onefinity Elite Series) has such an ATC and tool setter support already integrated.
For introducing such g-code routines, it would be nice if Onefinity’s fork of the Buildbotics CNC Controller backported macros like available on original Buildbotics.com CNC controller since version 1.0.0. That was requested for the Onefinity many times (see also here and here) as well as the ATC functionality. But Onefinity does not support manual spindles, so I doubt the help for using ATC spindles will come from the Onefinity manufacturer. It will have to be done by the user’s community.
The original Buildbotics.com CNC Controller is still under development. It evolved a bit (What’s new in Buildbotics 1.0.0, What’s new in Buildbotics 1.0.2) since Onefinity forked it for their own controller.
PS: Mike Bogart @BNB187 wrote this Bit setter macro v2.0 (updated version) that you can enter into the ‘program-start’ and the ‘tool-change’ fields of the SETTINGS page. I have not tested it. He doesn’t use the tool table but stores the tool lengths in g-code user parameters (#31–#5000). He also wrote a ‘tool-change’ routine similar to mine.
@Aiph5u per your last post I was looking at the Bit Setter Macro that @BNB187 wrote and comparing it to yours. I am curious if I wanted to use his bit setter macro and your Tool change routine would they be compatible or the fact that you are using the tool table and he is using gcode user params make it incompatible?
What I am trying to achieve is a tool change using the Rapid Change automatic tool changer. Whether or not folks here like the approach of RC-ATCn it fits my budget and its what I bought, I am trying to get this to work on my BB machine since we now have macros that I thought might help.
So my thought is that I could associate a tool number with a pocket number on the RC-ATC. When the machine hits a M6 it would execute your tool change routine, saving modal states, setting distance, then metric, etc … and then somewhere in there uses the tool number to go to an empty pocket, reverse the direction of the spindle and set it to 700 then lower into the empty pocket, which removes the collet, sets the spindle speed to 0, raises back up to a safe height, moves to the pocket number (a set of XY coords where x remains the same and y is set per the pocket number X set distance ) and sets direction to forward and spindle speed to 700 and down into the new pocket to grab the next collet and tool. Once it has done this I would need to measure the length of the new tool (perhaps using Mike’s bit setter?) and then resume the cut.
Thoughts? How could these two routines be modified/combined to achieve this?
Hey makermatt,
my M6 ‘tool-change’ routine does not differ much from the second part of Mike’s bit setter macro but his is a two-part tool setter routine (one runs at ‘program start’, one at ‘tool change’ in the SETTINGS page). Besides the fact that I have other dialogs and helpful comments in the code, it does what a tool setter does: It probes and stores the first tool Z at program start, remembers the previous G92 offset which is your workpiece Z zero (=workpiece height) that you probed (or manually set) before program run, and on the next tool change with probing Z, computes the new Z height according to the difference of the first tool to the second tool. It saves the G92 offset each time with G92.2 and restores is with G92.3.
Here I took Mike’s Bit setter macro v2.0 and added Aiph5u-style comments so you can better understand and tweak it:
Part one, for the ‘program-start’ field in the settings page:
| (Runs at 'program-start') | |
| (This is Mike's Bit Setter Macro v2.0 2021-01-13, with comments added by Aiph5u on 2024-03-31 v1.0) | |
| M70 | ; Save modal states |
| M5 | ; Stop the spindle |
| G21 | ; Set metric units mode |
| G40 | ; Turn cutter compensation off |
| G49 | ; Cancel Tool Length Compensation |
| G17 | ; Select XY plane |
| G90 | ; Set absolute distance mode |
| G53 G0 Z-10 | ; Lift Z rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position |
| G53 G0 X780 Y50 | ; Go rapidly to X=780 mm, Y=50 mm in absolute machine coordinates - manual tool change position |
| M0 (MSG, Attach Probe Magnet, Attach Dust Boot, Click "Continue") | |
| G0 Z10 | ; Go rapidly to a position 10 mm above currently active workpiece Z zero |
| G92.2 | ; Turn off G92 offsets but keep parameters 5211 - 5219 available. |
| F100 | ; Set feedrate to 100 mm/min for probing. (which means slow) |
| G38.2 Z-133 | ; Move the milling motor downwards until the bit touches the touch plate |
| #5000=#<_Z> | ; Set the user parameter 5000 to the current Z position value |
| G53 G0 Z-10 | ; Lift Z to rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position |
| M0 (MSG, Remove Probe Magnet, Click “Continue”) | |
| G92.3 | ; G92.3 - Restore the G92 offset to the values previously saved in parameters 5211 to 5219 |
| G0 X0 Y0 | ; Rapidly move to your workpiece X and Y origin |
| M72 | ; Restore modal states |
| G90 | ; Set absolute distance mode |
| G17 | ; Select XY plane |
Part two, for the ‘tool-change’ field in the SETTINGS page:
| (Runs at 'tool-change') | ||
| (This is Mike's Bit Setter Macro v2.0 2021-01-13, with comments added by Aiph5u v1.0 on 2024-03-31) | ||
| M70 | ; Save modal states | |
| S0 | ; Set spindle speed to 0 | |
| G21 | ; Set metric units mode | |
| G40 | ; Turn cutter compensation off | |
| G49 | ; Cancel Tool Length Compensation | |
| G17 | ; Select XY plane | |
| G90 | ; Set absolute distance mode | |
| G53 G0 Z-10 | ; Go rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position | |
| G53 G0 X780 Y50 | ; Go rapidly to X=780 mm, Y=50 mm in absolute machine coordinates - manual tool change position | |
| M0 (MSG, Remove Dust Boot, Change Tool, Attach Probe, Click "Continue") | ||
| G92.2 | ; Turn off G92 offsets but keep parameters 5211 - 5219 available. | |
| F100 | ; Set feedrate to 100 mm/min for probing. (which means slow) | |
| G38.2 Z-133 | ; Move the milling motor downwards until the bit touches the touch plate | |
| #4999=#<_Z> | ; Set the user parameter 4999 to the current Z position value | |
| G92.3 | ; G92.3 - Restore the G92 offset to the values previously saved in parameters 5211 to 5219 | |
| G0 Z25.4 | ; Go rapidly to a 25.4 mm above currently active workpiece Z zero | |
| G92 Z[#5000-#4999+25.4] | ; Compute the new Z offset by subtracting new tool length offset from old tool length offset and make this the new tool length offset | |
| G53 G0 Z-10 | ; Lift Z rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position | |
| #5000=#4999 | ; Set user parameter 5000 to the value in user parameter 4999 | |
| M0 (MSG,REMOVE MAGNET!!!, Replace Dust Boot, Click “Continue”) | ||
| G0 X0 Y0 | ; Rapidly move to your workpiece X and Y origin | |
| M72 | ; Restore modal states |
The above is Mike’s Bit Setter Macro v2.0, I changed nothing except that I put some g-codes in the preamble to one code per line for more space for the comments.
This bit setter macro assumes that you know which tool Nr. is the bit to be first used in the program, that you mounted it into the collet and secured it with the two wrenches and that you probed or manually set your workpiece Z zero height before starting the toolpath program.*
I can’t test this tool setter routine because I have no machine attached to my Onefinity controller at the moment (waiting for a move). So if you can test it I am sure the forum members will be interested in your report, also I can help you to tweak it. The tool change position (X=780, Y=50) is obiously near the right end of a Wooworker (816 × 816 mm). You can also have your manual tool change position on the left end, by setting it to X=0, Y=0 (which is the machine home).
Part one, for the ‘program-start’ field in the settings page:
| (Runs at 'program-start') | |
| (This is Mike's Bit Setter Macro v2.0 2021-01-13, with comments and different dialogs added by Aiph5u on 2024-03-31 v1.1) | |
| M70 | ; Save modal states |
| M5 | ; Stop the spindle |
| G21 | ; Set metric units mode |
| G40 | ; Turn cutter compensation off |
| G49 | ; Cancel Tool Length Compensation |
| G17 | ; Select XY plane |
| G90 | ; Set absolute distance mode |
| G53 G0 Z-10 | ; Lift Z rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position |
| G53 G0 X780 Y50 | ; Go rapidly to X=780 mm, Y=50 mm in absolute machine coordinates - manual tool change position |
| M0 (MSG, Please connect the touch plate to the controller, place the touch plate underneath the bit and attach the magnet end to the collet of your milling motor. Click "Continue" if you're ready.) | |
| G0 Z10 | ; Go rapidly to a position 10 mm above currently active workpiece Z zero |
| G92.2 | ; Turn off G92 offsets but keep parameters 5211 - 5219 available. |
| F100 | ; Set feedrate to 100 mm/min for probing. (which means slow) |
| G38.2 Z-133 | ; Move the milling motor downwards until the bit touches the touch plate |
| #5000=#<_Z> | ; Set the user parameter 5000 to the current Z position value |
| G53 G0 Z-10 | ; Lift Z to rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position |
|
M0 (MSG, Please remove the magnet end from the collet, remove the touch plate, attach the dust boot and start the router. Click “Continue” if you’re ready.) | |
| G92.3 | ; G92.3 - Restore the G92 offset to the values previously saved in parameters 5211 to 5219 |
| G0 X0 Y0 | ; Rapidly move to your workpiece X and Y origin |
| M72 | ; Restore modal states |
| G90 | ; Set absolute distance mode |
| G17 | ; Select XY plane |
Part two, for the ‘tool-change’ field in the SETTINGS page:
| (Runs at 'tool-change') | ||
| (This is Mike's Bit Setter Macro v2.0 2021-01-13, with comments and different dialogs added by Aiph5u on 2024-03-31 1.1) | ||
| M70 | ; Save modal states | |
| S0 | ; Set spindle speed to 0 | |
| G21 | ; Set metric units mode | |
| G40 | ; Turn cutter compensation off | |
| G49 | ; Cancel Tool Length Compensation | |
| G17 | ; Select XY plane | |
| G90 | ; Set absolute distance mode | |
| G53 G0 Z-10 | ; Go rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position | |
| G53 G0 X780 Y50 | ; Go rapidly to X=780 mm, Y=50 mm in absolute machine coordinates - manual tool change position | |
| M0 (DEBUG, Please remove the dust boot, remove the tool and insert tool Nr. #<_selected_tool> and tighten the collet with both wrenches. Then please connect the touch plate to the controller, place the touch plate underneath the bit and attach the magnet end to the collet of your milling motor. Click "Continue" if you're ready.) | ||
| G92.2 | ; Turn off G92 offsets but keep parameters 5211 - 5219 available. | |
| F100 | ; Set feedrate to 100 mm/min for probing. (which means slow) | |
| G38.2 Z-133 | ; Move the milling motor downwards until the bit touches the touch plate | |
| #4999=#<_Z> | ; Set the user parameter 4999 to the current Z position value | |
| G92.3 | ; G92.3 - Restore the G92 offset to the values previously saved in parameters 5211 to 5219 | |
| G0 Z25.4 | ; Go rapidly to a 25.4 mm above currently active workpiece Z zero | |
| G92 Z[#5000-#4999+25.4] | ; Compute the new Z offset by subtracting new tool length offset from old tool length offset and make this the new tool length offset | |
| G53 G0 Z-10 | ; Lift Z rapidly to Z=-10 mm in absolute machine coordinates - manual tool change position | |
| #5000=#4999 | ; Set user parameter 5000 to the value in user parameter 4999 | |
| M0 (MSG, Please remove the magnet end from the collet, remove the touch plate, attach the dust boot, and start the router. Click "Continue" if you're ready.) | ||
| G0 X0 Y0 | ; Rapidly move to your workpiece X and Y origin | |
| M72 | ; Restore modal states |
DISCLAIMER: I did not test this tool setter routine. Reports and feedback will surely be appreciated by the community.
Mike posted an Updated version on 2021-07-05 which is shown here:
Part one, for the ‘program-start’ field in the settings page:
| (Runs at program start) | |
| (This is Mike's Updated Bit Setter Macro v2021-07-05) | |
| G90 | ; Absolute distance mode |
| G17 | ; Select XY plane |
| #5000=-999 | |
| o10 sub | |
| G53 G0 Z-10 | |
| G53 G0 X780 Y50 | |
| o15 if [[#5000] EQ -999] | |
| M0 (msg, Remove Dust Boot, Attach Magnet, Click "Continue"…) | |
| o15 else | |
| G53 G0 X600 | |
| M0 (debug, Remove Dust Boot, Insert Tool #<_selected_tool>, Attach Magnet, Click "Continue"…) | |
| G53 G0 X780 | |
| o15 endif | |
| G92.2 | |
| G53 G0 Z-70 | |
| G38.2 Z-133 F100 | |
| G0 Z[#<_Z>+1] F100 | |
| G38.2 Z-133 F25 | |
| o10 endsub |
Part two, for the ‘tool-change’ field in the SETTINGS page:
| (Runs on M6, tool-change) | |
| (This is Mike's Updated Bit Setter Macro v2021-07-05) | |
| M70 | |
| S0 M5 | |
| G21 G40 G49 G17 G90 | |
| o20 if [[#5000] EQ -999] | |
| o10 call | |
| #5000 = #<_Z> | |
| G53 G0 Z-10 | |
| G92.3 | |
| o20 endif | |
| o10 call | |
| #4999= #<_Z> | |
| G92.3 | |
| G0 Z25.4 | |
| G92 Z[#5000-#4999+25.4] | |
| G53 G0 Z-10 | |
| #5000 = #4999 | |
| M0 (MSG,Remove Probe, Install Dust Boot, Click "Continue"…) | |
| G0 X0 Y0 | |
| M72 |
Thank you so much for taking the time to address some of the questions that I asked and putting the time into add the comments/messages in Mikes code. I will print this tonight and review in the morning as I work better on paper when I can see it all rather than scrolling. I will also run a small test cut to see what I get with the machine vs what I expected to get and report back.
I will also see if I can map out each of the pockets for the RC-ATC and see if I can map those to the tool number in the gcode.
Thanks again, this is a huge help to get me started on the right path.
I made some progress today with the code for the actual tool change itself and now will work to incorporate into the code that @Aiph5u posted above.
I am not sure if I should always work with the absolute positions for the plunge/lift cycle or should I use relative? Is there a way to make one subprogram that has a conditional for M3 vs M4? I would also love to know if there is a good way to store which pocket is open? Should this be in a permanent common variable/parameter?
Once I get this portion working well and efficiently then I will work on the bit setter/probe code and then work on the rest of the surrounding code that @Aiph5u posted.
M5; stop spindle
#550=31.262 ; first pocket X
#551=207.453 ; first pocket Y
#552=-99; lift height
#553=-133; plunge height
#554=-40; move height
#555=1800; spindle speed
G53 G0 Z0; raise Z to absolute 0
T00; tool 1
M98 P1000
O1000 ; disengage tool
#15=[45.0 * #<_selected_tool>] + #551; selected pocket Y
G53 G0 X#550 Y#15; move to selected pocket
M4S#555 ; turn spindle to reverse
G4 P1 ; pause for 10 sec
G53 G0 Z#553; plunge
G53 G0 Z#552; lift
G53 G0 Z#553; plunge
G53 G0 Z#552; lift
G53 G0 Z#553; plunge
G53 G0 Z#554; lift to move
M5 ; stop spindle M5
M99; back to main program
O1000 endsub;
T01; call for tool 2
M98 P2000
O2000 ; engage tool
#15=[45.0 * #<_selected_tool>] + #551; selected pocket Y
G53 G0 X#550 Y#15; move to selected pocket
M3S#555 ; turn spindle to forward
G4 P1 ; pause for 10 sec
G53 G0 Z#553; plunge
G53 G0 Z#552; lift
G53 G0 Z#553; plunge
G53 G0 Z#552; lift
G53 G0 Z#553; plunge
G53 G0 Z#554; lift to move
M5 ; stop spindle M5
M99; back to main program
O2000 endsub;
M5
Hey Matt,
by the way (I know this does not help you ) I must say that it causes me really pain each time to see the RapicChange-ATC system in use. Do you really engage the collet nut thread at 1800 rpm? I don’t know if this is free of harm for the spindle and the thread. With my Omron MX2 (aka Hitachi WJ200), I can deliver full torque at 6 Hz (180 rpm). Can your VFD go that low and still deliver torque?
I prefer not to have ATC as long as I don’t have the money for a spindle with HSK tool holders. I will have to remain satisfied with owning the HFS-8022-24-ER20 so far. Okay, a HSK25 2.2 kW spindle like the ATC-8022-30-HSK25 30000 rpm is at over €6000 and a ATC-8022-42-HSK25 42000 rpm at over € 6800, and there isn’t even the cables included and neither the VFD nor the control cabinet. Even a chinese Jianken JGL-80 2.2KW 24000 rpm ATC spindle with older ISO tool holder technology is at $1450. But I think this is the best way to have ATC, if you look at the HSK25 system spindle in action.
So with a complete professional ATC system from a German manufacturer you are easily at over $ 10 000, and at least at $ 3 000 for a chinese system. What does one have to pay for a RapicChange ATC system? Of course it does not include buying a spindle because you can remain using your old non-ATC-spindle.
This is possible. You can write a value into a user parameter and later compare it to another number or expression with EQ (equal), NE (not equal), GT (greater than), GE (greater or equal than), LT (less than), and LE (less or equal than). Boolean operators are also possible (AND, OR, XOR) You enclose this into a if…elseif…else…endif conditional branch and call two different “o code” subroutines accordingly.
Ah yes, I know it causes you pain and you have posted about this in other threads, but for the $250 that it cost me it is an easy decision for my hobby setup. Even if I have to replace a spindle at some point it will be far cheaper and simpler than a pneumatic ATC. Even if it mars up the collet nuts, I can purchase those cheap. I simply cannot justify that cost when this is just a machine for my personal projects and there are other tools I still need to buy for my workshop. So this the path I am venturing down to explore and see what the OF with a BB controller can do.
I tried the spindle spinning as low as 600 and there is not enough torque to tighten the collet nut sufficiently. Now that I have it aligned and functional I will continue to tune this and see how low I can drop the RPM.
Any advice on the absolute vs relative coordinate system for what I am working on? I am getting confused on what coordinate space I am in and how to best control the machine.
Do the subprograms need to be located in a particular spot (program start vs tool change), or can they be anywhere? I am used to programming where I put all my declarations and functions at the top listed once and then call them as needed. Is Gcode the same?
OK, so rather than passing a variable into a subprogram, I will just store that as a user parameter to access when the subprogram runs. Thank you for the links, I will see if I can get this working. I am also going to see if there are “for loops” that I can use to make the code even more efficient.
I truly appreciate all of the help that you have provided and I will post back here with my progress.
Hey Matt,
Wow, that is really not much money compared to a pneumatics ATC system.
I can understand that very well. I think being able to do something, even without a lot of money, is worthwhile. Personally, I’m just too uncomfortable with how this RapidChange system works (the fact that I spent about 1500 EUR on my spindle and a set of ER20 collets together may also contribute to this ) But I am far from turning up my nose at a system like the RapidChange ATC. If you want to get something baked, you take what you have – better than baking nothing. My situation is similar, yet I couldn’t afford the pneumatics ATC, my solution at the moment will remain the two wrenches
I think many people here will appreciate that you share your experience with this system here and that you post the code necessary to run it.
Please feel free to ask more questions if I may help you with g-code, it just could be that I have a little less time for the next three days because of the many things I have to do. I will have more time from Thursday on.
Yes, just like in other programming languages, the subroutines you call must have appeared before they are called. So if you assume that ‘program-start’ field is always read first, you can put all your subroutines there at the beginning. Just be aware that in a subroutine you have to consider that different modes could currently be active, and what modes should be reset or active at the return from the subroutine if you changed them inside the subroutine. But I think you know that already.
You can check whether you are in absolute or incremental mode by asking these parameters:
#<_absolute> - Return 1 if G90 is on, else 0.
#<_incremental> - Return 1 if G91 is on, else 0.
Note that G53 (Move in machine coordinates) will fail silently on the buildbotics controller if it is used while the incremental distance mode (G91) is active. This is a bug. G53 makes no sense when used in incremental mode because G53 means absolute machine coordinates. Usually it should output an error when used while in incremental mode. If you don’t know in which mode a subroutine will be called, you can always prepend a G90 in front of a G53.
Choosing incremental mode (G91) makes sense if you want a motion to be relocatable, i.e. if it should move by the same distance no matter where your starting point is. On the other hand, if you are in absolute distance mode (G90), you can move to a position that is always the same in relation to your workpiece zero / currently active offset origin. In both modes, you can have the disadvantage that either your incremental distance move is too big, or your active offset is shifted by a sufficient amount, so that it triggers a limit error. This of course can be solved by sophisticated computations of allowed move that consider current position by reading out the absolute positions parameters and including them in the computation (that is what my ‘tool-change’ routine still lacks to be limits-error-proof, due to lack of time and lack of an assembled machine ), or by using G53.
Hey Matt,
Shit, another not supported LinuxCNC parameter on the buildbotics-derived Onefinity Controller. This does not work on my 1.0.9. Does this work on a subsequent firmware version?
o10 sub
o15 if [#<_absolute>]
(debug, Absolute mode is on)
o15 else
(debug, Absolute mode is off)
o15 endif
o10 endsub
o20 sub
o15 if [#<_metric>]
(debug, Metric Units mode is on)
o15 else
(debug, Metric Units mode is off)
o15 endif
o20 endsub
; main
M70 ; Save all modal values
G90
o10 call
M0
G91
o10 call
M0
G21
o20 call
M0
G20
o20 call
M0
M72 ; Restore all modal values
check_for_incremental_and_imperial_mode.ngc (409 Bytes)
The parameters #<_metric> and #<_imperial> work, but not #<_absolute> and #<_incremental>.
I already found out the other day that #<_abs_x>, #<_abs_y>, #<_abs_z> are not supported by the buildbotics-derived Onefinity Controller. I use [#<_z> + #<_offset_z>] as a workaround for #<_abs_z>.