Messages

711

Mach4 General Discussion / Re: is macro B just as fast or faster than regular gcode?

« on: July 16, 2017, 01:07:58 AM »

The LUA scripts is that they are only available in M codes.  In other words, you can't embed LUA script in the G code directly.  Otherwise, LUA is certainly fast.  Both Macro B and LUA scripted M code will break the CV chain, so the move right before them will be an exact stop move.  

With Macro B, one can write a subroutine and associate the sub with a G code.  Say your sub is called 9099 and it is written to take the IJK values.  You can then associate that sub with say G103 and call it in the program like G103 I_ J_ K_.

You could also call the sub with G65.  Like G65 P9099 I_ J_ K_.

So it is about up to the way you want to do it.  The M codes CAN take parameters too.  But probably the M code would do the calculation in LUA and then stuff the output into some #var range that you define.  Then you would need to write the G code to handle the movement that uses those #vars.

But it would be far easier to write a sub that calculates the desired values and moves the head/table all in G code.  I would prefer Macro B.  But...  it does come at a cost.  

Steve

712

Mach4 General Discussion / Re: Mach4 Rotary Feedrate

« on: July 15, 2017, 03:36:40 PM »

Yes, A axis is rotation around X.  And it is in degrees.  So un-map the motor from the Y axis and map that motor to the A axis.  Then use A instead of Y in the G code.

Steve

713

Mach4 General Discussion / Re: is macro B just as fast or faster than regular gcode?

« on: July 15, 2017, 03:32:29 PM »

Macro B is as fast as the interpreter is.  And the interpreter is pretty darned fast!  Not many big name CNC solutions can match the G code lines per second that Mach 4 can process.  However, it will depend a lot on the PC hardware.  Meaning, don't expect an Atom to process the same G code lines per second that an I7 will, etc...

So the delay will be proportional to the amount of G code lines that it takes to do your calculations.  But those G code lines will runs just as fast as regular G code lines.

Steve

714

Mach4 General Discussion / Re: Mach4 Jog Increments

« on: July 15, 2017, 02:57:23 PM »

Again, the knowing the build is pertinent.  So please guys...  include the build (and other information like which OS and screen set you are running).

Newer builds follow the state of G20/G21.  With older builds, you had to change the jog units with a script API call. 

Steve

715

Mach4 General Discussion / Re: subroutines?

« on: July 15, 2017, 02:50:19 PM »

Nothing has changed.  Subroutines work in Hobby with M98 and M99, just not with G65 and G66.  Also, conditional G code is an industrial feature that is not in hobby.  What you are seeing is the WHILE (line 28) in the embedded subroutine causing the "feature not licensed". 

Perhaps the example is not the best.  I will make it so that it works in hobby by taking out the WHILE loop. 

Steve

716

Mach4 General Discussion / Re: MPG with Feed Hold SAFETY ISSUE

« on: June 16, 2017, 02:12:11 AM »

PMC == programmable machine controller.  It is a ladder logic software PLC.  Search of PMC in this forum for how to use it. 

Steve

717

Mach4 General Discussion / Re: MPG with Feed Hold SAFETY ISSUE

« on: June 15, 2017, 10:51:13 PM »

I would use the ISIG_MPG_INHIBIT instead.  As a workaround until the next release.  You can use the PMC to hold it high when no axis is selected on the MPG.  You could also use that signal along with the machine state and hold it high when the machine is in any of the feed hold states. 

Steve

718

Mach4 General Discussion / Re: MPG with Feed Hold SAFETY ISSUE

« on: June 15, 2017, 07:42:14 PM »

We experimented with jogging in feed hold but took it out but failed to take it out for MPG movements.  It will be corrected in the next build released. 

Steve

719

Mach4 General Discussion / Re: Module Works Simulator

« on: June 15, 2017, 07:19:15 PM »

Correct, a lot of what is displayed not needed.  What I wanted you guys to do is run depends.exe, point to the mwSim.m4pw, and then save the output to a file and post that file up.  That way, I can load that file and analyze it.  I do this stuff for a living, you know.    I can't tell much from the screen shots, as there is going to be a lot of misleading info.

The MW guys are using VS2013.  And probably on a Win10 machine by now.  So you are most likely correct in your assumptions.  Developers tend to target the newest OS to make sure it runs on it because that is what most people will be running if they bought a computer within the last couple of years or so.  But that can backfire.  Maintaining backwards compatibility and such is a freaking nightmare.  All perpetrated against programmers by Microsoft.  The newer compilers will not even run on XP.  So XP is definitely on its' way out. 

Steve

720

Mach4 General Discussion / Re: Module Works Simulator

« on: June 14, 2017, 11:11:58 PM »

There has got to be some other missing component.  Maybe another DLL that is required to run the MW simulator is missing on your systems?  Are either one of you familiar with dependancy walker?  http://www.dependencywalker.com/

I would like to see the output of that program when run on both of your machines.  It may tell us something.  So if you are comfortable running that, please do so.  Just point it at the mwSim.m4pw file. 

Steve