Messages

621

Mach4 General Discussion / Re: Mach 4 and Galil

« on: May 21, 2014, 12:06:45 AM »

I feel like the Galil plugin will be done about a month after Mach4 is released.  Now, when is that?  I don't know at the moment because all of these requests are going to take time to implement.  And we'll need documentation too.  The problem is that I can't work on both Mach and Galil plugin at the same time.  I've tried it!  But it turns out that I actually need two hands on one keyboard.    So Mach first, Galil second.

The movement with the Galil is solid.  I even have it probing and homing.  But it needs MPG support and lots of work on the configuration dialog.  Meaning as of right now, I'm putting a lot of text parameters in a file by hand.  It needs polishing.  I'd call it 98% done.  If I had a solid week to work on it AND Mach didn't change in the interim, I could stick a fork in it.  But I run Ethernet controllers.  I don't have the means to test any PCI controllers, so that may take more time.  And ISA and USB Galil support has been dropped, so don't expect those to ever work with Mach 4.

The Galil is actually the oldest Mach 4 motion plugin.  (Hmm...  I wonder how that happened?)    It is also, by that virtue, the one that has had to be changed the most to hit a constantly moving target.

So, again, it really depends on how long it takes to get Mach released.  And I really can't nail that down at all right now.    Sorry.

My machine is a Matsuura MC500 with a 16 pod tool changer.  The tool changer is run completely from the Galil.  When the Galil plugin is released, it will be industrial strength at least on the Ethernet controllers that run analog servo driven 3 axis mills.  I can't speak to gantry systems, as I don't have one.

I have Mach 3 running my machine to perfection.  So don't discount that option either.  It is a MUCH better controller than the original YASNAC ever thought about being.  We have customers that are shipping new production machines to industrial environments with the Mach 3/Galil combo.  It rocks.

Steve

622

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: May 20, 2014, 07:23:47 PM »

Mach4 does not like metric it goes mad

That is because I don't like metric and I go mad!    Seriously though, we are aware of it and we are working on it.

Steve

623

Mach4 General Discussion / Re: Mach 4 and Galil

« on: May 20, 2014, 07:22:23 PM »

Two Issues to Clarify

Have Galil board:  Galil has a nice simple program language.  How to convert G code to Galil language.  Surely this has been done and completely checked out?  Can we have a single standard unified program for this--- checked for quality.  Any comments.

Second Issue:  Where are the motion control board guys on the critical path to completion of whatever they are working on?

Have a lathe Leblond 17x80 want to try Mach 4 now.  Nearly ready with mechanicals servo cabinet etc,

Galil can't do constant velocity with it's simple programming language.  Therefore, we do the trajectory planning and feed it to the Galil via a motion plugin.  This is just one of the reasons that G code doesn't "convert" well to the Galil command set.  BobCad did a post processor for their CAM software back around v19 to v21.  It worked for 2D stuff only.  But that was about as it got and it certainly wasn't a G code converter because it bypassed the G code completely.

I have a Galil plugin for Mach 4 that moves my machine quite nicely.  But it is not ready for prime time.  Lots of testing still to do.  Other motion controllers such as the parallel port, Ethernet Smooth Stepper, Vital Systems HiCON and DSP-MC are coming along as well. 

Steve

624

Mach4 General Discussion / Re: ScreenSet Question

« on: May 16, 2014, 12:24:34 PM »

MPG is one area that you will see a huge improvement.  It will be up to the motion controller to support the MPGs, so no plugin required other than the one for the motion controller.  Basically, the motion controller will need to accept encoder inputs.  Most do.  If there is some sort of "encoder input" card/board/device, I'm sure a plugin can be written for it.

Steve

625

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: May 16, 2014, 12:15:43 PM »

Just so you guys know...  There is nothing wrong with using CPU.  If it makes the machine more pleasant to operate with faster refresh rates, then there is no reason not to have it.  But there is a limit since we are running on top of an operating system.  I have on machine (pretty new) that I have set to 10ms refresh rates.  My older machines can't take as much.  So we decided to make that a "tunable" setting.  That way, you can get it to run on just about any machine in the XP era. 

It is just not the CPU though.  It has a lot to do with the video card as well.  Some video cards use the CPU to do the video processing!  Those are the ones that will eat CPU like it is going out of style with the faster refresh rates.

Steve

626

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: May 15, 2014, 10:56:59 PM »

You can lower the refresh rates in the screen editor.  Click on the top element in the Screen Tree Manager and it is the "Refresh Interval".  It defaults to 50ms.  100ms would be more of a Mach3 speed.

Steve

627

Mach4 General Discussion / Re: Export tool table

« on: May 15, 2014, 08:14:25 PM »

The LUA stuff is dry reading isn't it?!?!?!  I bought the books.  I don't think I finished any of them.  I instead search the internet for examples.  I can stay awake that way...

Steve

628

Mach4 General Discussion / Re: MACH4 - Modbus

« on: May 15, 2014, 01:15:28 PM »

I think I have mentioned it before, but it is worth mentioning it again.  There are two instances of LUA.  One in the GUI and one in the mcLua plugin.  The mcLUA plugin is there so that M codes will run regardless of what GUI is driving the core.  It is NOT connected to the Mach4GUI in any way.  However, communication between the two LUA instances is possible with Mach registers.  But mcLua plugin based scripts and functions cannot see the Screen scripts as the screen scripts are imbedded into the screen set.

Mach 4 is written so that any developer can write their own GUI for the core.  It can be written in C++, C#, VB, or any other language that supports loading of DLLs.  We have two GUIs at the moment as an example of this.  Mach4GUI and the wxMach "static" GUI.  The static GUI is just that, static and not changeable.  I do have a sample GUI written in C# that I played with.  wxMach does not have a configurable screen and has no screen based scripting functions.  It does, however, have a PLC script.  So that is the reason for the separate LUA instances.

So on to global functions...  

If you want a global function that can be called from any screen object script, put the functions in the screen load script.  Then they will be available to all screen object scripts.

If you want a global function to be available to all M code "macro" scripts, put a file in the macro directory containing the global script functions.  The file can be named anything as long as the extension is ".mcs".  Say you named the file "myGlobalScripts.mcs".  You can write this file using the mcLuaEditor.  It is prudent to test the scripts (debug) and "compile" the file inside the mcLuaEditor to check for syntax errors.  The act of compiling the *.msc file will generate a *.mcc binary file.  Then when you press cycle start the first time, ALL of the *.mcc files in the macros directory will be combined into one LUA program called wxLua.mcc.  This is the chunk that gets loaded.

What if you want the same global functions in the screen and macro scripts?  You can duplicate the code in the screen load and the macros directory or you can "include" the code from the file system in each LUA instance.  This "shared" code should be put in a global directory.  Meaning not a profile's macro directory.  Something more along the lines of a "Modules" directory in the Mach4 installation.  That way all profiles or screens in you installation can access it regardless of if you happen to delete a profile or two.  But I won't get into how to do all of this.  The LUA manuals cover it.  

Oh another thing...  DO NOT expect any scripts that Brian or I post to just work.  They are hand typed generalized examples of how to get something done.  They are usually typed on-the-fly as we answer a post and they may not be perfect.  They are close.  But the only way to ensure they are perfect is to put them into the LUA editor, compile them, and tests them.  That is not something we have time to do when answering a posts.  It is an exercise for the user to make them work. 

Steve

629

Mach4 General Discussion / Re: Mach 4 Hobby Demo build 1767 is available

« on: May 14, 2014, 09:45:56 PM »

I thought sense the Keyboard plugin could call an internal function like X+ it should be able to call the internal functions such as Cycle start. 

But it seems it can't without Lua scripting.

Thanks (;-) TP

Not yet.  I have some things in mind for it.  That plugin will get more love soon.

Steve

630

Mach4 General Discussion / Re: Mach 4 Hobby Demo build 1767 is available

« on: May 14, 2014, 08:14:20 PM »

Yes.  It can.  You might have to do a little scripting.  But it is possible.

Steve