Hello Guest it is September 29, 2020, 12:38:39 AM

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: Can you use Inputs with Macro B Programming.
« on: November 20, 2017, 06:55:03 PM »
That looks like it might just do the trick.  :)

Ok, I read your dad's post.

When a script is run from a screen control or G code via mcGcodeExecute/Wait(), it will lock the GUI for the duration of the script.  Why?  Because the button click event is the action that causes the script to run.  And it needs to complete.  The application event loop only processes one event at a time.  Screen updates are also events. 

Say you are the application event loop and I am the user of the machine control.  I'm not telling you to do anything at the moment, so you are spending your time running around the screen and updating DROs and such.  But all of a sudden, I press a button that basically says "Cbyrdtopper, go do this script task".  So you go running off to do the script.  So who is updating the DROs now?  Nobody. 

So what mechanism(s) can we use to make this better? 

1) Use the PLC script.  Most buttons scripts should be short and sweet without loops or calls to code that has loops in it.  If a long running task is needed it is better to just set a variable to initiate the action in the button script.  Then a state machine (that watches that variable) can be implemented to process the task in the PLC script. 

2) Hand the action off to the interpreter.  An example of this is the MDI.  You type some G code in and hit cycle start.  The cycle start button just starts the interpreter and comes back immediately.  So the GUI is functional and screen updates happen.  But the state of the machine has changed from idle to MDIrunning.  So you can now wait on the state to transistion back to idle.  The other use of the interpreter is to let it do the complete action (via Macro B), as you are discovering. 

Otherwise, you will need to get into advance LUA programming and use coroutines.  That isn't a road that is easily traveled.  :(

Mach4 General Discussion / Re: Can you use Inputs with Macro B Programming.
« on: November 20, 2017, 06:07:01 PM »


Mach4 General Discussion / Re: Can you use Inputs with Macro B Programming.
« on: November 20, 2017, 05:56:42 PM »
I can't find your dad's post.  :(

There are no #vars for DROs.  However, DROs can read/write any #var you choose.  Obviously, you don't want to step on #vars that do something important, so keep that in mind.  You accomplish this by using the DRO's Parameter property.  Enter 500 for #500, etc...  The DRO would then display whatever is in #500 and when you edit it, it would change the value of #500.

You would typically use a #var if you also want to make that information available to G code.  If you don't need that, then using a register as the backing store for the DRO would be better. 


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. 


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.");
--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!.");
--Set the analog voltage
analogval = (CommandRPM/MaxRPM) * 4096;
mc.mcRegSetValue(hReg, analogval);

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


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.


Mach4 General Discussion / Re: Mach4 takes 30 seconds to start
« on: November 03, 2017, 10:22:52 PM »
Bingo!  Nice!  Thanks Gerry!

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! 


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. 


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.