Hello Guest it is October 20, 2019, 08:08:23 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

Yes, you use the screen API.  It is not documented other than you will get the function signatures in the ZeroBrane editor.  The two staples are:

string: value, number: rc = scr.GetProperty(string: ctrlName, string: propertyName)

number: rc = scr.SetProperty(string: ctrlName, string: propertyName, string: value)

The control name is the name you have given the screen element in the Name property.  It is case sensitive.  
The property name is the name of the property as spelled in the property grid.  Value, for example. Or Top, Left, Width, Height, etc...

The value of the property is always a string.  Use tonumber() to convert a string to a number in LUA.  Conversely, use tostring() to convert a number to a string.  Some properties are lists, which have values associated with the string description in the list.  In this case, you will get the value instead of the string description.

Keep in mid that it is ALWAYS better to use the underlying data that backs the screen element instead of the screen element itself, if possible.  For instance, if there is a slider on the screen named "myFROslider" that sets the feed rate override, use mc.mcCntlGetFRO() instead of scr.GetProperty('myFROslider', 'Value").  This is part of the reason that this stuff is not documented.  Because people will use it and not use the main Mach API proper.  I JUST ran into this when support gave me a supposed "BUG" the other day.  It wasn't a bug.  The slider is imprecise because it is pixel based.  If the slider has a range of 0 to 250, but the slider is displayed in less than 250 pixels, well...  there are going to be gaps in the range when using the slider.  Meaning you can start sliding it up from zero and get counts like 1, 2, 3, 5, 6, 7, 9.  So it wasn't a bug at all!!!!  It is why the FRO slider in fresh on my mind.  Yeah, I went down that rabbit hole. 

The other reason is I just don't like writing documentation.  LOL

99% of the time, these scr.* functions are not needed.  If you find yourself needing them all of the time, take a step back and think about how it could be done some other way.  Most of the time, the ONLY time you may absolutely need them is for a screen specific function.  Like the figuring out what tab is current to make the Start Cycle button process MDI commands instead of running a file.  


Mach4 General Discussion / Re: Simple one line MDI required
« on: May 20, 2018, 02:32:01 PM »
What is wrong with Mach4's "Run From Here"?  It works fine for me.  Let me explain what it does.

1.  The first thing it does is do a dry run to and including the line before the selected restart line.  Why?  To get the interpreter state correct.  So if cutter comp was in effect, it would start at the correct offset.  Or any offset, for that matter. 
2.  The dry run is for the interpreter state only, not necessarily the machine state.  If you turned the spindle off, you had better have turned it back on.  Why?  Because you turned it off.  You are master and commander of the machine tool.  And there might not be a line in the G code to tell the control to restart the spindle.  Otherwise, you will drag the cutter through the part and you WILL break something.  At this point, you really can't blame it on the machine control.  :)
3.  Execution will start at the beginning point of the desired line.  If the machine is not already at those coordinates, it will do a feed move to get there.  This includes Z.  This may seem contradictory to the statement above.  But is it?  The last line of the dry run set the starting point of the line.  If the machine is not there, you basically have told the machine to get there. 

Mach doesn't "automatically" restart spindles and such because it has no way of knowing the reason for the run from here.  It could be used to restart a program.  Or it could be used to start a program at a certain place.  You, the operator, know this and it is your responsibility to make sure the machine is in a state to accomplish this.

It is all about understanding what goes on in automatic vs. manual mode.  There is nothing magical about Run From Here.  It will do the same things every time.


The screen script is a screen resource.  Meaning it is part of the screen set.  You edit the screen to edit the script.  It has nothing to do with a machine profile other than the profile determine WHAT screen is use with it.  Fore example, multiple profile could use the same screen set.  Or each profile could use a different set. 

As Craig mentioned, the larger ScreenScript.lua is generated from smaller script snippets in the screen.  So you can't edit the ScreenScript.lua file directly.  See section 5 of "Mach4 Screen Editor V1.0.pdf" in the docs folder.

Usually, if one wants to make a function available for the screen elements, the function is put in the screen load script.  This allows for any button to call that function from their respective event scripts, etc..  So you will see the CycleStart() function in the screen load script. 

Now, do you NEED to put the code into the screen load script?  It depends.  If the code is something that is repetitive and common, then adding it as a function in the screen load script becomes desirable.  But if the button code is very specific to a certain button, then just use the button event script to do the whole job.  A LOT of times, doing all of the the code in the button event script is more clear to the intent.  Readability is important a year from now if you decide to change something and have pretty much forgotten what you are doing now.  :)  It really depends on what is most comfortable/effective for you. 



One thing to do is check the return code from any and all API calls.  These return codes will do a lot of work for you in diagnosing why something doesn't work.  Anything other than zero (mc.MERROR_NOERROR) is an error.

Allan's code is getting the return codes in the variable rc.  That is a step in the right direction, but it is still not actually checking the return code. 

Code: [Select]
local inst = mc.mcGetInstance()

rc = mc.mcJogIncStart(inst, axis, dist)
if (rc ~= mc.MERROR_NOERROR) then
    -- Error condition!  Maybe use SetLastErrror
    mc.mcCntlSetLastError(inst, "jog Start Failed")
    -- And return immediately so that things don't go all pear shaped.

It is a lot more coding, but I can promise you that it will pay off.  Things won't sneak up and bite you.  And it covers all of the bases, so to speak.  If you get into the habit of checking the return codes, it just becomes at some point.  It is especially important on API calls that are to perform an action.  Because you want to handle the case if the action didn't or couldn't happen. 


Mach4 General Discussion / Re: Lua Stats
« on: May 19, 2018, 09:04:21 PM »

Well...  Configure may indeed be working properly.  The library looks like it have several bindings, LUA only being one of them.  If configure can't find the LUA headers and libraries, it may build just the other bindings, etc...  That is what I was thinking.  Cmake is a good concept but I don't think it can ever be implemented perfectly.  Too many pieces to the puzzle a lot of times. 

That plplotluac.i file is what we call an interface definition file.  The C code is generated from that .i file.  Normally, it is processed by LUA itself.  So you may need Lua.exe in the path.  And there may be a place in the configure portion to tell it where that is.  So maybe a REAL LUA installation is needed.


Mach4 General Discussion / Re: Simple one line MDI required
« on: May 19, 2018, 03:08:40 AM »
Ctrl-Enter will execute the MDI.


Mach4 General Discussion / Re: Lua Stats
« on: May 19, 2018, 02:41:55 AM »
Well...  typically the configure process will show you what all is needed.  You may have to check the advanced checkbox in the cmake GUI to see everything.  The module documentation may also shed some light on what is needed. 

I would not modify CmakeCache.txt, as it is generated.  And usually, to modify a make file, you do it through the cmake interface.  You CAN change them, but be aware that the next time you either configure or generate, those changes will be overwritten. 

Anyway, since that checkbox goes away, I suspect it is looking for the LUA 5.2 headers and libraries.  You may have to point cmake to these directories if it doesn't automatically find them in the configure process.  Usually, one will "configure" and resolve all dependencies and repeat as necessary.  Then "generate" the make files.  If the configure process fails for some reason, it will show up in the log.  And possibly highlight the areas in the config list with red.


Mach4 General Discussion / Re: Lua Stats
« on: May 12, 2018, 03:39:17 AM »
Look at the Makefile and look for the target "all"

the format is:


A target may include other targets as dependencies.  Layer upon layer, etc...

Also, search the build directory and all child directories for *.dll.

Sometimes the modules will have more than a DLL file and have quite complex directory structures.  In that case, look for an installation directory path in the Makefile.  INSTALLDIR or something of the like.  You can directly edit the Makefile if needed.  Create a directory and point the installation directory variable to that path.  Then "make install".  All of the build files will be copied to the directory you created with the correct directory structure.  To use them in Mach, you would copy all of those files to the Modules directory of Mach, preserving the directory structure. 


Mach4 General Discussion / Re: Lua Stats
« on: May 12, 2018, 01:05:01 AM »
Usually, you would try and find pre-built binaries that will just drop into the Modules directory.  But it seems that it is "campy" to not provide pre-built binaries.  Like you have to be in their exclusive programmer club to be able to use the library modules.  At least that is my cynical take on it.  :)  But you have to realize that a lot of the guys that write this stuff are unix/linux oriented and they rather hate Windows with a passion.  EVERYTHING is built from source in the unix/linux world.  So pre-built binaries only exist in the Windows world.  

But you can build it with the development tools.  But if you haven't done that, it will be a steep learning curve.  However, it is not rocket science.  Anyone can do it, but it WILL be like poking the proverbial knitting needle through your eardrums.  That, I can promise you!

To build this stuff, you need the compiler (MinGW), the library source, any other library source that the target one depends on (if any), LUA 5.2 headers and libraries, and cmake.  There is a cmake GUI that makes it a little less painful.  In the world of cmake, you point to the source files, point to a build directory (usually one that you create), and "configure".  Which basically generates make files for the chosen compiler.  Then you have to go to the old command prompt, change into the build directory, and type "make".  The make program reads the generated make file (usually called Makefile without an extension) that cmake produced and that, in turn, will produce the binaries.  Cmake is all a an attempt at making the source compile-able with any compiler on any platform.  But...  to me, it is a huge pain in the ass.

You don't let Mach know anything other than placing the resultant LUA module DLL into the modules directory.  Then you use the module in your scripts, you "require" the module.  

graph = require "plplot"

If the module DLL is called plplot.dll.  Then you access the functions with the graph variable.

But wait...  there's more!  LUA 5.2 is different than LUA 5.0 and 5.1 where modules are concerned.  If the module source is not setup to compile with LUA 5.2, then you will have to "port" the source to something that is compatible with LUA 5.2  This generally involves changing the call to luaL_register() to use lua_newtable() and luaL_setfuncs() instead.  Here is an example from a LUA library that I recently compiled (and had to port).  

Code: [Select]
  luaL_setfuncs(L, functions_tb, 0);
  luaL_register(L, LIBNAME, functions_tb);


I buy dead stuff and fix it.  I'm successful about 75% of the time.  You have to watch out for stuff made in the 90s because they will most likely have the leaky surface mount electrolytic caps that can corrode the traces on the PCBs.  Sometimes beyond repair  Tek TDS500 series scopes, for instance.  But my wife HATES this stuff because the 25% that I can't fix seems to stay around.  :)  Plus I usually keep the stuff I do fix as well.

I got a Tek 492AP spectrum analyzer for free.  It was all ganked up with display storage issues.  But it is up and running like a new one now.  Up to 21 GHz!!!  That was my best fix ever.  Next was a Fluke 6080 signal gen from eBay.  That one cost less than the shipping to get that heavy beast to my door.  It is now running 100% as well.  So eBay can be even cheaper if you can fix the stuff.  I find that capacitors are almost always the culprit, no matter what vintage/type they are.  Even the good non leaky electrolytic caps let go with high ESR.  Capacitors are just little serial killers that are just waiting for a chance to pounce.  Nasty little beasts! 

But with eBay, I have a complete RF lab for less than the cost of a new HF radio.  eBay is good for machine tool stuff too.  But you better know something about what you are looking for, in call cases.

eBay can be frustrating though.  I simply hate the "buy it now" listing types.  Because most will invariably try to sell something dead for 10 times what it is worth and the listings clutter up your search for months on end!