Hello Guest it is September 29, 2020, 01:26:00 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

Mach4 General Discussion / Re: Export tool table
« on: May 15, 2014, 08:14:25 PM »
The LUA stuff is dry reading isn't it?!?!?!  I bought the books.  I don't think I finished any of them.  I instead search the internet for examples.  I can stay awake that way...


Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 15, 2014, 01:15:28 PM »
I think I have mentioned it before, but it is worth mentioning it again.  There are two instances of LUA.  One in the GUI and one in the mcLua plugin.  The mcLUA plugin is there so that M codes will run regardless of what GUI is driving the core.  It is NOT connected to the Mach4GUI in any way.  However, communication between the two LUA instances is possible with Mach registers.  But mcLua plugin based scripts and functions cannot see the Screen scripts as the screen scripts are imbedded into the screen set.

Mach 4 is written so that any developer can write their own GUI for the core.  It can be written in C++, C#, VB, or any other language that supports loading of DLLs.  We have two GUIs at the moment as an example of this.  Mach4GUI and the wxMach "static" GUI.  The static GUI is just that, static and not changeable.  I do have a sample GUI written in C# that I played with.  wxMach does not have a configurable screen and has no screen based scripting functions.  It does, however, have a PLC script.  So that is the reason for the separate LUA instances.

So on to global functions...  

If you want a global function that can be called from any screen object script, put the functions in the screen load script.  Then they will be available to all screen object scripts.

If you want a global function to be available to all M code "macro" scripts, put a file in the macro directory containing the global script functions.  The file can be named anything as long as the extension is ".mcs".  Say you named the file "myGlobalScripts.mcs".  You can write this file using the mcLuaEditor.  It is prudent to test the scripts (debug) and "compile" the file inside the mcLuaEditor to check for syntax errors.  The act of compiling the *.msc file will generate a *.mcc binary file.  Then when you press cycle start the first time, ALL of the *.mcc files in the macros directory will be combined into one LUA program called wxLua.mcc.  This is the chunk that gets loaded.

What if you want the same global functions in the screen and macro scripts?  You can duplicate the code in the screen load and the macros directory or you can "include" the code from the file system in each LUA instance.  This "shared" code should be put in a global directory.  Meaning not a profile's macro directory.  Something more along the lines of a "Modules" directory in the Mach4 installation.  That way all profiles or screens in you installation can access it regardless of if you happen to delete a profile or two.  But I won't get into how to do all of this.  The LUA manuals cover it.  

Oh another thing...  DO NOT expect any scripts that Brian or I post to just work.  They are hand typed generalized examples of how to get something done.  They are usually typed on-the-fly as we answer a post and they may not be perfect.  They are close.  But the only way to ensure they are perfect is to put them into the LUA editor, compile them, and tests them.  That is not something we have time to do when answering a posts.  It is an exercise for the user to make them work. 


I thought sense the Keyboard plugin could call an internal function like X+ it should be able to call the internal functions such as Cycle start. 

But it seems it can't without Lua scripting.

Thanks (;-) TP

Not yet.  I have some things in mind for it.  That plugin will get more love soon.


Yes.  It can.  You might have to do a little scripting.  But it is possible.


Keyboard plugin.  I changed it to work better for you guys.


On the MachSupport website.  I gave the link above but botched the build number.  I can't edit that post for some reason...  So here it is again.  This is the same link that you will get to if you download Mach 4 from the website by hitting the download button.



Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 14, 2014, 01:28:07 PM »
If the macro script is not wrapped in a function, then that is what you will get.

This is what a macro should look like.  Notice at the bottom it has code that detects the editor so that it will actually run the M40 function.

Code: [Select]
function m40()
    mc.mcCntlSetLastError(inst, 'I'm in M40!!!!')

if (mc.mcInEditor() == 1) then


There is a new 1767 out there now.  It should be better.  There were some "issues" in the original.  

Also, the greyed out screen buttons were testing the "Enabled States" property.  There is still a slight issue with that which I'm working on now.  Just clear the Enabled States property on the controls that are not working correctly and that should clear them up.


Mach4 General Discussion / Re: ScreenSet Question
« on: May 13, 2014, 06:17:43 PM »
Ok, to answer some questions...

Eventually, I had in mind the ability to shuffle the screen objects via drag and drop in the screen tree.  But in the interest in actually getting Mach 4 done, that went away for a future project.  The idea is to actually USE Mach 4 at some point for it's intended purpose!  :)  So we got the screen editor "functional".  And I have seen some AWESOME screens, so it is indeed quite functional.  Yes, it can stand some more bells and whistles, but they will come in time.  The motion plugins are the focus now though.

Also, there will be an import and export functionality.  The code is stubbed in right now.  I just have not turned it on or tested it.  But what that will allow you to do is export Group Boxes or pages.  Say a developer of some specialized hardware has a screen page that works with all of his gadgets on his device.  He can export that page and the user of said hardware can import that page into his screen set.  That is one example.  Another would be copying a page between two screen sets because we don't allow running multiple instances of the GUI.

Same thing for group boxes.  This is probably the better approach to use for "sharing" controls and functionality.  Because some screen sets (like the current Mach screen set) don't have multiple pages.

But like I said...  We are trying to get the motion controllers going at this time.  So all this may be a while.  But just to let you know where it will get to one day.


Mach4 General Discussion / Re: MACH4 - Modbus
« on: May 13, 2014, 05:56:43 PM »

You are adding two handles that sum to a number larger than a 16 bit register will take.  The internal Mach register can store that number easily.  But the 16 bit register in the PLC cannot.  It also looks like the Rhr3 is also part of a read function.  The internal Mach register will not get updated unless the value ON the PLC changes.  Yet is it possible to SET the value internally from the Mach side.  So if you wrote a number in the simulator register 40003, it would have changed the value in the Register Diagnostics window.

The correct way to do the register read is with two API calls.

local hRhr1 = mc.mcRegGetHandle(inst, "modbud0/Rhr1");
local valRhr1 = mc.mcRegGetValue(hRhr1);
local hRhr2 = mc.mcRegGetHandle(inst, "modbud0/Rhr2");
local valRhr2 = mc.mcRegGetValue(hRhr2);
local hRhr3 = mc.mcRegGetHandle(inst, "modbud0/Rhr3");
mc.mcRegSetValue(hRhr3, valRhr1 + valRhr2);

Rhr3 should == 24564 which is within the 16 bit range.

An enterprising LUA programmer can shorten the 2 API calls with something like this:

function ReadReg(regName)
    local inst = mc.GetInstance();
    local hReg = mc.mcRegGetHandle(inst, regname);
    local val = mc.mcRegGetValue(hReg);

function WriteReg(regName, val)
    local inst = mc.GetInstance();
    local hReg = mc.mcRegGetHandle(inst, regname);
    mc.mcRegSetValue(hReg, val);

Those are hand written on-the-fly functions so they may not be totally correct.  But put something like them in the Screen load script and you can access them from any screen/object script. This will make things a bit easier in the code like:

local valRhr1 = ReadReg("modbud0/Rhr1");
local valRhr2 = ReadReg("modbud0/Rhr2");
WriteReg("modbud0/Rhr3" valRhr1 + valRhr2);