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

201
Mach4 General Discussion / Re: Mach4 takes 30 seconds to start
« on: November 03, 2017, 07:16:44 PM »
Yeah, on Win7-32, my Atom board loaded Mach quicker than my 8 core Win 10 machine (4GHz w/ 64Gb RAM plus dual GPUs) did with spin disks.  The SSD addition to my desktop reduced the time significantly.  It will load Mach in less than 10 seconds (wx4.set) even with the initial load hit, About 5 seconds being the norm.  The initial program is loaded very quickly with the most amount of time being spend loading the GUI elements.  We track a LOT of things, so I know why that takes a time hit.  I wish I could find a way of loading the screen set more quickly.  

The Atom does, however, suffer when loading bigger G code files.  :(  But that's fine.  So I KNOW it is something on my Win10 machine that slows the initial load down.  I haven't tried to put my finger on it completely yet and have really just assumed that it was Windows Defender real-time scanning.

Like Craig, I don't run any anti-virus on my "production" Atom board.  But I do run Defender on my development desktop just because I touch the dirty internet with it.

Steve

202
Mach4 General Discussion / Re: Update error
« on: November 02, 2017, 11:35:14 PM »
The update and modify scripts have changed.  If the scripts exist, they must return a value, otherwise, the control will not get updated.  Even if the actual value isn't changed!

-- Example encoder update script.
local inst = mc.mcGetInstance()
local val = select(1,...) -- Get the system value.
val = tonumber(val) -- The value may be a number or a string.  Convert as needed.
local name = select(2, ...) -- Get the control name.  It is always a string.  You may not need it.  But it is there if you do.
val = val / 1024 -- convert the encoder value to a decimal (assumes 1024 counts per unit).

return val -- the script MUST return a value, otherwise, the control will not be updated.

In your script functions, it would be just a slight change.

Add
local val = select(1,...) -- Get the system value.

to the top of each script and

return val

to the bottom of each script. 

But that is not all.  The error states that the 4th parameter (XWear) is nil.  XWear is pulled from the droXWearOffset DRO.  So I'm thinking that there is an update script that needs to be looked at (probably the same modification as above). 

Steve

Steve

203
Mach4 General Discussion / Re: Signal vs IO and Aliases
« on: November 02, 2017, 01:41:03 PM »
I/O is provided by plugin devices.  I/O can be "mapped" to Mach signals.  In theory, one should be able to bypass mapping an I/O point and just twizzle the I/O without a Mach signal.  For like a script that just wants to toggle an output or look at an input that otherwise Mach doesn't need to know about. 

You need to provide a complete path to the mcIoGetHandle function.  As in add a beginning "/" character to it for "/modbus0/function1/fwdrevbit".  That might do it.  Otherwise, there may be a bug in the LUA binding for that function as not many have probably used it.  MOST of the time, it is just easier to map the I/O to a Mach signal. 

Steve

204
Mach4 General Discussion / Re: Mach4 takes 30 seconds to start
« on: November 02, 2017, 01:29:02 PM »
It is the real-time scan feature that seems to do it.  And I don't think it follows the exclusions.  I may be wrong though.  But I noticed it when I went from 7 to 10.  It is disk speed related because I moved to a SSD and the issue is not nearly as noticeable.  Mach is not a particularly big program.  And it is all C++ and doesn't use .NET stuff that has to be "assembled" at run-time.  So all things considered, it really should load fast.  I will say that there is nothing that we are doing to make is load slow.  Of course, the more screen elements that exist in the screen set, the longer it takes to load.  No getting around that.  :(

I can make it load slower by compiling a new GUI executable.  This makes the signature of the program change.  And at that point, Windows goes into slow load mode for the first time I run the new GUI.  But after the first load, it loads quickly.  It may also have something to do with the PC/processor's memory and/or disk cache.

Steve

205
Mach4 General Discussion / Re: Mach4 takes 30 seconds to start
« on: November 02, 2017, 03:02:25 AM »
If the program hasn't started in a while, Windows Defender will do a scan on it first, thus increasing the startup time.  There may be some settings that one can tweak to alleviate the pain, I don't know.

Steve

206
Here is a link:  http://www.ebay.com/itm/OMRON-Z-15GQ22-B7-K-Snap-Swch-15A-SPDT-Panel-Mt-Roller-Plngr-/321485205824?epid=691253239&hash=item4ada02f140:g:rjsAAOSwtfhYtaK9

You can find them cheaper.  But they may not be "real" Omron, but copies.  You said "quality", so I would go with the real deal from Japan.  So ~$115.00 you can get 8 switches and have limit+- and home for X and Y, and limit+ and home for Z.

That model may not be what you want.  They make "drip proof" designs that may have better coolant protection. 

Or...  get the real thing used.  http://www.ebay.com/itm/OMRON-LIMIT-SWITCH-4VBD4-1N-10A125-250VAC-4-POSITION-/162653739387?hash=item25deeb197b:g:XwcAAOSwYlRZLu26

That will do one axis.  It has 4 switches for limit +, limit -, home, and slow down.  The slow down switch can be used for high speed homing that automatically slows down a certain distance from the home switch so that you don't have to run a 40" travel at 1 IPM (if your motion controller has that option).  :)

Using the index pulse for repeat ability is the only way to go, IMHO.   

Steve

207
Yes!!!!  This is one of my pet peeves.  Eliminate the one switch wonders with extreme prejudice!  It just makes life sooooooo much better.  Life is short.  Why let one switch wonders ruin it?  LOL  Buy a few $13.00 switches and be happy! 

To the OP, those limit switches that Craig pointed to have been used on many many CNC machines.  My Matsuura MC500 has them on it.  They are mostly used in center mounted positions with ramps to engage the switches at the ends of the table/stage.  These ramps eliminate the issue of a runaway crunching the switch.   Meaning that the plunger of the switch is mounted perpendicular to the movement of the table instead of inline with the movement.  The table has the ramps mounted in inline with the direction of movement.  The ramps have a starting slope, a slew, and a trailing slope and are of a height that will never be more than the travel of the switch plunger.  This is a solid configuration that prevents damage and naturally keeps coolant away from them as they are usually well under the table.  They can be enclosed in boxes (and most are) to further limit coolant ingress.  I call these "the $13.00 switch" because as Craig noted, that's about what you pay for them. 

On thing though...  do not run mechanical switches on logic level voltages (5v or less).  Use 12v at a minimum with 24v being preferable. 

The prox switches are pretty nice since a lot of the time they are already pretty much coolant proof.  And if you are wanting to switch at logic level voltages, these are the better choice. 

Steve

208
Mach4 General Discussion / Re: New user - ToolPath Not Showing
« on: September 18, 2017, 12:45:02 AM »
There is an option in the Tool Path tab to revert to the older OpenGL code.  It might work for you.  I can't make any guarantees, though.  But it might be worth a shot. 

Steve

209
Mach4 General Discussion / Re: Canned solutions? M6 and others....
« on: September 18, 2017, 12:43:06 AM »
If it were a snake, it would have bitten you.  :)  Have a look in the LuaExamples\Toolchanger directory of your Mach 4 installation.  There you will find and assortment of tool changer M6 macros.  One of them will do exactly (or close to) what you want.  And if it doesn't, then what you are wanting to do doesn't fit the handful of basic operations.  Luckily, we gave you the ability to do anything you want with a tool changer.  But at that point, you will have to make it do your bidding with a small amount of LUA self education.  It isn't rocket science.  And the forum is here for help if you need it.  

MOST of the time when people are having to write code it is because they DO want something special.  Or they THINK they need something special and just don't know any better because the first time they thought about a CNC machine was the week before when they ordered it.  I'm speaking from experience because yeah...  I used to be that guy that didn't know any better.  Everybody starts at square one.  

95% of the time, people just buy a machine that already had Mach installed and configured.  This forum makes up the 5% that don't do that.  This group of people either retrofitted an existing machine, or built their own.  Like it or not, they are now the machine control integrator.  In both cases, each person has (knowingly or not) accepted the challenge of having to do more than the 95% did.  

If you don't have an auto changer, have you thought about not even messing with M6 codes in a program?  I write (or generate) a G code file per tool and just run them separately.  Way less hassle, IMHO.  

Steve

210
Mach4 General Discussion / Re: lua error or is it
« on: September 15, 2017, 10:32:51 PM »
Guys, you really can't "debug" the PLC script like a macro.  Why?  Because the PLC script is only part of a larger script.  If you do Operator->Lau Script, you will see ALL of the screen scripts merged together.  What you will find is that testcount is declared in the screen load script. 

The reason all of the various scripts are merged together is so that each script can access these global variables.  The scripts are all merged to form one "LUA chunk". 

So to debug the PLC script, one can do Operator->Lau Script, copy the contents, and then past the whole script into the mcLuaEditor.  Then, at the bottom, insert a line that calls the PLC script function. 

Steve