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

441
Mach4 General Discussion / Re: Mach4 Executing Gcode from LUA
« on: May 29, 2015, 02:06:41 AM »
I was speaking of GUI events.  Button presses, menu selection, etc...  Windows has an event loop.  The application updates it's controls with the very same event loop.  Signal events are external.

The MDI and GcodeExec functions load the G code into the interpreters and run it.  The movement happens at the motion controller and the motion controller updates the core with it's positions.  These positions are immediately sent to the Mach 4 screen.  If there were no long running button event, the screen would update within milliseconds.  There is no mystery location.  Each DRO has a list of what it is to control/display.  The values can be accessed with the scr.* LUA functions if you are wanting to track them.  I have never had a need to though.

I have no idea why a signal script would pass info to a screen load script.  The load script is loaded upon initial display of the screen.  Functions in the load script can be called if they are included in the load script.  But make no mistake, the load script is only actually run once.  It sounds like you need to use the PLC/signal scripts to me.  That is what should be used to process and input event.

One thing I have noticed is that there are a lot of fancy code snippets floating around for the LUA scripts.  And that is all great and wonderful.  But sometimes simple brute force code is best and in the end, more readable.  I'm not a LUA expert by any means, so I tend to keep it simple.

Signal script.  In the example, Input #1 is tied to a stop button on the panel.  If the machine is running, this will stop it just like hitting the stop button on the screen.  Input #2 is tied to a Start button.
Code: [Select]
    local inst = mc.mcGetInstance();
   
    if (sig == mc.ISIG_INPUT1) then
        if (state == 1) then
            mc.mcCntlCycleStop(inst);
        end
    end
    if (sig == mc.ISIG_INPUT2) then
        if (state == 1) then
            mc.mcCntlCycleStart(inst);
        end
    end

It is not elegant or fancy.  But it is damned effective. 

It is important to note that the signal script only gets called when a signal is changed.  So holding down the stop button will not continually call mcCntlCycleStop().  The signal changes state from low to high once when you press the button (the signal script is then called with state set to 1) and then from high to low when you let off the button (and the signal script is called again with state set to 0).

I didn't write the scripting manual.  So I really can answer that!  I'm sure it is a work in progress. 

Steve

442
Mach4 General Discussion / Re: G31.1, G31.2, G31.3 working?
« on: May 29, 2015, 01:09:47 AM »
Support for the extended probe commands is motion plugin dependent.  I'm not sure who supports them yet.

Steve.


443
Mach4 General Discussion / Re: Mach4 Executing Gcode from LUA
« on: May 29, 2015, 12:55:45 AM »
This isn't a bug. 

mc.mcCntlGcodeExecuteWait() should not be used in a button script if you want the screen to refresh.  When you press a button, the button event is run.  If that button event takes 15 seconds total time, the screen will not refresh for that time.  mc.mcCntlGcodeExecuteWait() does what it implies.  It waits for the given code to be executed.  Meanwhile your button event has not returned and the GUI is frozen.  It is more suited for M code scripts.

mc.mcCntlGcodeExecute() is good for button scripts.  It executes the given G code in a unit of work.  It drops the code off to the interpreter and does <B>NOT</B> wait.  However, It is not meant to be called block by block.  Two consecutive calls to mc.mcCntlGcodeExecute() will act like mc.mcCntlGcodeExecuteWait() because the second call can't be submitted until the first one is done.  If multiple lines/blocks are needed, then they should be concatenated into one single line separated with \n (newline) characters.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\nG0 X5 Y5\n")

Is proper for your last example and your DRO will update.

444
Mach4 General Discussion / Re: MACH4 - Modbus
« on: March 24, 2015, 10:46:42 PM »
We use the WINAPI EnumPorts() function to get the ports.  This API call is part of the printing subsystem.  Check to see if that is disabled/not installed on your machine.  It might be something like "print spooling" or the like.  If it is XP embedded, print support may not even be installed. 

You are the first to see this that I know of.  So I would be very interested in what Windows version you are running. 

Steve

445
Mach4 General Discussion / Re: Mach4 Screw Error Mapping
« on: March 24, 2015, 01:08:11 AM »
Screw error mapping will work for the rack.  But it as yet untested.  So I would not say it is ready for prime time.

Steve

446
Mach4 General Discussion / Re: Mach 4 Feature Request
« on: March 11, 2015, 08:38:49 PM »
The one that comes with Mach 4 is the demo version.  Demo is not a good word, as it is fully functional as it is and does not time out or anything.  Unlicensed would be a better word.  The licensed version would have more features (not all of which I can remember at this time so please do not state that I'm being vague.)  We don't have a demo version that enables the Pro features for a limited time or some such.  Not yet.  Because we simply haven't finished it yet.

When it is done, I think Todd may be able to do a time limited license or something.

Steve

447
Mach4 General Discussion / Re: Mach4 Screw Error Mapping
« on: March 11, 2015, 04:26:09 PM »
Eventually we will have a kinematics module.  But for now we only have screw mapping and that will not do what you want.  :(

Steve

448
Mach4 General Discussion / Re: Mach4 Screw Error Mapping
« on: March 11, 2015, 02:21:41 PM »
I don't think you two understood each other.  What you are talking about is kinematics.  Screw mapping is the mapping the error in a screw or rack in only one axis of travel.

Steve

449
Mach4 General Discussion / Re: Mach4 Screw Error Mapping
« on: March 11, 2015, 12:08:36 AM »
It is new and being tested.  When it runs out good, we will document it in the setup guide.

Steve

450
Mach4 General Discussion / Re: MACH4 - Modbus
« on: March 01, 2015, 03:43:21 PM »
The screen can be changed to anything you like.  It is a bit spartan.  Believe it or not, that screen design is over 15 years old!  It came from my milling machine GUI front end for Galil controllers way back in the 90's (before I stumbled upon Mach3).  When we were developing the Mach 4 core, and hadn't really done a GUI or any sort at that time, we needed something quick and dirty to test with.  So that old code/screen design is what I had from way way back and it became wxMach.  Then when we did the user configurable GUI, the test was to see if we could duplicate wxMach with Mach4GUI.  And we did, as unfortunate as it may seem.  :)

I'll be the first to admit that I have no "flare" for GUI interfaces.  Not my cup of tea, so to speak.  In fact, I can't do anything artistic as it pertains to drawing or anything visual.  I have to leave that up to people that have the talent for it.  I like DOS screens.  And I think the Fanuc screens are "works of art".   :)

Steve