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

Galil / Re: buy Mach4 yet? for a Galil DMC 2133?
« on: November 04, 2015, 03:56:04 PM »
Unfortunately, the M4 Galil plugin is still in Alpha stage.  Estimated time out now is the end of the year.  But that could change.


Galil / Re: Controlling a SuperPID w/ Galil 1842 and Mach3
« on: November 04, 2015, 03:53:56 PM »
Unfortunately, it is not possible to run a PWM spindle with the Galil plugin.


Mach4 General Discussion / Re: Showing selected axis
« on: November 03, 2015, 07:48:51 PM »
It works fine.  In 2788, the way MPGs are handled internally is different.  Now there is the concept of encoders that plugins can "export".  And there is a new tab on the Mach config labeled "MPG" of all things.  :)  In that tab, the user can associate a Mach MPG (12 to choose from) to an encoder from any device.  %max vel and %max accel are there as well as reversing the direction. 

For many of you, if you had script based setup of the MPGs, then that stuff will need to go away.

The shuttle plugin exports 1 encoder.  The center wheel.  Additional button functions were added to allow the MPG axis selection as well.  One thing to note is that MPGs are separate than regular jogs.  The MPG axis can be selected independently of the jog axis.  Currently, there is not a way to select both the MPG axis AND the jog axis with one button function.  Not sure how to handle that at the moment. 

My setup is as follows:

MPG#1 -> /Shuttle0/InnerWheelCount, 1 count per detent, accel% 25, velocity% 35, reversed.

The first 4 buttons in the top row of the shuttle pro are:
1.  MPG1 Select X
2.  MPG1 Select Y
3.  MPG1 Select Z
4.  MPG1 Select A

The MPG increment is the current jog increment by default. 

So all I do is press one of my 4 buttons to select the desired axis and start dialing away on the wheel.  And it works really well.  I wish the detents were a little more noticeable on the shuttle, but it is what it is...

MPG#0 is configured to another MPG, so that is why I used MPG#1 for the shuttle.


Mach4 General Discussion / Re: Mach 4 Bug Reports
« on: July 27, 2015, 01:37:43 AM »
Make a copy of the Mach4Mill profile and use it instead.  That way, your settings do not get overwritten.

Mach4 General Discussion / Re: Mach4 Executing Gcode from LUA
« on: July 01, 2015, 02:55:51 PM »
For macro scripts (not screen or buttons scripts), The M code functions are available in the calling M code.

if state == 1 then


Mach4 General Discussion / Re: No Script Engine Found for ...
« on: June 03, 2015, 11:01:08 PM »
Enable the mcLua plugin. 


Mach4 General Discussion / Re: need a little bit of help
« on: June 02, 2015, 11:18:50 PM »
Terry...  There is nothing in the core that is LUA.  The core has no knowledge of LUA.  The GUI has LUA.  And the macros can be scripted in LUA via the mcLua plugin.  When the core executes a macro script, all it does is hand it off to a plugin.  If someone wrote a VB script plugin, the scripts could be in VB.  If someone wrote a GUI, then they could use VB in that GUI. 

GUI --|  (LUA for the screen)
        Core ---|
                  Plugins. (LUA for the macro scripts)

The GUI is the HMI (Human Machine Interface).  It is where the rubber meets the road for the operator.  How the interface operates is up to the user/operator/integrator.  The Core is like an operating system.  In fact, I used to write operating systems so the Core modeled very closely to that of an operating system kernel.  It's sole purpose in life is to provide services to the application layer (GUI) and to interface with hardware via the plugins.  The plugins could be considered something analogous to operating system device drivers.  The core can be extended via plugins too.  This provides future flexibility. 

The LUA scripting uses the EXACT same API that we use in C++.  It IS the API.  It controls the core.  Not the other way around.  When you hit the Cycle start button, mc.mcCntlCycleStart() is used to tell the core to start executing.  So please tell me how LUA that controls the core should be controlled by the core?  How could the core ever have dominion over what the M code script wants to tell the core to do?  What if the core just said no?  That would be useless.  Your arguments are circular.

What keeps you from messing up when writing G code?  What protects you from yourself?  If you tell the spindle to plunge through your workpiece or the the table, what do you expect to happen?  It is up to you to write a good G ode program.  It is also up to you to write a good script program. 

One of the needs that kept popping up for Mach 3 was increased flexibility.  Therefore, that was a design goal for Mach 4.  I'll say it again.  There is nothing wrong with it.  There is no design flaw.  You can use it.  Or not.  Your choice.  You will be waiting a very long time for someone to make a system like you are wanting.  Maybe forever.

And waiting for what?  You make the machine do what you want ONE time.  Then, you use it!  I am an operator.  I did this very stuff on my very own machine.  It wasn't hard.  And I haven't touched it since I did all of the screen and scripts.  Not once!  All I do is go downstairs, turn the machine on, and run parts.  The machine is working for me, as you like to say.  The same way every time.  Just like I want it to. 


Once you get used to sizers, you will wonder why that has not been the way to do it from the beginning of time.  Yeah, there is a learning curve.  And some things are not possible.  Overlapping controls, for example.  However, you can still do that by NOT using sizers.  You can set the control positions manually if you want to.  But it is hardly worth the effort.  Sizers make expanding/aligning the controls with the parent window much easier just by laying out the sizers in a manner that does what you want.  Eventually, you will know how to get what you want and it becomes second nature.  And not using overlapping controls is a small price to pay for that.  You just have to change how you lay out the window in most cases.

As you mentioned, wxFormBuilder now includes support for generating LUA code.  I have not tried it, but it is nice to see that they did that.  But using a tool like that can certainly help you visualize how to work with sizers.  Generate a form and put some sizers on it and see what the code looks like.  I think that would be pretty awesome.  I'll have to play with it if I have time.


Mach4 General Discussion / Re: need a little bit of help
« on: June 02, 2015, 04:55:24 PM »
You are correct!!!  It is prudent to check the API functions for error codes.  In examples, I don't write that stuff in, as it becomes time consuming.  But it is NEEDED for production scripts to ensure that when things go wrong, it gets handled properly.  In the API docs, most of the examples are in C.  Some of the functions have LUA examples.  But the C examples use the error codes and can be used to deduce what they would be in LUA. 

Here is a snippet of a manual tool change M6 macro.
Code: [Select]
    -- M6start stuff here....

    --Here, we process an EVT_MACRO_HOLD and enter the macro hold state.  We can jog there!
    mc.mcCntlSetLastError(inst, "Press Cycle Start to finish the tool change.");
    wx.wxMilliSleep(100); -- wait a few so that the GUI can retrieve the message before the machine changes state.
    --  A sleep is not generally a good idea to use.  But in this case, it is harmless as the wait is minimal. 
    local rc = mc.mcCntlToolChangeManual(inst); 
    -- execution resumes from here when the user presses Cycle Start or Cycle Stop or some sort of E-stop or disabling of the machine.

    -- but in the mean time the user can Jog, toogle switches, stand on your head, or do anything else he likes!

    -- We check the rc of mc.mcCntlToolChangeManual() because the user might have aborted
    -- the tool change by pressing Cycle Stop.
    if (rc == mc.MERROR_NOERROR) then
        -- the user has not aborted, finish the tool change.  M6end stuff.


Mach4 General Discussion / Re: need a little bit of help
« on: June 02, 2015, 03:11:32 PM »
Terry, I think you are missing the point.  G code is NOT a programming language in the classical sense.  It is a command language.  It has no logic statements without the macro B stuff.  No way to control the flow at all sans the simple sub routine mechanism at all.  For example, what is the G code to test that machine movement has been completed?  What in G code notifies the operator of the machine that the G code is complete?  I mean standard G code.  Not a scripted macro.  M00?  M01?  What action/event is taken by the G code if "G00 X0Y0" is executed and then completed?  Nothing.  The machine executed the code and then just sits there like a bump on a log waiting for the operator to do something else.

Macro B is not another language.  It is an extension of the G code command set.  It executes in the same context as the regular G code.  Therefore it is an apples and oranges comparison.

Waiting on an event in a PLC with a loop is controlling program flow.  It is a LESS efficient way of doing so!  Ladder with VB is an extension just like Macro B is an extension to G code.  It operates in the same "program" context.  It is the same interpreter on the same device.  So how would you take TWO PLCs and make them work with each other?  That is a better example.  You will HAVE to use flow control mechanisms to prevent a race condition in one or the other PLC.  Because you are now executing code in two different environments/devices/contexts.  Is it a kludge?  Certainly not.

With that HUGE thing said, there is no possible way to integrate G code and LUA to the extent you are talking about.  Simply because G code can't really "communicate" with anything to that extent.  Unless we also interpret LUA along side of G code with the same interpreter, then having what you describe is simply not possible.  And then users would have to sprinkle LUA in with their G code just like you had to sprinkle VB in with your ladder logic.  Terry...  you have to distinguish what is a dream and what is reality.

In my example code above, it uses a semaphore like var to control the execution.  Please explain to me how that will not work on different machines?  Or for that matter, how would C/C++ mutexes and semaphores not work the same on different PCs?  If that were the case, EVERY windows program would have to be custom made for EACH PC.  That is not the case.  I don't want to argue, but what you are saying is simply not the case and I feel it a disservice to the rest of the community to let such a notion stand.

There is nothing wrong.  There is no design flaw.  It is working as intended to make the system as flexible as it can be.  It is the way it is for very good reasons.  The sooner you accept that and just move on, the happier you will be.  :)