Hello Guest it is April 24, 2024, 12:15:33 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - RecceDG

Pages: 1 2 3 4 »
1
OK.

So every

Code: [Select]
variable = mc.mcGetSomething(inst)

call that we see in macros like m6() etc are actually a

Code: [Select]
variable, rc = mc.mcGetSomething(inst)

call, where "rc" is the return code that indicates API success or failure.

For some reason, all the scripts people write handwave this away and blithely assume that API calls always work.

That might very well be true in 99.999% of the cases, but it is poor programming practice to not check error codes.

That means that functions like m6() need an error-checking function within them, like this:

Code: [Select]
function m6()
     
     function wc(rc)          -- wc stands for "welfare check"

          if (not(rc == mc.MERROR_NOERROR))
               -- Do something reasonable to abort m6()
          end
     end

     -- Do tool change stuff here
     local inst, rc = mc.mcGetInstance()
     wc(rc) -- make sure we got our instance

     -- etc..
end

I'm talking to some lua experts elsewhere to see if there is a way to do something like

Code: [Select]

 local inst, wc(rc) = mc.mcGetInstance()


so as to make the syntax a little cleaner, and is seems that lua does not have a case or switch statement, so parsing all the various possible error codes is likely to be a bitch.

But it is worth discussing this: if an API call fails in a gCode replacement call like m6(), what should the function do to gracefully report the error to the user and stop the machine?

There has to be a best practice here.

Ideally there would be a global wc(rc) lua function that was written to do just that and came with Mach - maybe there is?

2
Mach4 General Discussion / Upgrade problem - 4498 to 5310
« on: February 04, 2024, 03:31:30 PM »
I have a lathe and a mill powered off the same install of Mach 4 - different profiles.

I have been running 4498 and ESS 258 for forever, but the mill has probes (where the lathe does not) and later versions of Mach and the ESS plugin "fix probing", so it seemed time to upgrade.

Per the instructions, I made a copy of my old Mach4Hobby directory, renamed it, and then installed the new version over the old version.

So now I have 4 profiles: my old lathe and mill profiles, and 2 new lathe and mill profiles.

Attempting to start my old lathe profile spits out a script error, per attachment. This appears to have something to do with new canned cycles as a "Loading Modules" progress widget opens ,but never progresses.

Starting the new lathe profile successfully brings up the UI, but there's no ESS config nor is my custom signal script (which has a TON of stuff in it to support my control panel) active.

(Aside - where do the signal scripts live?)

What's the way to either fix my old profile, or bring my new profile's config info into the new profile?

I assume Mill will do something similar.

3
Mach4 General Discussion / Yet Another Tool Change Script
« on: January 08, 2024, 12:04:02 PM »
I'm in the process of writing my M6 macro (that incorporates tool length probing) and all the scripts I have seen so far have bugs in them.

So this is to document my attempt at the be-all, end-all, cover-all-edge-cases tool change script.

Psudocode

M6(tool_number) {

      constant tool_probe_x = "0.250"                            # Machine coords of tool probe centre
      constant tool_probe_y = "-1.250"

      constant probe_clearence = "9"                              # Distance between spindle and top of tool probe at G53 Z0

     get current_tool_number
     return if (tool_number == current_tool_number)      # We are trying to change to the already installed tool. This is a NO-OP

     get spindle_state                                                    # Shut off spindle if it is on
     GCode("M5") if (spindle_state != "off")

     get flood_coolant_state                                           # Shut off coolant if it is on
     get mist_coolant_state
     GCode ("M9") if ((flood_coolant_state != "off") || (mist_coolant_state != "off")

     get current_x_position                                              # Work coordinates
     get current_y_position
     get current_z_position

     get tool_desc = Tool_Table_Description (tool_number)
     get tool_length = Tool_Table_Length (tool_number)

     GCode ("G53 G0 Z0.0")                                                 # Lift head all the way up
     StatusMsg("Change to tool $tool_number $tool_desc")
     Mach4_Wait_On_Tool_Change                                        # Mach4 built in manual tool change function. Flash UI, wait on CYCLE START

     UserPrompt("Probe this tool?")                                       # Open dialogue box
     if ("no") {
          GCode("G43 H$tool_number")                                   # Apply tool length from tool table
          GCode("G0 Z $current_z_position")                            # I sure hope you got that length right!

     } elsif ("yes") {
          GCode ("G53 G0 X $tool_probe_x Y $tool_probe_y")      # Move tool probe under tool
          rapid_down = -1 *(probe_clearence - tool_length - 2)    # We are going to rapid down to 2" above the tool probe!
          GCode("G53 G0 Z$rapid_down")

          probe_z = -1*(probe_clearence)                                   # The point is negative but the constant is positive

          GCode("G31.1 Z$probe_z F10")                                    # probe the tool

          probe_stop = get_#_variable(probe Z)                          # read the probed end position
          measured_tool_length = probe_clearence + probe_stop  # Probed position should be negative... check this

          if (abs(measured_tool_length - tool_length) > 0.020) {   # If we are over a reasonable threshold for a difference in measured length vs table length, something is wrong!
                Freak_Out                                                              # exact steps TBD

          } else {
                write_tool_table(tool_number, measured_tool_length)   # Update the tool table and activate the offset
                GCode("G43 H$tool_number")

               GCode("G53 Z0")                                                          # Lift head to safe height
               GCode("G0 X$current_x_position Y$current_Y_position")  # Back to where we were XY
               GCode(G0 Z$current_z_position")                                   # Perilous!

         }
     else {
               FreakOut     #Should never get here
      }
         
      GCode ("M7") if (flood_coolant_state == "on")
      GCode ("M8") if (mist_coolant_state == "on")

}


4
Mach4 General Discussion / Homing Best Practices
« on: October 03, 2023, 09:13:37 AM »
So my mill has home/limit switches as follows:

2 on the X axis (left and right)
2 on the Y axis (in and out)
1 on the Z axis (all the way up)

For the paired switches, they are wired NC in series such that a failed wire stops the machine. I'm OK with the lost precision of knowing which limit (high or low limit) was tripped, as it will be visually obvious and it saves inputs. Ditto the configuration as both limit and home.

In my current scheme, homing the machine moves the head all the way UP, the table all the way RIGHT, and the table all the way OUT, as this seems to be the safest way to move with an unknown setup on the table.

However, I realized that this means my Y axis is configured backwards, as turning the jog handle clockwise (increasing) moves the head UP (correct) the table LEFT (correct) and the table IN (backwards) for a 0,0,0 that is supposed to be in the front left corner.

So as I see it, I have the following options:

1. Flip the Y axis and home to the other switch; or

2. Flip the Y axis, home in the opposite direction (is that even possible?) and then apply an offset (I know the exact distances between the two limit switches so I can do this to the micron) such that Y0 is "all the way in").

But then there is another consideration:

The vise on the table is placed so that the moveable jaw is out and the fixed jaw is in. This means that Y0 (work coordinates, not machine coordinates) changes depending on the thickness of the part in Y, where the YMax of the part is always colinear with the fixed jaw of the vise. That suggests that Y0 that was coplanar with the fixed jaw of the vise and increased moving towards the moving jaw (in other words, what I have now) would allow for a consistant Y0 location - and that theoretically, I could put an offset on the Y homing such that Y0 machine coordinates was on the vise jaw line.

The "so what" being that I would have to relocate part zero in CAM to be the upper left corner, and the numbers on the jog handle are backwards in Y - both of which I think I can live with.

Thoughts?

5
Mach4 General Discussion / Spindle ON/OFF UI Confusion
« on: April 25, 2023, 10:44:15 AM »
I just helped someone out (from another forum) who was pulling their hair out because they couldn't get their spindle working (ESS with C25X board)

It turned out that he was using the UI spindle clockwise/counter-clockwise button to try and start/stop the spindle.

I, being an old hand, know that the UI button won't work until the S word has been populated via MDI or via a program, so told him to type "S2000 M3" in the MDI window and press "CYCLE START" - which worked.

Apparently the CNC4PC guy didn't know this either; the two of them had been going back and forth on this for a week.

The UI button should fire a popup warning if it is clicked with the S word equal to zero....

6
After answering the same damn question for the thousandth time over on Reddit /r/hobbycnc, I got tired of it and wrote a book to help people out:

https://www.amazon.com/dp/1738802108

I figure about 2/3rds of y'all here are well past this book, but maybe you too are tired of answering questions and could use a reference that's a little more introductory than the Pete Smid books or the Machinery's Handbook.

The paperback is the best deal. I find the Kindle version doesn't work as well (too many pictures) and the hardcover is just there to make the paperback look cheap. :)

It's print-on-demand, and there are versions (English only) that can be bought from your local Amazon if you aren't American; it save a lot on shipping costs. Just search for the title and you'll find it.

Share and enjoy!

7
Much work has been happening on the mill!

I have the Z axis together and the ClearPath servo auto-tuned, and I get 400 in/im and 1G accel out of the thing:

https://youtube.com/shorts/lfv4NNx5zTs

Except....

When jogging with the handwheel (MPG), I have a selector switch and code that controls how far the axis moves per handwheel pulse - 0.001", 0.01", or 0.1". On the 0.001"-per-pulse setting, it's fine. On the faster settings, jogging generates a "move one increment then stop" movement, and at 1G acceleration / 400 in/min that's not a smooth movement; it's BANG-BANG-BANG.

It's way, way too harsh to be usable; something is going to break.

I could turn down the axis acceleration, but where's the fun in that?

Is there some way within the Lua API to slow down the movement rate and/or acceleration when jogging?

Thanks!

8
Clearpath servos provide a 0-5v output that is a measurement of how hard they are working, so I have 3 inputs assigned to them, and have created 3 gauge widgets on my screenset that I want to use to provide visual indications of axis load.

It isn't clear to me though how to assign a gauge to an input value.

Clicking on various widget properties, I found a drop-down list of ESS control lines, but that seems too low-level - I should be able to link to a Mach signal/value, one abstraction layer away.

So how is this done?

9
Mach4 General Discussion / What conditions set the ALARM signal
« on: April 13, 2022, 12:12:41 PM »
I have a light tied to the ALARM signal, but nowhere in the docs can I find what conditions set that signal.

So - what sounds the ALARM?

10
Mach4 General Discussion / Wx4 Screen Set Tool Change Not Working?
« on: April 06, 2022, 06:37:40 AM »
I have my controller and control panel for my mill wired up and working, and I am in the midst of adding the Lua to enable the panel switchgear, and tweaking the screen UI to be a better fit for this mill.

This is mostly self-plagerization from the lathe project, so I got over most of the Lua learning curve a year ago.

I have, however, encountered something odd.

On the lathe, “T0101 M6” halts the program and flashes a UI screen light indicating a pending tool change. Clicking Cycle Start twice (once to acknowledge the tool change, once to resume the program) updates the current tool UI elements and resumes the program.

I have added functions on the lathe to enable the physical cycle start button to do the same thing, plus flash a physical LED while tool change is pending. Works great.

In the mill, I expect “T01 M6” to work the same way - but in the Wx4 screen set, that GCode does nothing. No pause, no UI light flash, no update of tool info - nada.

I have not mucked with any of the tool change elements or backend code. As far as I can tell at the moment, this is default behaviour.

Is Wx4 broken? Known problem?

Pages: 1 2 3 4 »