Hello Guest it is September 20, 2020, 08:46:30 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

Legal tool number range?  That is pretty much defined by you, or the tool changer.  But there no hard rule to any of it.  For instance, my ATC is a 16 pod geneva drive carousel.  Tools 1-16 occupy the ATC and if 17 and above it called out, my M6 script goes into manual tool change mode.  VERY flexible.  Since I know my tool changer only holds 16 tools, that is the number I hard code in the M6 script.


The error is what it says.  You can't use wxMessageBox in any thread other than the main thread.  But it is a programmer error and not a bug type of error.  You can use wxMessageBox() in the PLC script because the PLC script is run in the main thread of the GUI. 

Using wxMessageBox() isn't a really good idea inside of Mach.  It is there because it is part of wxLua.  But just because it is there doesn't mean it is a good thing to use.  Use mc.mcCntlSetLastError() instead.  Or have the PLC script look at a flag or something to use wxMessageBox().


You only get that error if you close the whole application.  Just exit the screen editor by toggling the Edit Screen menu item. 


Mach4 General Discussion / Re: Will Mach4 work on This CNC Router?
« on: July 12, 2019, 02:14:17 AM »
Yes.  The important part is the UC100 is compatible with Mach4.  Get the UC100 plugin for Mach 4 here: http://cncdrive.com/UC100.html


Mach4 General Discussion / Re: Mach closing randomly 4162
« on: July 10, 2019, 04:14:45 PM »
Since it is in a module, I believe it has it's own 200 count limit.  But we do the table thing in modules too. 

Chad:  Yeah, something strange is going on because we haven't had any complaints about 4162 just closing like that on it's own.


Mach4 General Discussion / Re: Mach closing randomly 4162
« on: July 10, 2019, 03:37:35 PM »
Yes, that is the correct usage.  :)


Mach4 General Discussion / Re: Mill Profile Initialisation String
« on: July 10, 2019, 01:47:32 PM »
Oops...  there isn't a mcCntlGetResetCodes() API function.  :(  It is actually a compilation of a few constants and some profile settings in the order presented below.  I'll add a "Get" function at some point. 

The constants:
G40 // Always add G40 before G20 or G21!
G80 // Always add G80!

These next ones are in section/key, default format:
DefaultMode/UnitsMode, G20
DefaultMode/TraverseMode, G00
DefaultMode/MotionMode, G64
DefaultMode/DistanceMode, G90
DefaultMode/CenterMode, G91.1
DefaultMode/FeedMode, G95
DefaultMode/Plane, G17
DefaultMode/CanedCycleRetract, G98
DefaultMode/SpindleMode, G97S0
DefaultMode/UserDefaults1, ""
DefaultMode/UserDefaults2, ""

So construct a string by adding the constants and reading all of that from the profile, append your desired work coordinate system, and then set the new reset codes with mcCntlSetResetCodes().


Mach4 General Discussion / Re: Mill Profile Initialisation String
« on: July 10, 2019, 03:27:36 AM »
The initialization string is read when the core is loaded by the GUI.  It is then sent to the interpreter when the control is Enabled for the first time AND when the control is Reset.  You can change the init strings that are sent to the interpreter when reset by using mcCntlGetResetCodes() and mcCntlSetResetCodes() functions.  This string is initially built from the contents of the control configuration dialog's General tab. 

Basically, you could intercept the OSIG_MACHINE_ENABLED signal in the signal lib, get the reset codes, modify by adding your desired coordinate system (there won't be one in the reset codes unless you added it), and then set the new reset codes.  Then call mcCntlReset() manually to get them added to the interpreter.  Then forever after during the Mach session, every time you hit reset, the control will get your desired coordinate system until you change the reset codes.  If you shut down Mach, the modified reset codes will NOT be saved.  You will have to take care of saving the desired coordinate system at screen unload and retrieving it at screen load before modifying the reset codes. 


Mach4 General Discussion / Re: Mach closing randomly 4162
« on: July 10, 2019, 02:26:00 AM »
Oh, one more thing.  In your tool change mcs file, there are a lot of locals declared and initialized.  There is a finite limit to the amount of local variables you can have in any one chunk.  The default limit is 200 and we don't change it.  Since all of the macro scripts are compiled into one chunk, you have to be careful with locals.  It would be better to declare one local table in the m6 function.
Code: [Select]
function m6()
local inst = mc.mcGetInstance()
local rc

local vars = {
    Alarm = mc.mcSignalGetHandle(inst, mc.OSIG_ALARM)
    AlarmState = 0
    RequestedTool = mc.mcToolGetSelected(inst)
    CurrentTool = mc.mcToolGetCurrent(inst)
    ToolChangePosition = mc.mcCntlGetPoundVar(inst, 500)
    RequestedToolPocket = mc.mcToolGetData (inst, mc.MTOOL_MILL_POCKET, RequestedTool)

Then use them like vars.Alarm and vars.AlarmState, etc...

I have seen some strange thing happen when the declared local variables exceed the 200 count limit.  And there is NO ERROR that says you have exceeded the limit!  I found out the hard way. 


Mach4 General Discussion / Re: Mach closing randomly 4162
« on: July 10, 2019, 02:15:32 AM »

What error checking are you reffering to?  Give me a line number for an example in one of the files you posted.

What IS different between 5.2 and 5.3 is that 5.3 has a new integer type.  This mainly affects formating a string with "%d" or "%i" formats.  You can't format a LUA number (real number) with those anymore.  It will fail.  You have to use "%f" with old school LUA numbers.  To print only the integer portion of a real number, use "%.0f" instead of "%d".  So look for code that has printf statements with "%d" and check that.