Hello Guest it is September 20, 2020, 07:56:24 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: Keep track of OB axis
« on: January 15, 2019, 02:19:59 AM »
The DRO would be in whatever you set the motor up to be.  Counts per unit.  It if is rotary, how many counts per revolution is what you would put in the counts per unit field for the motor. 

Then there are update and modify scripts (See the GUI manual on how to use them) that can be attached to the DRO that reads tracks OOB axis' motor position.  The rollover count be handed in those scripts.  The axis would have to be homed first, but you probably want to do that anyway.  Since you would move the tool turret incrementally (so many degrees per tool pod), it would be easy to keep track of what tool you were using. 

I can't wait to see what you guys come up with!  :) 


Mach4 General Discussion / Re: License error 4
« on: January 14, 2019, 12:24:51 AM »
License error 4 means that the core thinks that it has been modified.  It may be a corrupted Mach4Core DLL causing all of the problems. 


Mach4 General Discussion / Re: separated Acc/Decll for G0 and G1
« on: January 14, 2019, 12:13:12 AM »
Acceleration has everything to do with the capabilities of the machine.  Meaning how rigid it is.  High acceleration rates will keep the tool closer to the real path when constant velocity mode is used.  However, if the machine is not capable of using the higher acceleration rates WHILE cutting, then the acceleration values need to be lowered (as you have noted).  So if you are wondering or waving on a corner, it is most likely machine flex going on. 

So on to how to solve this...  One could implement a custom M code (or two) to raise and lower the motor acceleration values.  Using the mcMotorSetMaxAccel() API function.  But I suspect that doing some reading up on CV tuning is what will help you the most.  There is a CV tuning wizard that will actually let you control how fast the machine goes into and out of corners, etc...  Slowing the corner speed may allow the higher accel rates to not impact the cut quality. 


Mach4 General Discussion / Re: Variable offset in Mach4
« on: January 13, 2019, 11:40:44 PM »
I forgot to mention that this stuff is in our current development version, build 4026.  The mapping wizard is mcMapSurface.mcc in the wizards directory.  Right now, the only way to load a map is with the surface map plugin configuration dialog.  In the future, there is a way to load maps via the register interface making it possible to totally automate mapping a warped/bowed PBC scenario without having to load files manually, etc...


Mach4 General Discussion / Re: Variable offset in Mach4
« on: January 13, 2019, 11:30:06 PM »
Well...  It is pretty much doing the same thing as the Autoleveler program is doing.  Only it is compensating for the table error at the output (motors), not the input (G code).

The map file can be created manually.  But what a pain in the rear!  So Brett wrote a Wizard that generates a G code probing routine to automate the mapping.  Of course this requires the use of a touch probe though.  You can specify the resolution required and the area of the table you wish to map.  For the base table map, one would obviously do the whole table area.  As for the resolution, you need to make is fine enough for your application.  The error map is interpolated between the map points.  This is what I would call the base table map. 

After you have the base table map (or your table is flat and you don't need base table map compensation), you can just load a map for a particular part.  This is almost exactly as you describe with the Autoleveler process with the exception that the G code is not modified and instead, the produced map file is loaded. 

For warped/bowed PCBs, one would necessarily have to "map" the board each time a new board is done.  But for getting rid of table error, the base table map only needs to be done once.  So this will work perfect for the OP's issue. 

This table mapping isn't using the override axes.  However, the THC control does indeed use that.  THC control will also be front and center in the next release. 


Mach4 General Discussion / Re: get and set the G54 ,G55..
« on: January 13, 2019, 11:08:53 PM »
Those system variables reflect the LAST modal state set through G code.  They are informational only meaning they don't actually set the mode.  However, we do read them for presenting the modal states on the screen.  So changing them basically only changes what is displayed. 

The Fanuc manuals do not specify that those registers are read only.  But they do not state that writing to them has any effect either.  So we don't enforce the read only attribute and we don't allow the modal states to be changed by them either.  Besides, there is already an interface for changing the modal state for #4014.  G54, G55, G56, etc...  :) 

I don't believe setting the offset with the #4014 system variable would work too well with the G54.1 style extended offset either.  So I'm inclined to think that those variables really are for informational purposes only. 

Also, a word of warning:  Be careful with setting system variables with screen elements (DROs or text boxes) while a program is running.  It may not have the desired effects because of the look ahead! 


Mach4 General Discussion / Re: Variable offset in Mach4
« on: January 13, 2019, 09:43:27 PM »
When the next release comes out, we will have that capability.  We call it table mapping.  I should do the same for the lathe.  You can have a map for a table that isn't level.  Or a bed that isn't straight.  And then also layer maps on top of that if you need them!  Say a warped PCB on top of a table that isn't level.  The sky is the limit! 


Mach4 Toolbox / MOVED: LUA, repeat until
« on: January 11, 2019, 05:03:47 PM »

Mach4 General Discussion / Re: Mach4 and Galill DMC 4133 on lathe
« on: January 10, 2019, 11:30:38 PM »
Steve,    how much of a process is it to get the plug in to work do you just need a guinea pig  8)


It is a big process, unfortunately.  I would pretty much need to be sitting right beside the machine.  Program, then test.  Rinse and repeat until it is done.  So I need to have easy and quick access to the machine.  This is the whole reason I was converting my lathe.  Because I had thought that would be the only way to get it done.  Doing something like threading "virtually" is probably an impossibility, orr it would take forever and a day.  :(


Mach4 General Discussion / Re: Mach4 and Galill DMC 4133 on lathe
« on: January 10, 2019, 10:37:07 PM »
steve   $#(#$)()    No threading that is a deal breaker for me any idea when it might be implemented.      i think the drives have analog inputs 

Well...  I pretty much need a lathe that has a Galil on it to implement and test the threading.  I had started the conversion of my manual lathe years ago just for this purpose.  But it is not finished and probably won't be for a while because I really just don't have the time to get it done!  :(

Kenny Crouch, the other programmer on the Galil plugin, has moved to St. Thomas Island in the Caribbean and could not bring his lathe with him.  So...  we just really don't have any machine to test with at the moment.