Hello Guest it is May 26, 2019, 10:31:47 PM

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


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! 


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.  :)


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.  :)


The motion controller may not be reporting feedback for motors on the OOB axes, if that is the case.  It should.  Make sure you are passing the correct value for the motor ID.  Check the return code of the API function!!!  :)  See if there is an error code.  If all is well, then there is something wrong with the motion plugin.  Typically, you would use mcAxisGetMachinePos() to get the position in machine units for the axis.  mcMotorGetPos() for the motor that is attached to the OOB axis should return the motor counts.  There is no coordinate system other than the machine coordinate system for OOB axes. 

The screen has DRO types that should show the machine position of the OOB axes.  Also there is a DRO types to show the counts and velocity of the motor as well. 

However, one could track the position of the motor with a script variable.  Home it first.  This is position 0.  Then track all moves (adding to the variable for incremental or explicitly setting the position for absolute).