Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: massynrt on January 10, 2025, 03:33:47 AM
-
Hi everyone - I thought to share this - Since I believe it is impressive. I tried to upload the photos, but cant seem to.
I build my own Auto Tool Changer with a n pneumatic tool rack. 10 Tools. The biggest challenge was the dust shoe. I decided to make a spot where I can park the dust shoe. You will see it on the photos.
The dust shoe top section (Attached to spindle), Bottom section (Brushes) and the parking spot holder where all 3d printed - If you want this models let me know - I will Glady make them available.
The CNC is a basic Chinese version that I bought and upgraded. Im running a Pokeys 57 CNC. I bought a ATC Spindle on AliExpress. I do agree this might not be the best on but because of budget and production time I'm willing to upgrade this is the future. The cost of the Spindle is only a small part of the whole solution. The programming time, tool rack. Pneumatics all add up and I had to spend my budget wisely.
M6 - Tool Change Macro
m110 - Toggle Draw Bar On Spindle (Output 2 - Set to relay2 Pokeys)
M120 - Toggle Tool Rack (Output 3 - Set to relay1 Pokeys)
M1005 - Fixed probe on bed to measure tool length and update Tool Table
M1010 - Normal Z probe to measure material Height.
The M6 macro is where all the magic happens.
I used the sample scripts to access to ToolRack database as created in the scripting Tutorial. Just a bit adjusted. I added a field for what tool is loaded. Look at the .csv in the modules folder.
Slot, Tool Num, X,Y,Z
I also make use of Mach4 Tool Database for length offsets.
This way I can load tool 23 as an example into slot 1 if I want to. Not limited to only 10 tools. Just update the CSV with your changes. I'm busy writing an editor for the CSV into the Screen. Not yet completed.
Keep in mind all ATC G00 and G01 happen in G53 (Machine).
First step is to park the Dust shoe.
Whenever M6 is called the Macro checks if a slot is allocated for the Current Loaded tool. If Not, it goes into a Manual Tool Drop Mode otherwise it will proceed to store the tool in the tool rack.
If no tool is currently loaded, the macro moves on to Loading Section.
On Loading, Same rule applies - If the requested tool is not configured in the tool rack, the macro goes into a Manual Loading Mode. If the tool rack is configured and loaded with the correct tool t he macro will go ahead and load the tool.
Pick Up the Dust Shoe.
If the select tool length is set to 999 in the tool database, the M6 will call m1005 to re-measure the tool length and update tool database. Useful for tool breaks or something. All Manual Tool Loads will be re measure.
Once done, the tool length offset is applied. And G00 back to where the M6 was called.
If M6 T0 (Unload tool) was called, M6 will clear tool offsets and park the Spindle at the dust shoe after the loaded tool was stored. It Will not move back to original position. This works for me as my bed is accessible and no tool loaded. Got practice at the end of each job.
Future plans are to input my VFD and Water signals into the pokeys for safety. Spindle should never start without water. And Drawbar should never release when VFD are running.
Please keep in mind this is very custom, but I do believe it is easy to configure for your own use. I tried to add a lot of comments to explain the M6.
I hope someone finds this useful or errors/suggestion. Send me a pm and I will forward you my email.
-
Holy smokes! This is impressive. Thanks for sharing.
Steve
-
Thank you -
I've already updated this.
I've redesigned the screen to show a table of the tools loaded and an indicator to show what slot/tool is loaded. I dont like tabs on the screen. I want all the detail I need on 1 page.
The ATC rack can also be configured from the screen now. No need to go dive into the CSV anymore - Only when XYZ of the tool rack might ever change - But tool # can be updated from the screen. Improved the database/CSV function.
I think I should make a google drive folder and put all the STL Models, images, videos and code there. That might be useful to some in the future.
-
https://drive.google.com/drive/folders/14xmjPPC4rwQ_XFNLGm2_F2rf4nqgs-zI?usp=drive_link
Here is the share to the photos, video, stl and code.
-
Very nice.
I will need to really look this over and see what I can improve on mine.
thanks for sharing.
Bill
-
And please feel free to give me feedback on what I can improve too. I would love this to be a help for everyone building their own. Some info I might need to add-
1. My implementation for tool length offset is based on the fact that I dont use a master tool - I'm sure it will still work - I rather think of my Spindle's bottom as the master tool - All my tool lengths are calculated from that point. The total length incl the tool holder from the spindle. As long as the correct tool offset is applied when you probe or home the Z home, everything is perfect.
2. I use a X Box controller - My Z probe is used with a macro that I've assigned on a bottom on the Xbox Controller. That is why I removed it from the screen. I want to be at the machine when I probe, not at the PC.
-
Oh do I wish we would have found each other about 8 months ago!
I have been working on a VERY similar set of modules, macros, scripts and whatnot to integrate a carousel style toolchanger. It would have been great to compare notes.
I'm in the final integration/debugging phase now so it is probably too late for me to use much of your efforts. I haven't done anything with the tool table/database however. I saved that for last.
One consideration with respect to the tool table: I have been making great use of the Gwizard software and plan to make the tool library the "master". Then I could just use some scripting to sync the tool tables between them. Let me know if this makes sense. I too was planning the Mach4 tool table to be a subset of the master table and able to be reconfigured. (load tool#18 into carousel slot 3 for example). I'll probably adapt your work for this.
My plan was the following:
My tool carousel is also 10 slots. Slot/tool 0 is "No Tool" (empty spindle). This is so that I can remove the tool from the spindle without an additional function. I have designated slot 11 for my renishaw probe (it has a cord to plug in so it needs to be loaded like a manual tool). Slots 12-20(?) are "manual tools". These will probably be loose mills/drills that are not living in a dedicated tool holder but existing in the tool table to keep track of speeds/feeds/etc... This way I can call them in the CAM software. Tools beyond 20 or so will exist only in the "master" tool table and would need to be entered on a case-by-case basis (maybe manually?)
I have a few specific questions about implementation:
I plan to use a number of different CAM/post processors until I find the one that works best for me. Currently I use Aspire/Carve3d but as I migrate to using 5 axis, I will need to go to SolidCam or MasterCam. Which of the tool table entries are necessary for the post processor to know? I know that for 5 axis work, the exact tool length is important for calculating the inverse kinematics.
Is there a standard(ish) format for tool tables that has at least been adopted by a few software packages? I'm hoping that there is a "least common denominator" csv file format that I can find that will work with all of these packages. Gwizard also can output a binary .dat file for Mach3 but it looks like more of a pain to work with.
Thanks!
-
I'm going to give this a shot - Im not as much as an expert as I would like to believe.
I think it is important to really understand how you want your system to work - There are a few different systems at play - I'm going to explain my implementation, and hopefully I can answer your questions.
Firstly, you need to define ToolIDs to your tools. I suspect this is your master db you are referring too. The post processor only knows the tool number. The PP does not manage tool length or diameter offsets.
I cant imagine for 5 axis work it would make a difference, since the tool length offset will be applied by the controller. I've never dont 5 axis work - But I'm sure there would be a Work offset procedure and then length offsets will be applied.
What you have to do, either in your PP or in my case in the M6 macro is, you have to apply the tool length offset from the MACH4 tool database. G43 H[tool number]. I'm sure you would be able to make use of your own database but then you will have to manually set the offsets - If you make use of MACH4 build in tool database, you immediately get access with on API call to apply to offset. It is also very easy to update the DB via probes etc. I would highly recommend you go that route.
The way I implemented it, was not to open the tool table every time. Once it is set up, you can forget about it basically - Only when I break a bit or want the bit length to be measured again, I open the tool table, change the length to 999 and my M6 macro will measure it again. I can always add extra check boxes or something for this - This was just an easy way to achieve the outcome.
Tool changes require two steps -
1- Physically loading the tool.
2 - Loading the offsets via G43
I have 10 slots also. I dont think of Tool 0 as empty spindle. M6 Macro is scripted in a way to unload, and if selected tool is 0, dont load next tool - Clear the offsets.
Im sure engineering companies that use large bits that resharpen them will also make use of diameter offsets. I dont care for them since I only cut Signs and Cabinets.
The only other real consideration is what you consider as Home Z 0. Some people call this the master tool. This can get a bit confusing. For me this is the bottom of the spindle, without any tool loaded. So basically - If I probe my z height with tool 1 loaded in the spindle and Tool Length 1 Offset applied. HomeZ is then 0. If I unload the tool and clear the length offset, the bottom of the spindle will actually be the Z0 point without the offset applied. Thus you can probe with any tool, change any tool and the offsets will make sure the Z height is correct.
I have 2 cvs database files for my tool rack.
1. One to assign the X,Y,Z position to the tool rack slots.
2. Second To load specific tools into specific slots. This can be random. I can load tool 94 into slot 5 if I want to.
Thus - Dont limit yourself to 1-10 as ATC, and 12-20 as manual - It can be anything you like - Anyway you would like to setup your Master Tool DB.
Tool ID's need to to be the same across all CAMs. In my case I use 2 CAM software apps. Vectric V Carve and Mossaik Cabinet. Both have their own build in tool databases. These databases are responsible for the speeds and feeds for each Tool ID, for each material, for each process etc etc.
You just need to make sure that the tool numbers align between Vectric, Mossaik, MACH4 tool table. For me, this is once off setting thus I did not feel the need to program scripts for this. Will only be done once. The only changes left is when I change a tool in the rack, to update the loaded tool CSV.
I've added some extra code to M6 to go into manual mode when a toolID is not available in the rack.
Then your 2nd questions - From what I've gather - There are NO standards. Every company building an ATC mill or something does it they why they want. Some of the Gcode are standardized but that is about it. I'm sure large companies like Tormach have standards between their machines - But that is above my pay grade..
Hope this helps.
-
Haha that’s great. Way easier than i thought.
Ok. I keep the tool master tool database flexible (have all tools there, arbitrary numbering). I would have to assign the tool slot number to the tool in vectric/pp? then? Because otherwise there would need to be a lookup table or something in mach that would know that ‘tool 23’ is loaded into slot 4 or whatever. Or is that exactly what you added for your implementation.
-
Because the PP needs to know what tool number to include in the M6 call each time…
-
That is exactly what I added - The 2nd CSV file - What tool is loaded where. Bascially the tool rack setup.
The tool table in MACH holds the tool ids with the length offsets.
-
Gotcha. So then your m6 uses the tool number from the PP to access the tool slot number. Nice approach.
That may not be possible for me because my tool changing is spread out over a number of functions. I think i use ‘current tool’ and ‘selected tool’ too much in sub functions to save the trouble of passing tool numbers. Maybe not though. I’ll investigate!
-
I just want to add a comment for clarification for other users that might read this -
PP (Post Processor) is loosely used but it refers to the CAM Software that generates the GCODE - The post processor's function is to convert the calculated tool paths to specific gcode for a specific implementation. Not all CNC machines uses the same gcode - The post processor is the layer in-between.
Im sure if you just review your code, you would certainly optimize it a bit - All gets cleared once you have a good plan of how you want to do it. What works for your workflow. That is the beauty of MACH4 - Nobody is forced to do it a certain why - I removed so many functions that I dont use because I like a clean simple smart interface.
-
I think i can probably use this idea. One question: does Mach4 copy the mc.mcToolSetData values into the tool table or just use them for the current gcode file/modal execution/whatever the "non persistent" lifetime is? It looks like some of the values go into the tool table but the API doc doesn't say explicitly.
Before I go and make changes to my code, let me try to explain the "standard" tool change flow as I understand it and you can correct me:
-CAM SW needs to change to tool "3"
-PP passes this Change to tool 3 command to the G code as T3 M6
-When Mach4 reads the T3, the selectedTool becomes "3"
-The M6 macro uses the currentTool (mc.mcToolGetCurrent) and the new selectedTool (mc.mcToolGetSelected) to direct the tool changer
-Before the current tool is removed, the tool is measured and this value is saved somewhere temporarily
-Current tool is replaced
-New tool is grabbed
-New tool is measured using toolsetter, difference between old and new tool lengths is applied somehow
-Tool offset is changed or Z height is modified to accommodate new tool
-Cutting resumes
So there appear to be a couple of methods that I have seen people use to apply the difference between old and new tools. Some scripts simply change the Z height immediately after measuring the tool so that the tool tip's Z height is the same as the previous tool. Others
(I believe yours) use the tool height offset instead.
As I will be migrating to 5 axis as soon as I get my machine dialed in, I think the tool height offset (which is stored in the tool table?) is a better option. The whole reason I have a toolchanger is because Mach4 can do 5 axis motion but not the 5 axis inverse kinematics necessary to recompute the toolpath for different tool length offsets, so I needed a way to have stable tool lengths that could be used in the 5 axis CAM and not need to be recalculated every time I change a tool.
Are there any "gotchas" about using the tool offset? In my previous machines without tool changers I never used it.
-
5 Axis I have not touched - I'm only assuming how it will work, based on what I know from the basic setups. Regarding this:
-CAM SW needs to change to tool "3"
-PP passes this Change to tool 3 command to the G code as T3 M6 ( Remember your spindle stop as part of the PP - M05)
-When Mach4 reads the T3, the selectedTool becomes "3"
-The M6 macro uses the currentTool (mc.mcToolGetCurrent) and the new selectedTool (mc.mcToolGetSelected) to direct the tool changer
-Before the current tool is removed, the tool is measured, and this value is saved somewhere temporarily. I dont see the need to measure to tool afterwards - Is this a requirement for 5Axis? Or just to make sure it is within spec? Not Broken? I would much rather measure it before I start cutting ...
-Current tool is dropped - Offsets cleared -
-Selected tool is grabbed
-New tool is measured using tool setter, difference between old and new tool lengths is applied somehow. - This is not correct - Theory yes, practically no.
The correct way to think is - The Length offsets are clear - G49. And the new tool offset is applied G43 H3. You don't calculate differences. This is done for you. You only need to concern yourself with the length of each tool.
-Tool offset is changed, or Z height is modified to accommodate new tool.. I would advice to only use tool offsets - It removes the thinking and makes the process simple.
I will take a moment and try to explain G43 and G49 a bit better - Just for future readers also.
Remember there are Machine Coordinates and Work System Coordinates - G53 Machine - G54 Work Coordiante System (WCS) as an example.
Assume you have no tool loaded in the spindle, and you do a Z probe to get the top of the material. The G54 Z position is set to 0 But the G53 position will be whatever to actually value of the machine is from HOME position. Lets assume it is -100mm for this examples.
Now - You load a tool into the Spindle - The tool length is 50mm. IF you don't apply any offset, the tool will cut 50mm too deep. When you apply to offset, the G53 value will move up -50mm and the bottom of the tool will become Z0 on your G54 WCS.
Once you've done the job and G49 is called - Offsets Cleared - then suddenly the bottom of the spindle will be G54 Z0 again. So on and So on. When you load the next tool, the whole process repeats itself.
The amazing thing about tool offsets is, the apply to probing also. I can probe with a tool offset applied. And if I remove the tool, and clear to offset - The spindle will once again be the Z0 G54 position.
-
5 Axis I have not touched - I'm only assuming how it will work, based on what I know from the basic setups. Regarding this:
-CAM SW needs to change to tool "3"
-PP passes this Change to tool 3 command to the G code as T3 M6 ( Remember your spindle stop as part of the PP - M05)
-When Mach4 reads the T3, the selectedTool becomes "3"
-The M6 macro uses the currentTool (mc.mcToolGetCurrent) and the new selectedTool (mc.mcToolGetSelected) to direct the tool changer
-Before the current tool is removed, the tool is measured, and this value is saved somewhere temporarily. I dont see the need to measure to tool afterwards - Is this a requirement for 5Axis? Or just to make sure it is within spec? Not Broken? I would much rather measure it before I start cutting ... Not a 5 axis requirement to my knowledge, This flow originally came from manual tool changing I think when the script I was looking at didn't use offsets but instead calculated the difference. Using offsets and maintaining an absolute reference is a much better approach.
-Current tool is dropped - Offsets cleared -
-Selected tool is grabbed
-New tool is measured using tool setter, difference between old and new tool lengths is applied somehow. - This is not correct - Theory yes, practically no.
The correct way to think is - The Length offsets are clear - G49. And the new tool offset is applied G43 H3. You don't calculate differences. This is done for you. You only need to concern yourself with the length of each tool.
Excellent. This is a better way to think about it I work in the semiconductor industry and the precision needed there is only possible through many many corrections to original absolute machine readbacks. This fits better with my way of thinking :)
-Tool offset is changed, or Z height is modified to accommodate new tool.. I would advice to only use tool offsets - It removes the thinking and makes the process simple.
I will take a moment and try to explain G43 and G49 a bit better - Just for future readers also.
Remember there are Machine Coordinates and Work System Coordinates - G53 Machine - G54 Work Coordiante System (WCS) as an example.
Assume you have no tool loaded in the spindle, and you do a Z probe to get the top of the material. The G54 Z position is set to 0 But the G53 position will be whatever to actually value of the machine is from HOME position. Lets assume it is -100mm for this examples.
Now - You load a tool into the Spindle - The tool length is 50mm. IF you don't apply any offset, the tool will cut 50mm too deep. When you apply to offset, the G53 value will move up -50mm and the bottom of the tool will become Z0 on your G54 WCS.
Once you've done the job and G49 is called - Offsets Cleared - then suddenly the bottom of the spindle will be G54 Z0 again. So on and So on. When you load the next tool, the whole process repeats itself.
The amazing thing about tool offsets is, the apply to probing also. I can probe with a tool offset applied. And if I remove the tool, and clear to offset - The spindle will once again be the Z0 G54 position.
So I currently have upper and lower limit switches on my Z axis (again, lower is only necessary when in 5 axis mode when the spindle is effectively pointing sideways. I currently use the upper limit switch as the home switch as well. This puts 0 up at the top and the bed is something like -380mm. I was considering configuring Mach4 to move the home switch to +380 (or whatever) so that I could more easily work in machine coordinates doing my configurations and jigs and things. Is there any reason that I shouldn't use the master tool (a stainless stepped shaft I have loaded into a spare tool holder) to set the actual machine Z0 to the tool touching the table? Purely to make checking my calculations and positions easier, I realize that it probably isn't necessary.
Maybe I have
-
I read a post once, or a video - I cant remember - But the general idea is - For standardization and good practice - Is to keep Home 0. Always. Doesn't matter if it is x,y,z. And the regarding the z Axis, I also tried it once to have the Bed zero - The problem is, the bed changes over time as you work. This is not a good setup. The Top does not where you put the home sensor. I do think it is better just to keep Machine Coordinates G53 -ZHome 0 (Top) and work down from There into, - values. This makes sense when working simply because - when you probe the material - for me that is - the top - When I see a Z -5 I know how deep I cut into the material. Basically, It will not matter either way on your workflow, because you dont use G53 when you cut stuff - You work in G54 which is 0,0,0 to your workpiece.
Then regarding the master tool - I'm open for input but I dont see the need, as this is an extra step for me that adds no value. Because I can use any tool, which length is known, and offset applied to probe the Z. I assume this will work the same in 5 axis, if you need to probe the side of material. I dont know if it works that way.
-
I taught ChatGPT to understand how to write the lua for Mach 4 and I discovered that the "pocket #" entry in the tool table is actually meant to be the SLOT number of the auto tool changer. We have re-implemented a feature already existing in Mach... here is what it said:
-
The **"Pocket #" (Pocket Number)** in the **Mach4 Tool Table** refers to the **physical slot** or **location** in the machine's **tool changer** where the tool is stored. This is commonly used for machines equipped with an **Automatic Tool Changer (ATC)** or a **tool carousel**.
---
### **How "Pocket #" Works**
1. **Tool Number vs. Pocket Number:**
- **Tool Number**: A logical number assigned to each tool, which represents its identification in the tool table. For example, Tool #1 might be a 10mm end mill, and Tool #2 might be a 5mm drill.
- **Pocket Number**: The physical location in the ATC or tool magazine where the tool is stored. For instance:
- Tool #1 might be physically stored in Pocket #5.
- Tool #2 might be physically stored in Pocket #3.
This distinction is necessary for machines that decouple the logical tool numbering from the physical storage locations.
2. **Why Pocket Numbers Are Important:**
- They allow the machine to know **where to find the tool** during an `M6` tool change.
- The machine can swap tools efficiently by mapping the **logical tool number** to the correct **physical pocket**.
3. **ATC Workflow:**
- When the machine executes a tool change (e.g., `T1 M6`):
1. It looks up the **Pocket #** associated with Tool #1 in the tool table.
2. It retrieves the tool from that pocket in the tool changer.
3. The tool is loaded into the spindle.
---
### **Example Tool Table**
| **Tool #** | **Description** | **Diameter** | **Pocket #** |
|------------|-------------------|--------------|--------------|
| 1 | 10mm End Mill | 10.0 | 5 |
| 2 | 5mm Drill | 5.0 | 3 |
| 3 | 6mm Ball Nose | 6.0 | 1 |
- **Scenario:**
- When `T1 M6` is executed, the machine looks for **Tool #1** and retrieves it from **Pocket #5**.
- When `T2 M6` is executed, it retrieves **Tool #2** from **Pocket #3**.
---
### **Pocket Numbers on Manual Machines**
For machines **without an ATC**:
- The "Pocket #" might not be relevant, as the operator manually loads the tools. However, some operators use the Pocket # field to define storage locations (e.g., tool racks or cabinets).
---
### **Configuring Pocket Numbers**
In Mach4, the Pocket # field can be edited in the **Tool Table**:
1. Open the Tool Table via the Mach4 menu or screen.
2. Find the "Pocket #" column for each tool.
3. Enter the correct pocket number corresponding to your machine's ATC.
---
### **Key Points:**
- **Pocket # is essential** for machines with an ATC to ensure proper tool management.
- If your machine doesn't have an ATC, the Pocket # can be left blank or used for operator notes.
Let me know if you'd like help configuring your tool table or understanding tool changer workflows!
-
Now I'm curious to see how to use the built-in functionality! I'll investigate and report back :)
-
OK, it wrote me the following M6 script that basically uses the pocket number that is referenced to the tool #. I like this alot. super minimal and streamlined.
function m6()
local inst = mc.mcGetInstance()
-- Get the selected tool and current tool
local selectedTool = mc.mcToolGetSelected(inst) -- Tool requested by T# command
local currentTool = mc.mcToolGetCurrent(inst) -- Tool currently in the spindle
-- If the selected tool is the same as the current tool, no tool change is needed
if selectedTool == currentTool then
mc.mcCntlSetLastError(inst, string.format("Tool %d is already loaded.", currentTool))
return
end
-- Get the Pocket # for the selected tool from the Tool Table
local pocket = mc.mcToolGetData(inst, mc.MTOOL_POCKET, selectedTool)
if not pocket or pocket <= 0 then
mc.mcCntlSetLastError(inst, string.format("Error: No pocket assigned for Tool %d.", selectedTool))
return
end
-- Display a message about the tool change
mc.mcCntlSetLastError(inst, string.format("Changing to Tool %d from Pocket %d.", selectedTool, pocket))
-- Move to a safe position for tool change
mc.mcCntlGcodeExecuteWait(inst, "G90 G53 G0 Z0") -- Move Z-axis to machine home (modify as needed)
mc.mcCntlGcodeExecuteWait(inst, "G90 G53 G0 X0 Y0") -- Move to tool change position (adjust coordinates)
-- Simulate tool change logic
-- If you have an ATC (Automatic Tool Changer), you would insert code here to control the ATC
-- Example: Send commands to move the tool changer to the correct pocket and load the tool
mc.mcCntlSetLastError(inst, string.format("Loading Tool %d from Pocket %d...", selectedTool, pocket))
-- Set the selected tool as the current tool
mc.mcToolSetCurrent(inst, selectedTool)
end
if (mc.mcInEditor() == 1) then
m6() -- Execute the function if running in the Mach4 script editor
end
-
I did not see the Pocket# . I enable the additional fields - And there it was. Obviously, there is no M6 functionally in Mach to use this in a custom ATC. This is only a column in a DB. That can store the pocket if the tool is loaded. You would still need a DB to store the Pocket X,Y,Z etc.
I will give this a day or 2 to brew in my head if I want to go that way. If there is an easy way to "search" the tool table to get all the tools with a pocket value assigned I might use it. My gut tells me I will stay with my own DB. I would like to visualize my tool rack. If that makes sense. But yes, definitely worth looking into. I would prefer to assign tools to pockets, and not pockets to tools.
-
I wonder if I can get the tool number from a script, if I provide the pocket#. That would make it worth it form me ... let me go try ....
-
I will be able to adjust my screen script, to scan the tool DB and update my screen to show me the loaded tools in my rack. Will tweak the scripts slightly to update the pockets. Should work great!! Thanks a mil for pointed out the pocket.
-
My next step will be to make an editable tool table tab that shows the 10 tools loaded into the carousel
-
On it already . hehe
-
Luckily for me this makes things super easy because I can now just use the pocket # instead of the tool# in all of my functions for the toolchanger (my carousel tool changer functions had tool# mapped to carousel positions 1-10 previously, so I change 2 lines of code and it all works as intended! super lucky!)
-
Yes, that screen was basically a cut and paste of yours with some mods :)
-
chaztGPT also gave me some code to recreate the actual editable tool table window in a tab but I haven't tried it out yet. That's where this all started.
-
You screen looks impressive - We will all be out of jobs one day.. thank you AI
-
That screen is 100% my own manual coding, actually. I can’t quite get chatgpt to write gui code that works.
It only appears to work with standard lua and machine controls.
I had to change the screen layout to fit 16:9 but didn’t want to lose all the new real estate so i had to redo alot of it. If you edit the xml file instead of use the screen editor gui it is alot faster and easier to organize. I can share my screen with you if you like but it is super custom to my machine build
-
I've uploaded my update versions to google drive:
Changes made:
1. Added a check in the M6 macro to make sure spindle is off before the draw bar release.
2. Hard coded my rack positions into my M6 macro - Since this is very custom, I don't see the need to make use of .csv files. Can just as well edit the script.
3. Implemented to tool table pocket field.
4. Updated the screen script to use be able to update the loaded tools. Sort of a work around implementation - Not optimized at all, but not needed to be perfect.
-
Cool.
I have a tab and script that populates a screen with the current tools loaded in each slot (editable), their descriptions, an editable ‘notes’ section, the offset and a ‘clear offset’ button which sets the offset to 999.999 to trigger a re-measure.
One of the downsides of being 30 miles away from your cnc is that it is easier to fiddle with software than it is with the hardware. Thus things get prettier than that they need to be. :)
I’m still looking for a way to get the tool table to launch in a tab because the current pop up window is super tough to deal with using a touch screen. (It is basically impossible to drag windows around to see things).
-
If I may recommend - Use the tool table only as a backend system. Write your own edit window - Like your doing now - Lets say you want to edit tool 13 - You type it in, load the info from the tool table, edit the info. save.
I like your reset button..
-
Good idea for the tool table.
I will have my new friend chatGPT write a script to load/sync the tls tool library from Mach to the CSV-based tool crib that is used for Gwizard and post it here for folks to use for themselves. The code it writes is often "too clever for its own good" and uses really complicated methods when something super simple would work instead. It should work great for something like this though.
I think this is why it has a hard time with the GUI scripting. I think that not all of the wx controls have been implemented in Mach, and there's no way for chatGPT to know which are implemented. It would be really nice to have it build the tables for you. I end up manually cut and pasting (lots of find and replace) the XML to get the screens I want.
Speaking of, here is the setc for my tool carousel tab. The scripts for populating the entries are also in there.
I've also included a screenshot of how it looks like.
-
Apparently I can't attach a setc file,
Here is the file as txt....