Hello Guest it is February 28, 2020, 08:15:39 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

Mach4 General Discussion / Re: Q word missing error when running G83?
« on: January 11, 2017, 10:32:44 PM »
The CamBAM post processor is producing incorrect G code.  G81 and G93 are modal G codes.  You turn them on, then cancel them with G80.  So what Mach 4 is asking for is correct.  Previous builds of Mach 4 probably didn't catch that error.  We have been improving the error catching abilities of the interpreter and it looks like it messed things up for you, unfortunately.  :(  But it is probably a rather simple edit of the CamBAM post processor to fix the issue.  Or maybe try a generic Fanuc post processor to see if it may be better.


I have never heard of Mach doing this.  Why don't you tell us about your hardware and stuff (motion controller, OS, Mach build, etc...)?  Because the more information, the more everyone might be able to find a solution. 


Mach4 General Discussion / Re: Tool Table Import?
« on: January 05, 2017, 03:38:40 PM »
G10.  Look at the Milling Manual in the docs folder to get the syntax.  Some CAM programs will export the tool table into a G code file that includes G10.  Then the G code program is simply run once to set the tool table. 

If your CAM program can only output the .CSV file, then you could write a "translator" in LUA script to go from the .CSV contents to G code with G10. 

The other way would be to read the .CSV file in a LUA script and use the API to modify the tool table. 


Mach4 General Discussion / Re: Fusion360 Post processor for Mach4
« on: January 04, 2017, 11:42:22 PM »
Mach 4 is more Fanuc compatible than Mach 3.  Patterned after a 21i.  Cutter comp memory type C.  For regular XYZ programs, the Mach 3 post is probably adequate.  If not, start looking through the Fanuc posts.

Lathe/Turn is where the more major differences from Mach 3 are.  Specifically G76 threading.  Mach 4 accepts both Fanuc G76 1 line and two line formats.


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

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. 


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.  


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.

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. 


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")

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

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.


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.