Tool Measurement Macro - Help Requested

    I am working to fully understand the macro.cnc from Sorotec and translate version (2.1e) to english in the process. I am trying to fully explain each line using comments and I am completely tripped up in the tool measurement sub routine (sub user_2).


    I am referencing Schallbert 's amazing website on macros and there seem to be some extra lines in the Sorotec version I want to understand.


    Can someone help me understand how the machine knows the probe measurement (#5053) without issuing a G92 command at the sensor trigger point?


    Specifically, why does the machine move to safeZ and then do the measurement calculations:

    IF [#5067 == 1]

    G53 G0 z[#4506]

    #[5400 + #5016] = 0

    #[5500 + #5016] = 0

    #5021 = [#5053 - #4509]

    msg "Tool Length = " #5021


    IF [#3501 == 1]

    #4502 = [#4501]

    #4501 = [#5021]

    #3502 = [#4501 - #4502]

    G92 Z[#5003 - #3502]


    Here's the whole code from after the machine is moved to the sensor:

    No Idea if it is correct, but here is what ChatGPT answers to your question:


    It looks like the machine is using a probe measurement to calculate the tool length and then using the G92 command to set the zero point for the Z axis.

    The probe measurement (#5053) is taken at some point before the G92 command is issued. The probe measurement is then used to calculate the tool length (#5021) by subtracting the probe trigger point (#4509) from the measurement (#5053).

    The machine then moves to a safe Z position (presumably above the workpiece) using the G53 G0 z[#4506] command. This is likely done to ensure that the tool does not collide with the workpiece while the zero point is being set.

    After moving to the safe Z position, the machine sets the zero point for the Z axis using the G92 command. The zero point is set by specifying the current position of the probe (#5003) minus the calculated tool length offset (#3502).

    This allows the machine to take into account the length of the tool when making future movements in the Z axis. For example, if the tool is longer than the probe trigger point, the machine will move the tool closer to the workpiece to compensate for the extra length.


    I am so blown away by this AI tool, that I just wanted to let you know about it and try it for your own learning experience with GCode and programming. It just recently helped me to dive deeper into linuxcnc programming and I reached a detail level within days that I would normally have learned over months.


    I hope this helps,

    Tom.

    Ha that is amazing coincidence. I recently messed with AI gcode a few days ago when ChatGPT went public, but never even thought to mess with it as I sat working on this code the last 2 days.


    It seems to restate the macro in plain terms, which is great for learning but doesn't exactly explain when the #5053 is recorded. I'll still take your lead and see what it comes up with for some other macros I've been thinking about. Maybe I'll even see if it could've done all the translation for me if I can handle the shock ^^

    Zitat von TomR

    I am so blown away by this AI tool, that I just wanted to let you know about it and try it for your own learning experience with GCode and programming.

    The technology is pretty close! It is very similar to our CNC machines; it will operate precisely according to commands, in this case how the question is asked. I needed to rephrase my question a few times, but I'm still impressed with it:


    pasted-from-clipboard.png

    Hey tdawg,

    Zitat von tdawg

    Can someone help me understand how the machine knows the probe measurement (#5053) without issuing a G92 command at the sensor trigger point?

    That's easy - it is because EdingCNC developers decided to hard-code a set of variables (including this one) internally to always reflect probe position. They also made it write-protected. You can find this information in the handbook, p.136pasted-from-clipboard.png


    This also explains why the tool tip doesn't have to touch the probe at the point in time when the calculation is made and saved to an internal variable.

    Believe me, I had to work through the whole array of variables in that handbook to finally understand the macros ;), on my Website I tried to note down the simplest possible method to do things.


    If you find anything that I might have overlooked, please let me know; it makes sense to have well-written macros that are easy to follow.


    Regards,

    Schallbert

    Zitat von Schallbert

    That's easy - it is because EdingCNC developers decided to hard-code a set of variables (including this one) internally to always reflect probe position.

    So does the G38.2 update this value on the backend when #5067 (probe triggered) is triggered? The manual says #5067 is 0 unless triggered to 1, so just want to confirm my interpretation. This would be easy to watch if I had a machine with me, but I am left to work this out in simulation mode and my monkey brain while I am away.

    Code
        G53 G38.2 Z[#4509] F[#4504]     ; Probe Z to sensor height with Probe Feed #4504

        IF [#5067 == 1]                 ; Sensor is triggered

    I don't have any improvements to suggest on your code, it is already very easy to understand. Do you think I could remove the tool table recording from the Sorotec macro since I use a normal collet?


    I actually thought you work for Sorotec! Do you host any of this on Github? I am looking to start keeping mine there for version control and availability.

    Hey tdawg,

    Zitat von tdawg

    o does the G38.2 update this value on the backend when #5067 (probe triggered) is triggered?

    Exactly. EdingCNC handbook p.159 gives the detailed description. pasted-from-clipboard.png


    Yes, you should be able to remove the table if you don't need it. On the other hand, it doesn't hurt either (except from cluttering your code).

    Zitat von tdawg

    I actually thought you work for Sorotec! Do you host any of this on Github?

    Nope, I don't ^^ - I'm new to the CNC world myself and am learning on the way. Sorotec (and maybe EdingCNC as well) own intellectual property rights for the macro, and I didn't ask for written permission yet to "fork" their work and publish - that's why you won't find anything like that on Github. Also Eding's repository is private. But I think it's a good idea to collaborate on that end! Thus:


    Willy / Roy wäre es für euch bei Sorotec OK wenn ich meine Version eures Macros "quelloffen" veröffentliche und über Github versioniere bzw. pflege? Falls ja, habt ihr Vorgaben bzgl. der Open-Source Lizenz?


    Regards / Grüße

    Schallbert

    Zitat von Schallbert

    Willy / Roy wäre es für euch bei Sorotec OK wenn ich meine Version eures Macros "quelloffen" veröffentliche und über Github versioniere bzw. pflege? Falls ja, habt ihr Vorgaben bzgl. der Open-Source Lizenz?


    Regards / Grüße

    Schallbert

    Ja klar kannst machen. Haben wir nichts dagegen, wir sind da unproblematisch :)

    Sorotec GmbH | Support - Team

    Gefällt mir 2

    I discovered that there are some pre-defined callouts within EdingCNC that refer to the macros.


    When I renamed the 'change_tool' sub routine to 'TOOL_CHANGE', it broke. Renaming it fixed it.


    Looking through the manual, other routines with hardcoded names and called by the software itself are:

    home_all

    change_tool

    user_reset

    user_1-20

    xhc_probe_z

    xhc_macro_1-10

    zero_set_rotation

    zhcmgrid


    Everything else can be named whatever you want and associated with your own sub routine.


    You can even nest your own subroutines within these software routines to customize their sequences.

    Schallbert I came back to this thread to ask if you would post your version so I can compare my edits ^^ Thanks for the link, I will have a look around.


    At this point it would probably be good to have a new thread specific for the macro that can contain your articles and the github repository. I made a private github myself to testdrive hosting the files, but am still learning how to use it and implement versioning online instead of my hard drive.


    I am really surprised how little info I can find specific to Eding macros. The Sorotec version has mostly different variables than the Eding macros and is much more complex, so it's obvious they have someone really smart writing this stuff. That person should make a youtube channel or something! Maybe there is a forum where people get together and write macros?


    I have completely free time at work during the holidays and have been reading/editing macros for the last several days straight :sleeping: I think I've hit a point where I am going in circles a little bit and need a break. I'll reach back out when I get back at the computer.

    Schallbert


    Alright, my work is finished... for now. Here's my github repo with all of my changed files. It is drastically different from the Sorotec version, but mostly in naming and some added user macros to rapid move into known locations.


    https://github.com/Miniclubbin/Eding_CNC_Macros_English


    If you find any issues, please let me know! I need that feedback to learn. Not sure how to properly collab over Github, but if you have an idea I'm happy to try it.


    Over the next few weeks, I will work to isolate and test some functions that I'd like to propose Sorotec include in their macro, like improving the cancel functions in some dialogs. I've implemented the "fixes" with my very basic knowledge and hope to polish it up so I can easily present it for use.

    Zitat von tdawg

    Not sure how to properly collab over Github, but if you have an idea I'm happy to try it.

    Here's your first pull request: https://github.com/Miniclubbin…CNC_Macros_English/pull/1

    It's a fix I implemented a year ago on my local copy.


    Thx for opening a github repo. That's an initiative I really embrace. As a software developer I'm used to having everything under version control ;)

    By the way: Copying multiple versions of your files in a github repo and doing manual versioning is not the usual convention. Usually you'd create a branch for intermediate development.

    Hey, that's cool :)


    I'm pretty busy with another project right now but when that's released I'm planning on writing a small piece of software called bundler.

    Bundler will be able to compose a macro.cnc out of a set of subroutines each with its own file, support translations both for code comments and dialoges/messageBoxes etc.


    This will improve readability a lot and a built-in variable handler should be able to fix issues of double-usage with specific variables of which some are persistent, some not, some write-protected.


    In addition, we can keep one common repository instead of multiple ones for different translations this way.

    Zitat von tdawg

    I came back to this thread to ask if you would post your version so I can compare my edits

    Sorry, my version is really stripped down (and is on my CNC laptop that I won't be able to access before week 2/2023) so I think it wouldn't be that helpful.


    Give me some weeks to develop bundler and then let's pull together resources to have a common repository for EdingCNC macros.


    Cheers,

    Schallbert

    Zitat von Schallbert

    This will improve readability a lot and a built-in variable handler should be able to fix issues of double-usage with specific variables of which some are persistent, some not, some write-protected.

    Man that's exactly what we need! I was wondering if there was a way to ID duplicate or unused values. Really looking forward to that. It would be awesome to use text variables like in your tutorials and have them mapped on the back end. Awesome idea.

    Hi Guys,


    looks like I finally will be able to make some time for macro_amalgamation aka bundler.


    Here's the spec I'll be starting with to implement:

    - name: cnc_macro_amalgamation

    - Scope: Python command line application

    - input folder: input_subs (create if not existing)

    - prompt user to put all subroutines that shall be combined into that folder (as .cnc files)

    - read input files and scan for:

    1. duplicate Subs

    2. duplicate Variable WRITES

    3. duplicate Variable READS that are no system variables (makes sense?)

    4. syntax errors (?)

    - sort subs by number (?)

    - list all user variables incl. comments (if available) at top of file

    - list all used system variables incl. description at top of file

    - concatenate input files into one single macro.cnc output file analog to SQL's amalgamation, place in application's root directory

    - github actions pipeline to auto-build for EdingCNC macro repository


    Anything you guys are missing?

    I'll set up a repo and link here once I have a first rough prototype running. Might take some more weeks.


    Regards,

    Schallbert

    Schallbert did you end up publishing a version of the bundler?


    Sorry I haven't been active on this. Unbeknownst to me, diving into the macro seems to only be possible while away on work trips and/or during winter months. Otherwise things are just too busy running the family or running the machine. I haven't even been able to update a tool change skip sequence when starting a job from the handwheel 😭😭😭 pressing cancel each time at the laptop hurts my automated heart so badly.


    Anyways, your bundler project would serve to help me eek some more time out of managing the macro. Curious if you pushed a version I can test.


    Cheers

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden