Messages

601

Mach4 General Discussion / Re: Using a button script to set jog increments etc

« on: May 20, 2018, 12:52:27 PM »

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. 

Steve

602

Mach4 General Discussion / Re: Using a button script to set jog increments etc

« on: May 19, 2018, 09:16:33 PM »

Striplar,

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.
    return;
end
...

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. 

Steve

603

Mach4 General Discussion / Re: Lua Stats

« on: May 19, 2018, 09:04:21 PM »

Craig,

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.

Steve

604

Mach4 General Discussion / Re: Simple one line MDI required

« on: May 19, 2018, 03:08:40 AM »

Ctrl-Enter will execute the MDI.

Steve

605

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.

Steve

606

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:

target:dependencies

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. 

Steve

607

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]

#if LUA_VERSION_NUM > 501
  lua_newtable(L);
  luaL_setfuncs(L, functions_tb, 0);
  lua_pushvalue(L,-1);
  lua_setglobal(L,LIBNAME);
#else
  luaL_register(L, LIBNAME, functions_tb);
#endif

Steve

608

Mach4 General Discussion / Re: Out-Of-Band Axes in Hobby vs Indusrial

« on: May 11, 2018, 07:56:10 PM »

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! 

Steve

609

Mach4 General Discussion / Re: Out-Of-Band Axes in Hobby vs Indusrial

« on: May 11, 2018, 06:55:59 PM »

I'm going to do some more testing with this and get my PLC and Mach changing the OB Axis position to make sure that it will do what I want.   Is this still considered Hobby??? lol

Well...  hobby can be/is expansive.  For instance, one of my hobbies is ham radio.  People can get into that hobby and just buy radios and antennas just to talk.  But others. such as myself, get hopelessly drawn in and end up having tons of test equipment following them home and/or start building solid state amplifiers and power supplies. 

So...  I think you are building the equivalent of a solid state amplifier. 

Steve

610

Mach4 General Discussion / Re: Out-Of-Band Axes in Hobby vs Indusrial

« on: May 11, 2018, 06:12:42 PM »

Further, what other gems have been introduced that we have no idea even exist?

One may NEVER know... 

I usually don't document an API call until it has been fully tested.  There are tons of undocumented API calls in Windows too, and I suspect for the same reason.  However, the reason THIS one (and a few others) is not documented is because I had to re-install Windows (long story) and I lost all of my license keys for a lot of my development software.  The Help documentation software included. 

I did have a backup, but some of the stuff is stored in some mysterious location.  Typically, the CAD/CAM stuff allows for you to "park" your license, reinstall, and then pull the license back down.  So those were easy.  But other things were not so easy and/or you just forget that they are licensed.  Anyway, I have that all sorted now.  But I detest writing documentation because people then complain that it is not good enough, etc...  So I have to be in a particularly "I don't give a rip" mood before I can motivate myself to write that stuff. 

Steve