Hello Guest it is September 19, 2019, 06:01:56 PM

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

231
Mach4 General Discussion / Re: homing to index pulse
« on: January 20, 2018, 02:11:52 AM »
It all depends on the motion controller and drive/motors used.  Most controllers that support analog servo drives will home to an index pulse.  FWIW, homing is a motion controller only function.  All Mach does is tell the motion plugin to home and provides no trajectory for the movement of the motors during the homing operation.

Steve

232
Mach4 General Discussion / Re: Homing and Tool offsets on Lathe
« on: January 19, 2018, 09:42:52 PM »
Ron Ginger did a nice video on this very subject.  But I can't find it.  :(  But Rob Gaudette also did one.  https://www.youtube.com/watch?v=SDuZWZHVU0s 

Steve

233
Mach4 General Discussion / Re: Mach 4 Feature Request
« on: January 19, 2018, 07:01:23 PM »
I would like to see an existing motion behavior removed or at least be disabled optionally in settings. Whenever an M or S code is encountered in the GCode or MDI the machine decelerates to 0, executes the command, and resumes. There is not necessarily any need for it to stop in the following example.

g00 x0 s1000       motion starts and spindle at 1000
g01 x10 s5500     motion stops, spindle changes to 5500, motion continues
g01 x20 s5500     motion stops, spindle still at 5500, motion continues (no change was made but the fact there was an S code in the line means the motion stops to address it)

If the spindle speed commands weren't in there, the machine would travel from x0 to x20 without interruption but with the extra commands in there (I tested and saw the same behavior with turning coolant on and off during motion) travel slows to 0 and without any delay executes the command and accelerates back to it's previous rate.

I have my Spindle Accel/Decel time at 0 and 'Wait on spindle to stabilize' disabled

The reason I want the travel rate uninterrupted is because I'm using spindle control PWM signals to control the power output of a laser to do raster engraving.

Assume each 'pixel' i want to engrave is 1mm and I'm drawing a 5mm striped pattern I'd code as:

g00 x0y0      starting point
x50           lead in for acceleration
x55 s255   laser power max 5mm
x60 s0      laser off 5mm
x65 s128   laser half power 5mm
x70 s0      laser off
x120        lead out for deceleration
y1           next line

The laser PWM control and positional results of this code work perfectly but that forced motion stop before executing S kills the end result of the piece.
Fixing this would make raster laser engraving incredibly easy in Mach4 with the use Inkscape plugin 'Raster 2 Laser GCode' which produces great results with simpler GCode senders. It would achieve the equivalent of Art's Impact / Laser plugin for Mach3.



There is a parameter option that changes the behavior of the look ahead. Normally, you WANT to wait on the motion to complete before the M, S, or T codes are processed by the look ahead. 

Set #3003 = 2.  That will disable MST waits.  But you must consider the look ahead!  If it is set to say 100, then up to 100 lines are read (and processed!) at one time.  In effect, the S command would be the last S command.  The only thing you can do to combat that is set the look ahead to 2 lines.  That way CV will be maintained across the G code moves and not come to a complete stop.  Setting the look ahead to 1 line would be the equivalent of running in exact stop mode, BTW. 

You would be wise to set #3003 back to 0 before any stop M code is issued (M01 M02, M30, etc...)

I really don't recommend the above at all.  Instead, Have a look at M62 and M63 (The motion controller must support these).  They control outputs synchronized to the movement of the G code.  M62 and M63 are special M codes that do not break the CV chain.  So you can leave the look ahead alone.  You could easily implement 0%, 25%, 50%, 75%, and %100 with a few outputs. 

We are still working on a dedicated laser interpreter.  It will have options specifically for lasers that should accommodate this type of thing. 

Steve

234
Mach4 General Discussion / Re: Screen Editor - Hide bar
« on: January 19, 2018, 04:57:49 PM »
If you close it in full screen, it will open in full screen. 

Steve

235
Machines with tool changers and induction motors on the spindle use a spindle key lock.  The spindle is rotated slowly at low torque and the key lock is engaged.  When the key lock drops into the notch on the spindle shaft, the VFD is turned off.  So it is a pure mechanical orientation. 

Steve

236
Mach4 General Discussion / Re: Mach4 won't shut down
« on: January 18, 2018, 10:22:02 PM »
The problem is most likely a LUA script that is not terminating or a plugin hanging it up.  You can test if it is a plugin by disabling them one at a time and seeing if you can close Mach.  I have never seen Sim hang Mach up, so don't worry about disabling that one. 

There was a post where the modbus plugin was preventing a shutdown.  TOTALLYRC had that one.  It turned out that the polling frequency was too fast for his machine.  He turned the frequency down and all was well. 

Steve

237
Mach4 General Discussion / Re: Is Mach4 really Hobby Material?
« on: January 18, 2018, 10:15:50 PM »
Rich,

-.  -.--  ...-- .--. , .-- - ----- -.-  I'm sure you do know about hobby costs!  $500 to play in the ham world is chump.  And I'm also sure you know that we are super nerds, right?  :)

I use my CNC machine to help build solid state amplifiers.  Check out my QRZ page to see it.  The copper heat spreader has the MOSFET holes machined into it.  And of course, the case was CNC'd as well.   CNC and ham radio go well together.  I use my little desk CNC machine to make PCBs on occasion. 

People that are just in the CNC hobby are lucky and don't have to take tests and get licensed. 

Steve

238
Mach4 General Discussion / Re: Screen Editor - Hide bar
« on: January 18, 2018, 07:22:03 PM »
In the screen load script, insert the line:

scr.ShowMenu(false);

to get the menu back:

scr.ShowMenu(true);

Be careful not to paint yourself into a corner!  :)  Put a button on a tab to turn it back on, etc...

Steve

239
Mach4 General Discussion / Re: Is Mach4 really Hobby Material?
« on: January 18, 2018, 06:17:10 PM »
I just read this thread and I must say I'm certainly confused in a lot of ways.  During the days of Mach 3, we compiled a list of things that people were asking for that Mach 3 simply could never do.  That list became Mach 4.  So Mach 4 was the direct result of us listening to what our users wanted!  But now they don't want it?  Thus my confused state of mind.

Ii used to be, or I used to think, that hobbyist had simple machines to do simple things.  3 axis mill without a tool changer, for example.  But no.  Just take a look at the feature request thread!!!!  90% of that thread is people wanting Mach 4 to do something special.  But also, 90% of that can be accomplished with using the tools that are already provided with Mach 4!

So there is a strange dichotomy going on here.  People want shrink wrapped software simplicity but also want it to do something very special that THEY want it to do.  So I don't buy the "Mach 4 won't work without a lot of programming" complaint.  Mach 4 will run my Matsuura MC500 "out of the box" with absolutely no LUA programming!  Just by mapping signals to I/O and setting up the motors.  All of this is done in the Mach configuration dialog.  The only thing that requires LUA is the tool changer.  It required VB in Mach 3.  And since no two tool changers are the same (assuming some are built, some are converted, etc..), this becomes one of the "special things".   But I could run that machine with manual tool changes with Mach 4 "out of the box" all day long.  In fact, I don't use the tool changer all that often with the things I do.

"But I have brand 'X' joystick that I want to use..."  Guess what?  You are wanting something special. 
"But I want to touch off a tool at a certain location on my custom built machine, set the height, and restart with one button.  And I might have to learn LUA?"  The answer is yes!!!  The good news is that you can make that work.  The bad news is that we will never be able to provide that "out of the box". 

I could go on and on, but I digress. 

As to the hobbyist definition...  If you end up buying a Centroid controller, are you still a hobbyist?  A point to debate.  I'm a ham radio guy.  That is another one of my "hobbies".  But you know what?  Now I find myself collecting expensive test gear like signal generators and spectrum analyzers.  I like fixing radios.  I no longer consider it a hobby and I now consider it as a semi-profession venture.  I make money fixing radios.  It is no longer something I do just for myself.  The tools I use are something far greater than what a normal ham radio hobbyist uses.  BTW, I wish ANY ONE PIECE of that test gear was as affordable as Mach 4.  So ask yourself the question "Am I truly still a hobbyist?", and be honest. 

Also, I have a 3 axis X2 machine running Mach 4 and ESS.  It runs Mach 4 out of the box without any LUA code at all.  Now THAT is THE quintessential hobby machine.  So yeah, I think Mach 4 is hobby material.  But isn't it nice that Mach 4 will also run my Matsuura production type machine?  Make no mistake, I have no illusions about the differences between those two machines.  One is a hobby machine and the other could be put to work in any professional machine shop.  One didn't required a bit of LUA and the other did. 

Steve

240
Mach4 General Discussion / Re: Mach4 Install on XP
« on: January 16, 2018, 12:25:38 PM »
I strongly suspect your XP was missing some dependency (like the printing subsystem) that the .net installation corrected.  Some plugin that you are using might require .net (ESS maybe? I don't know).  But Mach does not require .net for the GUI and core.  It never has and never will.  I'm not a fan of anything .net and I will do ANYTHING not to use it.  But Microsoft pushes that stuff like crack!  So some program installers (the programs that install the applications) try to include it whenever they can, by default, unless the programmer writing the installer explicitly turns it off.  Obviously, our installer does install .net.  But that might explain why .net is installed with other applications, even if it is not used or needed. 

Side by side is the term used when referring how DLL dependencies are loaded.  Old school Windows would load DLLs in the Windows/System32 directory, if they existed there, first.  Side by side give preference to the DLLs in the application's directory.   Side by side, or "SxS" was the fix for "DLL Hell" caused by different versions of the same DLL.  ComCtl32.dll, for instance.  If a newer version of that DLL exists in the application directory, it will use it instead of the ComCtl32.dll in the Windows\System32 directory. 

At one time, Mach did not require any of the printing subsystem.  So it might have installed and run previously.  But we added printing in the G code and LUA editors, so that subsystem is now required.  It is possible that installing the .net stuff also installed a missing printing subsystem, etc... 

There is a program called Dependency Walker that is used for figuring stuff like this out.  But I will be the first to say that it is cryptic and hard to use.  But if you strip down the OS to the point of the application not being able to run, you may have to use a tool like Dependency Walker to figure out what is needed.  Or, get lucky and install something like .net that happens to also install the needed dependency. 

Since Mach 4 is now running, but takes a long time to load, it may be a virus software thing.  For example, Windows Defender delays the loading of Mach when it is launched for the first time in a certain amount of time.  It scans the EXE and all of its' dependencies before launching.  And it can delay the launch for a ridiculous amount of time!  Excluding Mach4GUI.exe in Defender sizes the problem.  There is another post on this forum related to that.  So look for something like that. 

Also, think about upgrading your Operating System.  Microsoft ended support of XP on April 8, 2014.  So we are coming up on the 4 year anniversary of that date.  My current compiler (Visual Studio 2013) won't even run on XP!  Luckily, it will still compile an executable that will run on XP.  We have to do some tricks to even get an executable that will run on XP with 2013.  I would say the writing has been on the wall that XP is dead has been there for a good period of time now.  We are fixing to make the jump to the Visual Studio 2017 compiler and there is no guarantee that it will even produce an executable for XP.  If it doesn't, then that will end Mach 4 running on XP, for sure.  :(  My point being is that we are fast running into the possibility of not being able to support XP.  Windows 10 seems to be a very stable OS at this point.  As good or better than Windows XP. 

Steve