Posts by tdawg

    That means I take wlsA, measure it like in the video, and then use it to find Z “0”. I put wlsB on a defined location and program it in EdingCNC as a tool length measurement point?

    Hi, are you using EdingCNC? If so there is a z0 sub routine and a tool measurement subroutine(macro) where you would need to define the wzl sensor height.

    I have 2x wzl sensors and have defined each sensor height within each macro as it's own parameter. zbs I have one fixed wzl 41.1mm high defined as #4500 in sub tool_measure, then the z0 wzl 41.3mm high defined as #4510 in sub z_probe. Then when each macro runs, it uses the applicable sensor height. If I were to swap the sensors, the measurements would be totally wrong.

    My workflow is to measure the tool length initially, probe z0, run the job until M6, then calculate the difference in the next tool and adjust z0.

    Edit: I see you are using EdingCNC, so you can do it as described. You can see my entire macro in English here:…lob/main/MACROS/macro.cnc

    If you aren't using EdingCNC, it will be different in the configuration but the concept is the same.

    Thanks Schallbert

    We are on the same schedule, because I was about to post my solution. That's exactly what it was.

    I spritzed some silikon Öl at the points circled in the picture and the noise is resolved.

    My noise seemed to be moreso from the fixed bearing wiper, but the klauenkupplung also went silent after lubing it.

    For the X, I'll need to wait until winter break and hoist the machine to get underneath it.

    I have a CL and recently the Z and X axis have started making a rhythmic creaking during movement.

    I've traced the sound to either the main bearing for the ballscrew or the stepper couplers.

    Anyone have experience with the couplers making noise as they get older? Maybe they get dry and the insert starts rubbing? If so, what kind of lubricant is safe to use with them?

    I recently started using G54-G56 for some different operations (G54 - current workpiece center, G55 - Lower left corner for probing, G56 - alternate workpiece center).

    I was getting some crazy behavior where my XY0 would move all over the place after setting 0 and switching between WCS.

    The problem:

    G92 commands shift ALL workspaces!

    For this reason, replacing G92 became top priority and this was the result:

    - Set zero button behavior in Eding CNC to L10P....

    - Replace any G92 commands with corresponding G10, for example:

    G10 L20 P[#5220] X0Y0 ; Set current WCS offset [#5220] X and Y zero
    G4p0.2 ; pause .2 seconds

    So Schallbert thanks again for the idea, you ended up saving me a ton of frustration and helped me get to a valuable Gcode lesson. Using #5220 lets me stay in my "operational" workspace and I can leave the actual XY0 alone in another G5x space.

    Updated ZHC macro and a new macro I made to make sure I don't forget to use ZHC (called in the post processor header):

    I have the eco 10060, but have not had a chance to really get into it. My piping has some leaks that I couldn't quickly find, so I have it waiting for busy season to slow down.

    Initially with just one side connected, I could completely suck down a cupped 600x300x19mm buche plate 👍 that's with a Kärcher WD6 1300w.

    Eventually I want to be able to engrave 1000x600 plates and make many parts in one job. That is the dream, better than doing each 300x600 individually. Every single one bows up after painting.

    I've quickly upgraded my spindle and some other parts and have almost new original parts that would be better off in someone else's shop.

    Kleinanzeigen is too general and nobody seemed to want anything. Same for Facebook.

    Are there other German forums with classified sections? Or should I try eBay?

    Thanks Schallbert that's definitely a decent alternative. I've had trouble finding use cases for the additional work offsets, but I keep stumbling into new situations where they are useful.

    In this case, I could set my material xy0 in g54, call g55 and set a new xy0 relative to the clearance distance, then simply switch back to g54 on completion. That could save me a movements on the backend.

    If I make the update I'll post it for critique ☺

    Unrelated: I loved your blog on vacuum work holding. Helped me avoid making a €3000 euro mistake that might not have worked in my application 🍻

    I've recently discovered and learned how to use the Z height compensation tool in Eding CNC. I've also made some modifications to make it easier and quicker for me to use:

    - added a tool check to ensure sub only runs with 3d probe

    - added safety dialog to verify XYZ0 is set correctly before starting

    - added automatic grid size calculation based on material length and width

    - added specifying a clearance distance in XY so you can probe from XY0, but not worry about hitting clamps or probing dead space outside your actual cut area

    - CHANGED original #100 series variables to #4100 series in order to deconflict with 3dprobe macro from Sorotec

    HOWEVER, my current implementation uses G92 to change XY0 to account for the clearance space. I would rather not mess with the original G92 XY0 and instead have it factored into the grid point location logic.

    Anyone want to take a stab at improvement? The focus area is the XY movement:

    G0 x[#4107 * #4104] y[#4108 * #4105] ;to new scan point [current n * grid distance]

    Full macro:

    Thanks Schallbert . I'm tracking the macro and 4400, and that's what led me to my discovery-the tool sensor tested OK in the program, but was unplugged!

    It turns out that the sensor I have in this case is NO normally open, not NC as it was labeled.

    Nothing is wrong with the machine, and a NC sensor will fix the issue I described above ;(

    So much headache chasing the issue, when it was the incorrect sensor.

    Cay good question. I have always done trial and error testing with my engraving bits. Calculate a good chipload (feed per tooth), like 0.06 and adjust feeds and speeds then. I usually start at 18.000/1500mm/min and adjust based on desired finish and chatter using the feed overrides.

    Set the 3dprobe as a specific tool # (99 for me) and then ensure you have a macro to check which tool is inserted before running anything that isn't good for the Probe.

    IF [#5008 > 97] ; Tool 98 and 99 are 3D button - no Tool Length Measurement

    msg "Tool is 3D button -> Tool Length Measurement not executed"

    M30 ; END of sequence


    Solved: sensor was incorrectly labeled as NC but was NO, causing input to show as active.

    No way to invert the Probe signal on the CNC720 that I can find, but I no longer need to.



    I currently have a situation where my probe input #5068 shows active even when a Probe is disconnected. The input switches fine and I can probe normally when the input is switched to off by the probe during g38.2, but for safety reasons this is a problem because there is no difference when the Probe is plugged in or not, so a fault would not be detected.

    I cannot find anything in the software to adjust this input and invert it besides changing the lines in the macro file to invert my watchdog commands. Does anyone know a line in cnc.ini I can modify to change it?

    Also, does anyone else have a normally-active (#5068=1) probe input on their eding controller? I could swear it only started once I added an inductive Probe, but can't be sure. Now it is like this even with a mechanical Probe.

    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.


    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.


    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.

    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.