Messages

821

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. 

Steve

822

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. 

Steve

823

Mach4 General Discussion / Re: High GPU usage workaround

« on: January 18, 2017, 04:34:24 PM »

The GUI will not redraw on every refresh if you tick the "Use Lazy Tool Path Update?" checkbox in the Mach config Tool Path tab.  Only if the tool path is moved or when G code is running.  If that option is chosen and there is no movement, the OpenGL routines are never called.  I can say this with %100 confidence as I just looked at the code and tested it to be sure.  If you have that checkbox ticked and you still have high GPU usage, then your problem must lie elsewhere. 

Here is my GPU graph with a 100MB 3D file loaded.  The red line is the activity line.  The spikes are when I was track balling the tool path around.  The yellow line is the GPU speed, which spikes when zooming the tool path in and out.  Dual AMD R7 370s but Mach never even blips them enough to even dent one card while moving the tool path aggressively. 

824

Mach4 General Discussion / Re: CV Simulation Toolpath vs CV Controller Toolpath ???

« on: January 14, 2017, 12:01:59 AM »

Data is flowing to the controller first, then we have to wait on a position update from the controller to update the position on the tool path.  We depend on the motion controller to give us updated positions and since there is nothing real-time about it, there will be positional "gaps".  So it really depends on how often the motion controller sends Mach position data.  No two motion plugins are the same.  For instance, this update rate is configurable in the Galil plugin and can go as low as 8ms if the PC will handle it.  But a lot of them may be as slow as 100ms.  A slower update rate will have the effect of chopping off a corner in the tool path display as Mach basically draws a line from the last reported position to the current one. 

Steve

825

Mach4 General Discussion / Re: Q word missing error when running G83?

« on: January 11, 2017, 10:32:44 PM »

The CamBAM post processor is producing incorrect G code.  G81 and G93 are modal G codes.  You turn them on, then cancel them with G80.  So what Mach 4 is asking for is correct.  Previous builds of Mach 4 probably didn't catch that error.  We have been improving the error catching abilities of the interpreter and it looks like it messed things up for you, unfortunately.    But it is probably a rather simple edit of the CamBAM post processor to fix the issue.  Or maybe try a generic Fanuc post processor to see if it may be better.

Steve

826

Mach4 General Discussion / Re: Mach4 de-referencing all axis when loading gcode

« on: January 11, 2017, 10:20:43 PM »

I have never heard of Mach doing this.  Why don't you tell us about your hardware and stuff (motion controller, OS, Mach build, etc...)?  Because the more information, the more everyone might be able to find a solution. 

Steve

827

Mach4 General Discussion / Re: Tool Table Import?

« on: January 05, 2017, 03:38:40 PM »

G10.  Look at the Milling Manual in the docs folder to get the syntax.  Some CAM programs will export the tool table into a G code file that includes G10.  Then the G code program is simply run once to set the tool table. 

If your CAM program can only output the .CSV file, then you could write a "translator" in LUA script to go from the .CSV contents to G code with G10. 

The other way would be to read the .CSV file in a LUA script and use the API to modify the tool table. 

Steve

828

Mach4 General Discussion / Re: Fusion360 Post processor for Mach4

« on: January 04, 2017, 11:42:22 PM »

Mach 4 is more Fanuc compatible than Mach 3.  Patterned after a 21i.  Cutter comp memory type C.  For regular XYZ programs, the Mach 3 post is probably adequate.  If not, start looking through the Fanuc posts.

Lathe/Turn is where the more major differences from Mach 3 are.  Specifically G76 threading.  Mach 4 accepts both Fanuc G76 1 line and two line formats.

Steve

829

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 07:32:45 PM »

The Keyboard plugin was one of the first plugins we developed.  So it was made prior to the advent of the Mach Register concept.  Just a FYI as to why it is like the way it was. 

830

Mach4 General Discussion / Re: Keyboard Inputs Enabled or Disabled Handle

« on: January 04, 2017, 07:30:15 PM »

You can get the state of the keyboard plugin with the output.  However, since it may not reflect the state of the keyboard plugin at startup, you have to set it to something first.  This is why that call was made the FIRST time the PLC script ran.  Then, once the output is set to on or off, you can then get the output state and it will reflect the status of the keyboard plugin.

Now, there are two outputs that the keyboard plugin exports.  Keyboard/Enable and Keyboard/EnableKeyboardJog.  One enables/disables the entire keyboard key mapping and the other will just disable the jog key mappings but leave the rest of the key mapping working (keyboard must be enabled). 

So it can work.  But...  The register is the better way in case one ever just wants to check if the keyboard mappings are enabled without setting that status first.  In any case, there will be a register called "KeyboardControl/Enabled" that will reflect the state of the keyboard mappings.  If you set that register to 1, it will enable the mapping.  Setting it to 0 will disable all of the mappings.  Reading it will always reflect the status of the mappings. 

Steve