Messages

531

Mach4 General Discussion / Re: Un-Supported wxNumberEntryDialog

« on: January 20, 2019, 07:46:31 PM »

I miss the Digital Machinist shows.   

The wxFormbuilder stuff isn't that hard once you realize that it puts all of the GUI code in one table called UI (I guess for User Interface).  You just paste all of that generated code into your LUA file and call it, basically.

Steve

532

Mach4 General Discussion / Re: Un-Supported wxNumberEntryDialog

« on: January 20, 2019, 03:23:17 PM »

Just use a text entry and convert the text to a real with tonumber().

One thing that you guys may not know is wxFormBuilder generates code for wxLua.  Just build you own dialog in wxFormBuilder and do what ever you need.  There will be a learning curve, but it is worth it. 

Steve

533

Mach4 General Discussion / Re: Plasma table - Dry Run feature in M3 macro

« on: January 19, 2019, 04:35:29 AM »

Craig!  I couldn't have said it any better.  In fact, I might not have said it as good! 

Steve

534

Mach4 General Discussion / Re: Plasma table - Dry Run feature in M3 macro

« on: January 18, 2019, 03:57:20 AM »

The m3 macro is the perfect place to put this type of code for plasma.  Basically, you want the m3 macro to light the torch and check that it is ok before proceeding, right? 

I have flushed out the code a bit more.  Notice the comments I put in there about the instance and the error checking. 

Code: [Select]

function m3()
    local inst = mc.mcGetInstance('Custom M3 macro'); -- always get the instance first

mc.mcCntlSetLastError(inst, "Dry Run feature test");

--INITIALIZE OSIG_OUTPUT0 (INTERNAL SIGNAL FOR DRY RUN BUTTON)
local hsig
local rc
hsig, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT0);
-- It is important to check the API return codes (rc). 
-- You can handle errors gracefully.
if (rc ~= MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, "Could not get signal handle!");
mc.mcCntlCycleStop(inst); --end program *****
mc.mcSpindleSetDirection(inst,mc.MC_SPINDLE_OFF);
return
end

--READ THE STATE OF OSIG_OUTPUT0, SET buttonstate VARIABLE
local buttonstate
buttonstate, rc = mc.mcSignalGetState(hsig);
if (rc ~= MERROR_NOERROR) then
mc.mcCntlSetLastError(inst, "Could not get signal state!");
mc.mcCntlCycleStop(inst); --end program *****
mc.mcSpindleSetDirection(inst, mc.MC_SPINDLE_OFF);
return
end

--Begin modified M3 for ARC OK signal detection
mc.mcSpindleSetDirection(inst, mc.MC_SPINDLE_FWD);

--DRY RUN LOGIC SECTION
if (buttonstate == 0) then
mc.mcCntlSetLastError(inst, "Dry Run feature not activated, cutting will commence");
mc.mcCntlSetLastError(inst, "m3 waiting for Arc");

local returncode = mc.mcSignalWait(inst, mc.ISIG_INPUT62, mc.WAIT_MODE_HIGH,2);

if (returncode == mc.MERROR_TIMED_OUT) then
mc.mcCntlSetLastError(inst, "Arc does not respond");
mc.mcCntlCycleStop(inst); --end program *****
mc.mcSpindleSetDirection(inst, mc.MC_SPINDLE_OFF);
else
mc.mcCntlSetLastError(inst, "m3 Arc OK");
end
else
mc.mcCntlSetLastError(inst, "Dry Run feature activated, torch will not fire");
end
end

if (mc.mcInEditor() == 1) then
    m3();
end

Steve

535

Mach4 General Discussion / Re: Mach 4 demo?

« on: January 17, 2019, 11:33:09 PM »

You may have to enable the ESS plugin first (Configure->Control, then the plugins tab), then restart Mach.  Then you will be able to configure the ESS plugin at that point (Configure->Plugins).  Once the ESS is up and running, you need to select the ESS as the motion device (Configure->Select Motion Dev), then the plugins tab), then restart Mach. 

These same things (similar) had to be done with Mach 3, but it may have been so long since you did it you forgot!    All of the Documentation is in the Docs folder below the installation folder.  "Mach4 CNC Controller config.pdf" is the one most pertinent to this subject.  But reading through the rest of them as well will give you a leg up understanding the differences between Mach 3 and Mach 4. 

Steve

536

Mach4 General Discussion / Re: Understanding Mach 4 LUA scripting capabilities

« on: January 17, 2019, 03:46:19 AM »

In addition to what Chad and Craig have written:

For #2.  In the Modules directory, you will find several useful LUA modules.  One of which is luars232, a serial library for LUA
For #3.  The PLC script will not hamper machine performance.  LUA is fast fast fast!  It is why we chose it.  Most PLC scripts run in well less than a millisecond.  Now, that doesn't mean that bad code could not cause a problem.  So the fix for that is "just don't write bad code." 
For #5.  Yes.  But check the Modules directory of the install (#2 above) because we provide several of these "libraries" (but more properly called modules).  LUA modules ARE the way to call C code.  Writing one is beyond the scope of any of our manuals though.  But there are tons of resources out there about that. 

BTW guys, the development versions of Mach are now using LUA 5.3.    Be sure to read up on the difference between 5.2 and 5.3. 

Steve

Steve

537

Mach4 General Discussion / Re: cant add the Mach4CoreDll to c# project

« on: January 15, 2019, 11:03:56 PM »

The DLL isn't a COM object or an assembly.  It is an old school (non .Net) API DLL.  So you cannot add it as a reference like that.  You have to use it like you would any WINAPI type DLL.

e.g. this will define mcAxisDeref()

Code: [Select]

[DllImport("Mach4Core.dll", CallingConvention = CallingConvention.StdCall)]
        [return: MarshalAs(UnmanagedType.I4)]
        public static extern int mcAxisDeref(
                [param: MarshalAs(UnmanagedType.I4)]  int mInst,
                [param: MarshalAs(UnmanagedType.I4)]  int axis);

Steve
 

538

Mach4 General Discussion / Re: G93 Inverse Time

« on: January 15, 2019, 05:24:46 PM »

Yes, feed rate is units per minute.

However, it isn't necessarily the number of decimal places that you should be concerned with, motion controller wise.  In the end, a trajectory is boiled down to the number of counts/steps the motor should move in a window of time.  The most common "time slice" is 1 millisecond.  I don't know what motion controller you are using, so I can't give any advice on what it may or may not do. 

For the purposes of this discussion, let's assume that is is running a 1 millisecond time slice.  To get continuous motion on the motor, a minimum of 1 count per time slice is needed.  Say the counts per unit is 10000 (inch).

10000 per inch == .0001" per millisecond. 
.0001 * 1000 == .1000" per second
.1000 * 60 == 6.000" per minute. 

That is for the case of each time slice moving 1 count per millisecond.  Obviously, the more counts per unit (higher resolution), the slower you can go with the smoothest possible motion.  But for most things, we have to compromise on the smoothness of the motion to go slower.  Say like a count every other millisecond (3.0000" per minute).  The time the motor spent moving would be equal to the time the motor wasn't moving.  In other words, 1/2 of the time, the motor would move.  But if you extend that out to a count every 4 milliseconds (1.5000" per minute), the motor is moving 1/4 of the time.  And so on and so forth.  At what point does the motion controller consider the motion as stopped?  No movement in 10 milliseconds?  20? 100?  That is what you have to worry about.

Steve

539

Mach4 General Discussion / Re: G93 Inverse Time

« on: January 15, 2019, 02:51:26 AM »

In the core, we basically call it zero velocity if you are below .00001" per minute.   So don't go that far.  Your motion controller may limit you, so check the specs on it.

Steve

540

Mach4 General Discussion / Re: Keep track of OB axis

« on: January 15, 2019, 02:19:59 AM »

The DRO would be in whatever you set the motor up to be.  Counts per unit.  It if is rotary, how many counts per revolution is what you would put in the counts per unit field for the motor. 

Then there are update and modify scripts (See the GUI manual on how to use them) that can be attached to the DRO that reads tracks OOB axis' motor position.  The rollover count be handed in those scripts.  The axis would have to be homed first, but you probably want to do that anyway.  Since you would move the tool turret incrementally (so many degrees per tool pod), it would be easy to keep track of what tool you were using. 

I can't wait to see what you guys come up with!   

Steve