Hello Guest it is April 18, 2024, 07:18:35 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.


Messages - smurph

11
Mach4 General Discussion / Re: Set Tool Number in Gcode?
« on: September 06, 2023, 06:08:44 PM »
Build 5194 is up with M61 in it.  Check the docs on how to use it.  Basically M61 Q1.  Q sets the tool number.  Q0 means no tool installed. 

Steve

12
Mach4 General Discussion / Re: Set Tool Number in Gcode?
« on: September 05, 2023, 06:41:07 PM »
I'm fixing to add M61 as a means to do just this.  I'll post when there is a build up with this in it. 

Steve



13
Mach4 General Discussion / Re: Mach4 Closing
« on: August 31, 2023, 01:45:13 AM »
You are correct.  This forum is a good place to get answers to questions.  I saw you had an issue with your scripts and I posted a solution.  If you have an Industrial license, we also have phone support.  But the solution I gave you, because I honestly wanted to help you out, is sound and it works flawlessly 100% of the time.  I realize not everyone is a programmer (and not everyone is an engineer), so I try and help out when I can.

I'm not going to argue much of anything here.  I just don't want people reading and getting the wrong idea.  My goal is no misconceptions.  So I'm just going to throw out some facts based on a system that I'm intimately familiar with.

1.  If Mach is used with a closed loop system with encoder feedback, Mach will NOT lose position when e-stop is pressed or Cycle Stop is pressed.  This includes closed loop controllers like the Galil, Vital Systems DSPMC, or any Step/Dir controller with encoder feedback used to drive so called "digital" step/dir or position controlled servo drives.  With these motion systems, Mach 4 is no different than a Fanuc.  If anyone tells you something different, they are giving you bad information.  Even if they work for a motion controller company, they may not know exactly how Mach operates.  As the primary developer/programmer for Mach 4, I can promise you that these motion systems do not lose position when e-stop or Stop is pressed.  If I had to home every time I pressed stop or e-stop on my Matsuura (Mach 4 conversion), I would freak out and start sky screaming and probably start throwing rabbits.  :)

2.  Mach 4 commands the motion controller to home most of the time when the reference button is pressed.  It doesn't care how the system is homed, whether by the motion controller or a motor.  All Mach cares about is "Are the axes homed and if so, what is the position of each with which to to synch the planner."  Home the best way you can.  I think it is cool that the motors have a homing routine. 

3.  With M66, you can specify the timeout with the Q word.  A value of 4294967 seconds can be use in order to make it wait for like 8 years.  Hopefully the operators don't take a lunch that long!  :)  M66 works in the very same manner on Linux CNC, BTW.  So Mach 4 isn't the only device/controller in the world that works like that.  I don't want people getting the idea that M66 is just junk and doesn't do what it is meant to do.  It works exactly as advertised.  M66 does work best with industrial so that conditional G code can be use to check for a timeout.  But failing that, writing your own m166.mcs is good means of not requiring the G code conditional statements. 

And I have an observation that may not be immediately apparent to all that just pop into this forum.  When you first see these forums, all you see are people with problems or questions, real or perceived.  And most likely anyone that comes to these forums has a question of their own.  Sometimes people figure out what they did wrong or need to do and fix it themselves.  Sometimes they found something that genuinely needs fixing in Mach.  But most of the time people that are as spending an a bunch of time to solve a problem are people that want something custom and they need help doing it.  And they are most likely not engineers or programmers.  They understand what they want, but not how to get it.  So they come to the forum for help and the community tries our best to help them.  But it can still take a long while to sole their issue because we are not sitting at their machine.  Also, a lot of times people don't even know the terms to use to ask.  So yeah, there may be a lot of code and examples flying around the forum while everyone is trying to get on the same page.  So what you see on this forum are people needing help.  You do not see the majority of people that don't need help posting on the forum.  The VAST majority of people buy their machines turn key and don't need any help at all.  Then there are people that install Mach and run their machines fine because they don't need anything custom.  Otherwise, we would have to hire thousands of support people.

I'm not going to laugh at .007" holes.  A friend of mine used to make glue dispenser pumps with holes around that size. He made a fortune!     

Steve


14
Mach4 General Discussion / Re: Mach4 Closing
« on: August 30, 2023, 04:31:32 PM »
Stop NEVER stops the loop.  E-Stop will not stop the loop.  Once a script starts, it runs to completion.  So if you use loops you MUST provide a way to break out of the loop.  It is designed that way and it is perfectly acceptable.  Here is why: Manual tool changes or any operation that requires the control to be taken out of automatic/run mode.  Also, some scripts may need to detect the E-Stop, Reset, or Cycle Stop condition and perform some cleanup or safety action.  I just gave an example in another post where the script needs to continue to run even when the control is put into the idle state. 

I took my M3 script and modified it to test the code I gave above.  I tested this script and I could break out of the loop with cycle stop and disable 100% of the time.

Code: [Select]
function m3()
    local inst = mc.mcGetInstance('M3')
    mc.mcCntlSetLastError(inst, 'Going into the loop')

    local state = 0
    local rc = mc.MERROR_NOERROR
    local loopCondition = 1

    state, rc = mc.mcCntlGetState(inst)
    while (loopCondition == 1) and (state ~= mc.MC_STATE_IDLE) do
        wx.wxMilliSleep(10) -- Sleep for 10 milliseconds
        state, rc = mc.mcCntlGetState(inst)
    end
    mc.mcCntlSetLastError(inst, 'Broke out of the loop.')

end

if mc.mcInEditor() == 1 then
m3()
end

And I've also interlocked the CycleStart to the axis being HOMED like most industrial equipment would be. Can't start a program legitimately without actually knowing where the machine is. Unless you want to rip off a robot arm, demolish a fixture, or do something else that should end up on YouTube as an example of what not to do.
Mach is designed to run with as little modification as possible on as many machines as possible.  We simply cannot make a configuration that covers every machine.  So it is up to the machine integrator (you) to make it work how you want it to work if you want something different than our defaults.  If you want it more industrial, then we give you the tools to make that happen.  That said, there are lots of examples with auto homing (PMC objects and LUA scripts) to help in that goal.  I really like using the PMC to do tasks like this as it doesn't require any scripting.  There is also an option in the general tab of the configuration dialog that lets you select if you want the axes to be dereferenced in e-stop.  Believe it or not, we have a lot of customers that don't even have home switches.  All machines are different unless you are an OEM that is building lots of the same models.  For instance, my machine, once homed, will not lose position even if you hit e-stop.  I can reference the machine once when I turn it on and never have to reference it again until I turn it off.  If it homed every time I pressed Cycle Start after e-stop (I have no Cycle Stop button on it), I'd lose my mind!  And we have machines with absolute encoders that never need homing.  So we have to be able to cover a wide gambit of machines.

Steve

15
Mach4 General Discussion / Re: Problem with custom M5 macro
« on: August 30, 2023, 03:52:36 AM »
Calling a macro from another macro with mcCntlGcodeExecute/Wait() is not the best practice.  You are writing a script that should call script functions where possible.  So if M5 called mc.mcSpindleSetDirection(inst, mc.MC_SPINDLE_OFF), then your M30 script should too INSTEAD of calling mcCntlGcodeExecute/Wait(inst, "M5")  Why?  Because the interpreter is already RUNNING an M code that is backed by a script.  Some M codes are built in (no script) and they will run. 

So what if you M5 does some multiline complex operation and it is hard to edit EVERYTHING to do that operation? Especially if you made changes to it and want to update everything.  This is where code sharing via modules becomes a good idea. 

Steve

16
Mach4 General Discussion / Re: Alpha Cam Post Processor
« on: August 30, 2023, 03:40:50 AM »
If AlphaCAM has a standard Fanuc post processor for say a Fanuc 21i, then that is all they need. 

Steve

17
Mach4 General Discussion / Re: Machipc could not be found
« on: August 30, 2023, 03:31:17 AM »
I would try installing the Visual C/C++ runtime as Administrator for Visual Studio 2017. 

https://aka.ms/vs/17/release/vc_redist.x86.exe

Steve

18
Mach4 General Discussion / Re: Mach4 Closing
« on: August 30, 2023, 03:22:59 AM »
Ok, what happens when you press the Disable button or E-Stop button?  The machine goes into the IDLE state, right?  Simply check for the idle state in your loop.

Code: [Select]
local state = 0
local rc = mc.MERROR_NOERROR
local loopCondition = 1

state, rc = mc.mcCntlGetState(inst)
while (loopCondition == 1) and (state ~= mc.MC_STATE_IDLE) do
    wx.wxMilliSleep(10) -- Sleep for 10 milliseconds
    state, rc = mc.mcCntlGetState(inst)
end

Steve

19
Because that is what you set for the screen label.  In this screen, the label is set to Mach 4.

20
Mach4 General Discussion / Re: Set GCODE Line using Lua scripting
« on: August 30, 2023, 02:38:48 AM »
Yes, the GOOMBA is correct.  MACRO B is the way this is done in the main stream and mc.mcCntlSetGcodeLineNbr() will not work when the machine is running (as stated in the API manual).  This API is used by external scripts or GUIs to set the line number.  As in where you click on a G code line in the G code list when the machine is IDLE.  The IDLE state is important, otherwise, the user could click lines in the G code list while the machine is running and cause all sorts of mayhem and chaos.   

And here is when I also get on my soap box about checking the API return codes.  Because if the API was implemented in C/C++ but not implemented in LUA, it would simply be an unknow function to LUA (macro would produce a runtime error) OR the function call would return mc.MERROR_NOT_IMPLEMENTED.  Either way, there would be no mystery why the API call didn't work. 

All that being said, you could possibly use the mc.mcCntlSetGcodeLineNbr() when the machine is IDLE by first calling mc.mcCntlCycleStop(), then waiting on the state to become IDLE and then calling mc.mcCntlSetGcodeLineNbr() followed by mc.mcCntlCycleStart().  It was never meant to function like this, so your mileage may vary.  You cannot jump to a N label in the G code with this.  Only the physical line number.  Obviously, this would NEVER work in MDI mode as there isn't a real notion of line numbers in MDI and the function would try and set the G code file line number instead.  And you may have to wait a bit after the call to mc.mcCntlSetGcodeLineNbr() to allow the GUI to update its notion of the line number.  I can't remember if the function is synchronous where the line is set by the time the function call completes or asynchronous where the line number is set lazily.  Again, caveat emptor! 

Code: [Select]
local inst = mc.mcGetInstance(inst, 'Trying to do the impossible script')
local lineNumber = 12 -- the G code line you want to jump to.  It is base one, so 12 is line 12 and not line 13.
local rc = mc.MERROR_NOERROR
local state = 0

rc = mc.mcCntlCycleStop(inst)

-- Wait until the machine state is idle.
state, rc = mc.mcCntlGetState(inst)
while (rc == mc.MERROR_NOERROR) and (state ~= mc.MC_STATE_IDLE) do
    wx.wxMilliSleep(10) -- Sleep for 10 milliseconds
    state, rc = mc.mcCntlGetState(inst)
end

rc = mc.mcCntlSetGcodeLineNumber(inst, lineNumber)
if (rc == mc.MERROR_NOERROR) then
    -- We got the proper return code from the API
    -- telling us that there are no errors.
    rc =mc.mcCntlCycleStart(inst)
    if (rc ~= mc.MERROR_NOERROR) then
        -- Some error happened.
    end

    -- if the code path gets here, the machine SHOULD be in File Running mode. 
    -- However, it is a good idea to check for the idle state at the end of any M code macro. 
    -- This lets you catch any action a user may have taken to stop the machine while the M code was running.  E-Stop or Cycle Stop, etc...
    state, rc = mc.mcCntlGetState(inst)
    if  rc == mc.MERROR_NOERROR) and (state == mc.MC_STATE_IDLE) then
        -- The user must have aborted the G code!!!!!  You can handle this gracefully if you needed to here. 
    end
end

Obviously, if you are trying to make API calls like this work, this means you are trying to make Mach do something that is doesn't do out of the box.  Luckily we provide the API to make this possible but understand you are now programming.  And you have to get your mindset right to program any device.  It isn't a human.  It isn't going infer anything.  And it may make assumptions that you are not.  So treat is like it is a 3 year old kid.  You have to tell it to do everything step by step.  I mean EVERYTHING.  Including error checking. 

Anyway, I hope this helps,
Steve