Messages

681

Mach4 General Discussion / Re: m3 gets special treatment?

« on: November 20, 2017, 05:31:40 PM »

That spindle speed script gets called whenever there is a S word in G code or when the spindle is changed via a screen or panel control.  I believe it will do what you want.  It was originally conceived to allow external spindle controls (not on the motion device) like MODBUS work well. 

Steve

682

Mach4 General Discussion / Re: m3 gets special treatment?

« on: November 20, 2017, 02:27:43 PM »

The "reserved" M codes will NOT take parameters.  Only user defined macros will.  M3, M4, M5, M6, etc...  are all defined to have a specific function in G code.  Thus, they don't do anything other than what they were meant to do.  Contrst that to say a M code that you create called M110.  The M110 macro scrip can then have parameters and hParam will not be nil. 

If you want to do something special with the S word, use spindlespeed.msc.  The parameter is the value of the S word.  So 1000 for your example. 

Here is an example:

Code: [Select]

function spindlespeed(rpm)
inst = mc.mcGetInstance();
CommandRPM = mc.mcSpindleGetCommandRPM(inst);
range = mc.mcSpindleGetCurrentRange(inst);
MaxRPM = mc.mcSpindleGetMaxRPM(inst, range);
mc.mcCntlSetLastError(inst, "SpindleSpeed! " .. tostring(CommandRPM) .. " RPM");

if MaxRPM == 0 then
mc.mcCntlSetLastError(inst, "MaxRPM is zero!  Please set up the spindle.");
else
--Get the hReg handle of the modbus analog register
hReg = mc.mcRegGetHandle(inst, "modbus0/mboreg1");
if hReg == 0 then
--mc.mcCntlSetLastError(inst, "Register not found!.");
            return;
else
--Set the analog voltage
analogval = (CommandRPM/MaxRPM) * 4096;
mc.mcRegSetValue(hReg, analogval);
end
end
end

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

Steve

683

Mach4 General Discussion / Re: Can you use Inputs with Macro B Programming.

« on: November 20, 2017, 02:22:06 PM »

Have a look at http://www.machinetoolhelp.com/Applications/macro/macro_variables.html  It is kind of a cheat sheet on Macro B.

When referring to those variables, we use Tool Compensation Memory type C.  Like a Fanuc 21i.  

Specifically, the answer to your question is yes.  See the top of this page: http://www.machinetoolhelp.com/Applications/macro/system_variables.html  Input signals are mapped to #1000-1015.  However, we do extend that to #1000-1031 to cover the input signals INPUT #0 to INPUT #31.  The input signals WILL need to be mapped to valid device inputs.  

And you can turn on outputs signals too.  With #1100-1131

Those pages also have some examples of Macro B (loops, etc...) and how to use them.  But for the quintessential reference, Peter Smid has a book called "Fanuc CNC Custom Macros" that covers the subject.

Steve

684

Mach4 General Discussion / Re: Mach4 takes 30 seconds to start

« on: November 03, 2017, 10:22:52 PM »

Bingo!  Nice!  Thanks Gerry!

685

Mach4 General Discussion / Re: Mach4 takes 30 seconds to start

« on: November 03, 2017, 08:19:02 PM »

LOL!!!!  Yeah, anti-virus is a lot like the TSA, I seem to get my bung hole stretched with either.    And both are the wrong ways to approach their respective problems. 

When I was an IT manager for a global company, we used Cisco routers, switches, and firewalls to keep the viruses OUT of our networks.  None of the workstations had a need for anti-virus software!  They all ran fast like they were supposed to.  But sadly, that kind of equipment is far too expensive for us mere individuals.    But I will say this...  all that expensive Cisco stuff was cheaper than signing up for virus software/definition updates for all of the workstations.  And it was really nice not having to worry about it.  Even if someone brought a virus into the network internally, the switch would detect the malicious activity and shut down the port of the offending workstation and prevent others from being infected.  Really really nice stuff! 

But right now...  I'm trying to figure ways to speed up the screen load process.  Because 99% of our users have to have some sort of virus protection.  It is a fact that most just have to live with.  I haven't been infected since the late 90s when all of the MS Outlook "preview" exploits hit the scene.  I started running MS Security Essentials because, at the time, it was light weight, and I figured it might protect me from future Outlook holes.  And sure enough...  no infection.  One of the problems with my Win10 upgrade was that I had Security essentials installed on my Win 7 machine.  And it left it there on the upgrade but it was incompatible with what it had morphed into with Win 10 (Defender).  And the time I spent undoing all of that mess was akin to the time spend removing a virus!  So yeah...  I tend to agree that anti-virus is a virus unto itself. 

BTW, sanity is a relative thing.  Just like paranoia is.  Just because you are paranoid, doesn't mean you are not right.  And just because you may think you are insane, doesn't mean you are! 

Steve

686

Mach4 General Discussion / Re: Actions verses Events

« on: November 03, 2017, 07:49:17 PM »

Yes, those are considered "stock actions" that the GUI provides that give users a quick way of accomplishing the most needed tasks.

The GUI has the concept of pages like Mach3 had.  But they are mostly not needed with the advent of the tab control.  Most of the screen sets now are built all on ONE screen page.  But the screen can have multiple screen pages.  But with pages, there are not any tabs to click to switch between them.  So usually what is done is a button is placed on the screen that uses "Goto Page" to switch to a different page.  "Goto Page" will take a page number (in the order that they appear in the tree manager) OR a page name.

"Run MDI" is for the MDI controls.  MDI controls allow entry of MDI commands but there isn't anything on the MDI control to execute that code!  So "Run MDI" takes the name of an existing MDI control as the parameter.  When the button is pressed, the G code in that MDI control is executed.  Most of the screens do the task of executing MDI code from the Cycle Start button and "Run MDI" is not used.  There is switch code behind the Cycle Start button that determines whether or not to execute a file or the contents of the MDI control based on if the MDI control is focused or not. 

I'll put some bonus info out here just because I know that this is commonly misunderstood and/or mysterious.  Up and Down and clicked events, what is the difference?  Well...   MOST of the time users will want to use the left up event (action or script).  This is because if the action or script is executed in the left down event, the GUI will appear locked for the duration of the event.  The button will even appear "stuck down".  Why? Because the event has to complete before the up event is fired.  Using the up event can still lock the GUI for long running code but at least the button appears to come up instead of looking like it is stuck down.  Most of the time, it is prudent to only perform fast running tasks in button scripts, even if you use the up event.  The ONLY reason we have a down event is to handle momentary button control of things like velocity jogging.  In the velocity jog case, the jog is started with the down event and ended with the up event.  In each event's case, all the event is doing is setting a state, so the actual event code is very very fast.  No long running code in buttons!!! 

The clicked event happens when both a down and an up event occurs.  And it ONLY happens when both the up and down events were fired.  It is possible to prevent an up even from firing by clicking the button mouse down (down event happens) and while the mouse button is still down, moving off of the button and then releasing the mouse button (no up event is fired).  No up event, thus no clicked event. 

Steve

687

Mach4 General Discussion / Re: Mach4 takes 30 seconds to start

« on: November 03, 2017, 07:16:44 PM »

Yeah, on Win7-32, my Atom board loaded Mach quicker than my 8 core Win 10 machine (4GHz w/ 64Gb RAM plus dual GPUs) did with spin disks.  The SSD addition to my desktop reduced the time significantly.  It will load Mach in less than 10 seconds (wx4.set) even with the initial load hit, About 5 seconds being the norm.  The initial program is loaded very quickly with the most amount of time being spend loading the GUI elements.  We track a LOT of things, so I know why that takes a time hit.  I wish I could find a way of loading the screen set more quickly.  

The Atom does, however, suffer when loading bigger G code files.    But that's fine.  So I KNOW it is something on my Win10 machine that slows the initial load down.  I haven't tried to put my finger on it completely yet and have really just assumed that it was Windows Defender real-time scanning.

Like Craig, I don't run any anti-virus on my "production" Atom board.  But I do run Defender on my development desktop just because I touch the dirty internet with it.

Steve

688

Mach4 General Discussion / Re: Update error

« on: November 02, 2017, 11:35:14 PM »

The update and modify scripts have changed.  If the scripts exist, they must return a value, otherwise, the control will not get updated.  Even if the actual value isn't changed!

-- Example encoder update script.
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the system value.
val = tonumber(val) -- The value may be a number or a string.  Convert as needed.
local name = select(2, ...) -- Get the control name.  It is always a string.  You may not need it.  But it is there if you do.
val = val / 1024 -- convert the encoder value to a decimal (assumes 1024 counts per unit).

return val -- the script MUST return a value, otherwise, the control will not be updated.

In your script functions, it would be just a slight change.

Add
local val = select(1,...) -- Get the system value.

to the top of each script and

return val

to the bottom of each script. 

But that is not all.  The error states that the 4th parameter (XWear) is nil.  XWear is pulled from the droXWearOffset DRO.  So I'm thinking that there is an update script that needs to be looked at (probably the same modification as above). 

Steve

Steve

689

Mach4 General Discussion / Re: Signal vs IO and Aliases

« on: November 02, 2017, 01:41:03 PM »

I/O is provided by plugin devices.  I/O can be "mapped" to Mach signals.  In theory, one should be able to bypass mapping an I/O point and just twizzle the I/O without a Mach signal.  For like a script that just wants to toggle an output or look at an input that otherwise Mach doesn't need to know about. 

You need to provide a complete path to the mcIoGetHandle function.  As in add a beginning "/" character to it for "/modbus0/function1/fwdrevbit".  That might do it.  Otherwise, there may be a bug in the LUA binding for that function as not many have probably used it.  MOST of the time, it is just easier to map the I/O to a Mach signal. 

Steve

690

Mach4 General Discussion / Re: Mach4 takes 30 seconds to start

« on: November 02, 2017, 01:29:02 PM »

It is the real-time scan feature that seems to do it.  And I don't think it follows the exclusions.  I may be wrong though.  But I noticed it when I went from 7 to 10.  It is disk speed related because I moved to a SSD and the issue is not nearly as noticeable.  Mach is not a particularly big program.  And it is all C++ and doesn't use .NET stuff that has to be "assembled" at run-time.  So all things considered, it really should load fast.  I will say that there is nothing that we are doing to make is load slow.  Of course, the more screen elements that exist in the screen set, the longer it takes to load.  No getting around that. 

I can make it load slower by compiling a new GUI executable.  This makes the signature of the program change.  And at that point, Windows goes into slow load mode for the first time I run the new GUI.  But after the first load, it loads quickly.  It may also have something to do with the PC/processor's memory and/or disk cache.

Steve