Messages

831

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 07:32:45 PM »

The Keyboard plugin was one of the first plugins we developed.  So it was made prior to the advent of the Mach Register concept.  Just a FYI as to why it is like the way it was. 

832

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 07:30:15 PM »

You can get the state of the keyboard plugin with the output.  However, since it may not reflect the state of the keyboard plugin at startup, you have to set it to something first.  This is why that call was made the FIRST time the PLC script ran.  Then, once the output is set to on or off, you can then get the output state and it will reflect the status of the keyboard plugin.

Now, there are two outputs that the keyboard plugin exports.  Keyboard/Enable and Keyboard/EnableKeyboardJog.  One enables/disables the entire keyboard key mapping and the other will just disable the jog key mappings but leave the rest of the key mapping working (keyboard must be enabled). 

So it can work.  But...  The register is the better way in case one ever just wants to check if the keyboard mappings are enabled without setting that status first.  In any case, there will be a register called "KeyboardControl/Enabled" that will reflect the state of the keyboard mappings.  If you set that register to 1, it will enable the mapping.  Setting it to 0 will disable all of the mappings.  Reading it will always reflect the status of the mappings. 

Steve

833

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 04:33:05 PM »

Because getting the state of an output is not logical.  You set outputs.  If you get the state of an output, the result is undefined because there isn't really a backing store for the state at the device level.  Meaning if you get the state of an output, it may be different than the actual state of the output on the device.  

I'm adding a register that will allow both getting the status and controlling the keyboard plugin.  A register actually has a backing store for the value.  

Steve

834

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 02:12:28 PM »

The keyboard plugin exports an output that can be used to enable/disable the keyboard plugin.  It is not necessarily a reflection of the enabled status as nothing in the keyboard plugin will actually set the value of this output because it is well...  an output.  It is a control mechanism that the GUI can use to enable/disable the keyboard functionality.

Code: [Select]

local inst = mc.mcGetInstance()
local hIo, rc = mc.mcIoGetHandle(inst, "Keyboard/Enable")
if (rc == mc.MERROR_NOERROR) then
    --the keyboard plugin exists and the plugin is enabled and we found the plugin output.
    mc.mcIoSetState(hIo, 1) -- Turn the keyboard enable output on.  The keyboard plugin will now accept keyboard input.
    mc.mcIoSetState(hIo, 0) -- Turn the keyboard enable output off.  The keyboard plugin will not accept keyboard input.
end

But currently, there is nothing that will get the status of the keyboard plugin.    Other than looking the task bar icon.

I will add a status register that can be read to determine the status in a future build. 

Steve

835

Mach4 General Discussion / Re: Can i edit or add to a Predefined Macro?

« on: January 03, 2017, 11:50:16 PM »

You CAN create a M30 macro.  If you do, it will REPLACE the stock M30 functions.  So when you write it, you will need to put any of the original functionality of the stock M30 into the custom M30 macro. 

The stock actions for M30 in mill are:

1. Stop the spindle.
2. Turn off cutter comp.
3. Turn off mist.
4. Turn off flood.
5. End processing (Cycle Stop).
6. Rewind.

Note: #5 and #6 are preformed even if a custom M30 macro exists.  The entire custom M30 macro will be executed and then #5, followed by #6, will be executed. 

Code: [Select]

function m30()
local inst = mc.mcGetInstance()
mc.mcCntlSetLastError(inst, "This is my m30 macro")
end

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

If you used that file, when G code calls M30, it will simply print they message, end processing, rewind, and do NOTHING else.

So, to recap: 
1.  If the m30.mcs macro exists in the macros directory, it will be used in lieu of the stock M30 actions.
2.  If a custom M30 macro is used, it must include all of the functionality you wish as none of the stock M30 actions will be performed otherwise except for Cycle Stop and Rewind.

Steve

836

Mach4 General Discussion / Re: Mini ITX Motherboard for Mach4

« on: January 03, 2017, 11:21:52 PM »

For those that may be interested, the Atom board that I am using is the D2700MUD.  Affectionately called the "mud" board.  Windows 7/32bit.  Mach 4 runs fine on it and it does have the Intel NIC on-board.  Even so, the default setup for the NIC was tiny transmit buffers.  At least the Intel Ethernet driver would let you bump them up though (and I had to). 

So the little Atom board is well...  diminutive as compared to modern day (this week LOL) desktop boards.  But it is light years faster than the 4MHz 68020 processor in the original YASNAC control my machine had on it.  It was a 1980s tape reader.  The Atom board will run FAR larger programs than that tape real could ever hold.  But...  it might not be a good choice for a board to run huge 3D files like router guy do with plaques and the like.  So pick your system boards carefully with the desired use of the machine kept in mind.  I would NEVER suggest an Atom board for a router where the user wishes to run HUGE 3D files on it.  Loading G code files is definitely a function of the processor and disk I/O speeds.

But for metal milling jobs (relatively small G code files as compared to 3D router files), the Atom is plenty powerful.  Just make sure the NIC is a good one.

Steve

837

Mach4 General Discussion / Re: re-mapping motors and home switch inputs through lua script

« on: January 03, 2017, 11:00:57 PM »

The config dialog just reads the profile's Machine.ini file and displays those values.  NOT values that may have been modified at run time by scripts and API calls.  When you hit OK (or Apply) on the config dialog, the profile's Machine.ini will be updated with the values in the dialog (changed or not) and then when the dialog closes, the core will re-read the profile's Machine.ini.  Thus "undoing" any run time modifications.  Even if you hit CANCEL in the config dialog, the run time modification will be undone, as the core will ALWAYS re-read the profile's Machine.ini file.  The core does not know if you pressed OK, or CANCEL on the configuration dialog.  

If you modify the values at run time and then shutdown Mach (without entering the config dialog), the modified values WILL be written to the profile's Machine.ini at shutdown and then next time you start Mach, those values will be used.  

So if you ever want to see the run time modifications in the config dialog, you must also modify the Machine.ini file with the mcProfileWrite*() functions (with the appropriate keys and values) and call mcProfileFlush() afterwards to write them to the disk BEFORE entering the config dialog.

Steve

838

Mach4 General Discussion / Re: mcCntlGetGcodeFileName ...Crashes M4

« on: January 03, 2017, 10:44:50 PM »

We have an old build that runs on Linux.  In fact, we demoed Mach 4 at IMTS 6 years ago on a Linux machine.  So yeah, it will run on other platforms.  But Linux is not where the majority of our customers are at the moment.  So we have been concentrating on the Windows platform.  I hope to have a Linux build by the end of the year though.  Once we get that going, we'll keep it in sync with the Windows build from that point on.  However, the Linux build will be more for OEMs and such and run on a dedicated distribution of Linux.  We simply can't get into the world of supporting all of the flavors of Linux.  We will probably choose a CentOS distribution.  We may make it available to end users on a strictly "you are on your own" kind of thing with ZERO support from our ticketing system or phone support (meaning only forum based support from other users).

And from Linux to Mac.  I can't imagine a Mac being used as a dedicated machine controller, but we do get questions asking if we support Macs all of the time.  I have a Mac, so I might just make it run on it just for the fun of it.  

As to your case question, I would use the LUA string.lower() function to lcase the string returned into pathCode.  e.g.

Code: [Select]

local pathCode=mc.mcRegGetValueString(hreg);
pathCode = string.lower(pathCode);
...

But only IF you WANT to convert it to lower case.  It will not matter for Windows.  But it will matter for Linux and Mac.  So if you put the filename into the register with the correct case, then I would suggest NOT converting it to lower case in the event you ever run the code on a Linux or Mac machine in the future. 

Steve

839

Mach4 General Discussion / Re: mcCntlGetGcodeFileName ...Crashes M4

« on: January 03, 2017, 08:49:10 PM »

An explanation on the lower case M code functions:

When the interpreter reads a line/block of G code, it first converts the whole line to lower case.  It then removes all of the spaces in the block.  So

G00 X1
S2000 M03

becomes

g00x1
s2000m03

So when the M3 macro is called, the core will look for a macro named "m3.mcs" and look for a function named "m3()" within it.  On Windows, the filenames are NOT case sensitive and it will find a file named "M3.mcs" or "M3.MCS" or any other combination of upper and lower case letters.  However, it will still look for a lower case function name!!!  Because that is what is fed to LUA and LUA is case sensitive. 

So the convention is now to use lower case names for both files AND functions to maintain cross platform compatibility. 

Steve

840

Mach4 General Discussion / Re: What is this error???

« on: January 03, 2017, 08:25:00 PM »

Daz,

When you hit Cycle Start, the FIRST thing that is done by the core (LUA plugin) is to look at all of the .mcs files and compare them to the date/time of the byte code .mcc files.  If a .mcs file is newer than its' accompanying .mcc file, the .mcs file is assumed to be modified and the LUA plugin tries to recompile it.  Once all of the .mcs files are compiled into .mcc files, all of the .mcc files are rolled up into one big chunk called mcLua.mcc.  If any of this fails, it will result in a MERROR_NOT_COMPILED error return.  So SOMETHING is causing it.  Mach will continue to run on the old mcLua.mcc file if it cannot compile a new one.  

You are correct that the screen LUA scripts are just snippets that get rolled up into a larger script.  That script is what you can see in the Diag menu.  When the GUI starts, it takes all of the screen element scripts and rolls them up into one big script.  So you really can't edit that one because it is generated.  Any changes you made to it would get overwritten once you restarted the GUI or made changes to the screen in the editor.  

I'll try and make a way to find the errors more easily.  Like blanking out the failed .mcc file to zero bytes if it failed to compile.  That way, it would be easy to see which .mcs file has the error in it.  

Steve