Hello Guest it is February 18, 2020, 05:54:53 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 i edit or add to a Predefined Macro?
« on: January 26, 2017, 07:40:30 PM »
The G code interpreter will take M03, m03, M3, or m3 and turn them all into m3.  So when looking for a macro, it will use m3.  Much simpler than looking for all 4 variations.

Using the constants is a very good idea.  Because if we change the value of the constant, it will not require you to change your code.  :)

The return code is simply discarded and garbage collected if it is not used.  However, I strongly suggest checking for error codes!  Not only is it a good programming practice, it could have bearing on whether or not you loose a finger or not!  Yikes!  In truth, it is not necessary all of the time.  But if you get into the habit, it is going to pay dividends in the future for sure.

All of the API functions have their possible return codes documented and I'd say that the majority are correct.  In the event that we messed up, I prefer to test for inverse success.  e.g.

if (mc.mcSpindleSetDirection(inst, mc.MC_SPINDLE_FWD) ~= mc.MERROR_NOERROR) then
   --handle any failure!


Mach4 General Discussion / Re: Can i edit or add to a Predefined Macro?
« on: January 26, 2017, 06:18:38 PM »
The macros (and functions inside them) should be lower case and leading zeros dropped.  m03, M03, m3, or M3 is accepted by the interpreter, but it gets low cased and leading zeros dropped shortly there after.  Windows is not case sensitive but LUA is.  Everything ought to be case sensitive.  Everything on the planet, except Windows, IS!!!! 

If you write a custom m3 macro, it replaces the stock actions of m3.  So you must provide all functionality you desire in the custom m3 macro.  See the doc on mc.mcSpindleSetDirectio().


Mach4 General Discussion / Re: Send Email
« on: January 24, 2017, 04:45:03 AM »
It is asking you to find the required module.  Simply pick smtp.lua.  When the require keyword is used in a LUA script, think of it as "including" that script.  Also think of:

local smtp = require("/socket.smtp")

as short hand for:

local smtp = require(cpath .. "/socket/smtp.lua")

For port 587, that will require SSL.  I think there was a post on here somewhere that deals with using SSL along with the sokets smtp module.  Search around for it.  I worked with Chaoticone on getting that working at some point, but I do not remember the details. 


Mach4 General Discussion / Re: 24 Position Side Mount Tool Change Macro
« on: January 23, 2017, 04:22:25 PM »
rc is the function return code.  Ideally, you should check the rc to determine success or failure of the API call instead of assuming that it worked.  You know what they say about assumptions.  :)  f an API function succeeds, it will return a rc of mc.MERROR_NOERROR.

For example:

RequestedTool, rc = mc.mcToolGetSelected(inst)
if (rc ~= mc.MERROR_NOERROR) then
    mc.mcCntlSetLastError(inst, "Error getting selected tool!")


Mach4 General Discussion / Re: 24 Position Side Mount Tool Change Macro
« on: January 23, 2017, 03:20:32 PM »
For machines that don't have a 1:1 for tool number to pod, use the tool table's pocket feature.  

pocket , rc = mc.mcToolGetData(Inst, mc.MTOOL_MILL_POCKET, tool);


rc = mc.mcToolSetData(Inst, mc.MTOOL_MILL_POCKET, tool, pocket);

pseudo code:

RequestedTool, rc = mc.mcToolGetSelected(inst)
CurrentTool, rc = mc.mcToolGetCurrent(inst)
pocket , rc = mc.mcToolGetData(Inst, mc.MTOOL_MILL_POCKET, RequestedTool);
retrieve tool from pocket
rc = mc.mcToolSetData(Inst, mc.MTOOL_MILL_POCKET, RequestedTool , 0); -- tool is in spindle.
put current tool in the requested tool's old pocket
rc = mc.mcToolSetData(Inst, mc.MTOOL_MILL_POCKET, CurrentTool , pocket); -- old tool is in the new pocket.

Before the first run, make sure the tool table has the correct pocket numbers for eash tool.


Mach4 General Discussion / Re: Lua
« on: January 23, 2017, 02:11:22 AM »
The max value of the analog input is determined by the ADC used on the hardware. 

10 bit == 0 to 1023 for a 1024 count range
12 bit == 0 to 4095 for a 4096 count range
14 bit == 0 to 16383 (16384 range)
16 bit == 0 to 65535 (65536 range)

This is called the ADC resolution.  To get the analog input value as a percentage, just divide the value by the total range. 

percent = value / range

For example, if the ADC is 10 bit and the value is 512, then:

512/1024 == .5 (or 50%).

Now you can play with some numbers to arrive at solutions to common problems.  For example (and just for kicks), say you want to know the voltage present at the ADC given its' integer value.  For the above value of 512 that yields 50% and a VCC voltage of 3.3v:

3.3 * .5 == 1.65v. 

So going back to main problem at hand, we now want to know what 50% of a range is.  Say 50 to 150.  The formula for that is:

val = (percent * (max - min)) + min

Where percent is a decimal representation of a percentage.  e.g. .5 for 50%

(.5 * (150 - 50)) + 50 == 100.


Mach4 General Discussion / Re: Question on Toolpath?
« on: January 22, 2017, 06:24:15 PM »
Unfortunately, not at this time.  :(


Mach4 General Discussion / Re: Errors in Machine.ini file
« on: January 19, 2017, 09:09:56 PM »
As long as the code looks for the misspelled keys, then it doesn't matter.  If you correct the spelling in the .ini file, then you get hosed.  :)


Mach4 General Discussion / Re: High GPU usage workaround
« on: January 19, 2017, 09:08:19 PM »
I doubt you lose steps.  Like i said, all we do is load the matrix and then modify it.  The rest happens in the GPU and will have no effect on the CPU running the planner.

If there is no tool path on the screen, then none of the OpenGL code gets called.  The GUI has to tell the core to update a visible tool path.  So I'm not sure why a screen with no tool path is exercising the GPU other than for DRO updates. 


Mach4 General Discussion / Re: High GPU usage workaround
« on: January 19, 2017, 04:28:15 PM »
We update the tool path with the cut path.  So while it is not moving, per say, it HAS to be updated when running G code.  I just loaded that 100MB file and looked at my GPU when it is running.  The GPU does go up to about 25% (on one card only) with the tool path zoomed out.  Zoomed in, 5% or less. 

There are two options on how the tool path is run.  Vertex Buffer Objects (aka VBOs, and requires OpenGL version >= 1.5) and the old Mach 3 way.  We test for the v1.5 and if the driver supports it, we use VBOs.  Typically, using VBOs puts more of the work on the GPU and less on the CPU.  But usually, it also lends to smoother video as most graphics cards have faster memory that the RAM that the CPU uses.  But...  all graphics cards and their associated drivers are not created equally.  Just because a drive reports that it can do OpenGL v1.5 doesn't mean it does it well.  Some graphics cards may not even implement it in hardware but choose to emulate it in the driver software.  We can't know this.  All we can know is what the driver tells us.  But finding out that some drivers just plain suck, we offered the option to disable the use of VBOs in the Mach config.  This drops back to the old Mach 3 tool path code.  The Mach 3 tool path style should use more CPU and less GPU.  And it might now move around as slickly.  I used to be able to tell the difference between the two methods, but with my current PC (4GHz 8 core), they feel about the same now. 

BTW, as I was typing this, I loaded the 100MB file on my D2700MUD Atom board that uses an on-board cheap ass Intel GMA.  It took like 15 minutes to load!!!  (Atoms are so slow!)  I have no way of looking at the GPU usage on it, but it does handle that file!  I really didn't think it would.  It seems to track ball around well.

Attached is the GPU graph while RUNNING the file with the tool path fully visible (zoomed out).  The red peaks are ~25%. 

Anyway, the only thing I can say is that you must have a driver or hardware issue that is causing the high GPU usage.  What we do is relatively simple in comparison to something like a video game or even a 3D CAD program.  My AutoDesk Inventor works my GPU much harder than the Mach 4 tool path does.  All we have is a matrix of points that are connected by lines.  This matrix gets dumped into video card memory (if using VBOs) or the computer RAM if not using VBOs.  Nothing special.  Once the matrix is loaded, we really don't do anything more with it except change bits and pieces of it "in memory".  The rotation is handled purely by the OpenGL driver and video card.  When more of the matrix is displayed in the view port, the more processing will be required.  So seeing the GPU usage go up seems perfectly logical. 

So what is causing the high GPU reading?  Is it a driver or hardware issue (most likely) or maybe bad feedback to your GPU monitoring utility?  That's about where we are at this point.  Because if my Atom didn't choke on that 100MB file, I would expect most anything would run well if all was in working order.