Messages

981

Mach4 General Discussion / Re: Mach 4 Feature Request

« on: September 22, 2014, 01:40:54 PM »

Mach 4 has and never will close the servo loop.  It doesn't need to.

The loop can be close in three places:

1) The motion control software. (Mach does not do this.  Windows is not a real time OS).
2) The motion controller hardware.  (Galil, Vital System DSPMC, K-Flop, etc...)
3) The servo drive (Position controlled drives that take step/dir as input).

And we are talking servos here.  Steppers are generally never closed loop.

In the absence of #1 above, software never needs to close the loop.  The software can generate the motion profile without the loop being closed.  This is analogous to you in a car driving from your driveway to the stop sign down the street.  You plan your route (motion profile) before getting in your car (software).  Once in you car (hardware), it is your job to follow the planned route.  If you don't make it to the stop sign, you apply more throttle to get you there.  If you go past the stop sign, you put the car in reverse and apply throttle to get you there.  The end point didn't change and thus the route doesn't need to either. 

So if the loop is closed on the motion controller or servo drive, then there is no need for the software to close the loop. 

So to answer your question, any step/dir plugin that Mach4 supports will work with position controlled servo drives to close the loop.  Any plugin that Mach4 supports that closes the loop on the motion device will work with analog command controlled servo drives.

The Mach4/Galil combination running on my Matsuura MC500 is definitely closed loop.  It is using old school analog drives with PID filter on the Galil that manages the following error.  If you are retrofitting a machine with existing analog servo drives, using a plugin/controller that closes the loop on the controller is the way to go.

The newer and far more simple way is using position controlled drives.  Less tuning required as most of these type servo drive tune themselves.  If you are building a new machine or replacing the drives in an older machine in a retrofit, then this is the way to go.

When we were at IMTS, there were three machines demoing Mach4.  One used a Galil controller with Yaskawa EtherCat servo drives.  (Servo loop closed on the Galil).  Another used an ACS controller with Yaskawa EtherCat servo drives.  (Servo loop closed on the ASC controler).  And then another machine that used a Vital System HiCON controller outputting Step/Dir signals to Yaskawa position controlled servo drives.  (Servo loop closed on the drives).  All of these machines worked flawlessly.

We really had a good show at IMTS.  Mach Motion did a fine job!  The machine using the HiCON was running a SolidCam produced high speed pocketing tool path that was moving the machine @ 600 IPM.  It was simply amazing to watch a 3/16" end mill remove a 5/8" pocket depth of metal in 1018 steel in a matter of 3 minutes.  With precision!  Industrial?  I would emphatically say yes!  The Mach4 machine was capable of keeping up with the Hurco that was also demoing the SolidCam tool paths.  Yeah...  we had something to grin about. 

All of the Mach4 machines were running Mach4 Hobby.  How is that for you guys?  Hobby priced software that can keep up with the big boys!  Videos of the show will be forthcoming.  So stay tuned!

Steve

982

Galil / Re: Galil controller compatability (what works with the plugin)

« on: September 05, 2014, 07:58:58 PM »

No parallel port required with Galil.  Stay away from the ISA controller.  It will only work with SmartTerm drivers and that limits you for the future.  The 2200 is ok, but 41x3 or 40x0 is the controllers that we are targeting for Mach 4.

Steve

983

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: September 04, 2014, 07:46:03 PM »

Make sure the axes are enabled.  1953 runs fine so far from other reports.  So there is a problem with the config or something.

To further explain...  The Zero buttons are greyed out based on the availability of the axis.  Same with the jog buttons.  Since yours are greyed out, it makes me think that the axes are not enabled.  So check that out and see.

Steve

984

Mach4 General Discussion / Re: Screen Set Ideas

« on: September 03, 2014, 07:22:21 PM »

Man, that's a lot of info.

I sure hope they add the ability to create our own LED's, as those round ones look like they came from a DOS program..

What is wrong with the LEDs?  The fact that they are round?  If so, you just change the shape property to square and get Mach3 style LEDs.

Steve

985

Mach4 General Discussion / Re: Making MACROS turn on OUTPUTs faster by inlining your code!!

« on: August 28, 2014, 03:01:49 AM »

Yeah, the only problem is that M10 and M11 are for turning a pallet or axis clamp on and off on Fanucs.  Sometimes they are used to turn vacuum on a table on and off.  So I really don't want to use those.  And I really don't want to use M codes at all because M codes currently break the CV chain and we would have to add an exception.  But we may have to.  I would rather join up with LinuxCNC and try to create a standard than try to create something from scratch or use some code that already has uses.

Mach 4 mill (and lathe is almost done) is what we currently have.  Lathe is a whole separate interpreter!  We plan on having a separate G code interpreters for laser, plasma, water jets, and tangential knifes.  These will come at at later date.  One interpreter doesn't have to do it all in Mach 4.  Until then, try the sleep trick and see if you can get it better.  I'm pretty amazed at what you are doing with the laser and the mill interpreter!

Steve

986

Mach4 General Discussion / Re: Making MACROS turn on OUTPUTs faster by inlining your code!!

« on: August 28, 2014, 01:30:10 AM »

Yes, they are quick!  The issue is because Mach4 doesn't know exactly when the last movement was done on the motion controller.  Mach4 holds up the M code until the last way point is sent to the motion controller.  But there is going to be some latency involved between the time the data was sent and movement actually is done.  So the physical motion always lags the as compared to the position in the G code file.  This latency is PC/motion controller specific and will be different on just about every system. 

The good news is that you can slow up the M codes with a wx.wxMilliSleep(ms) call.  If you are consistently 10ms fast, do wx.wxMilliSleep(10) in the first line of the M code.   

That is something to try, but it is not the best solution.  Eventually, we will have a facility to turn on output in coordination with motion.  We may use the LinuxCNC M62 and M63 type of thing.  It seems that there is no standard at all to follow.  Maybe if we do it like LinuxCNC does, it will "create" a standard.  Only LinuxCNC's current form doesn't go far enough, IMHO.  They only provide for turning output on or off at the beginning of a move.  It would be nice to be able to do the same at the end of a move.  Then there is CV to consider!  It all gets a bit complicated.

http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M62-M65

M62 P1 (Turn output 1 on at the beginning of next move)
M63 P2 (Turn output 2 off at the beginning of next move)
G01 X1 Y1 (The movement.  Outputs 1 and 2 will be coordinated with the start of this motion.)

Steve

987

Mach4 General Discussion / Re: Lua Panels and events

« on: August 27, 2014, 07:38:20 PM »

I would add a panel on top of the parent panel.  The parent panel actually resides in mach4gui and any click events are going to be eaten by the GUI. 

Steve

988

Mach4 General Discussion / Re: Mach 4 Feature Request

« on: August 27, 2014, 07:34:24 PM »

Limit override is simple.  Add a toggle button to the screen and tie it to the limit override output signal.  Done.  Or if you prefer a real switch on the panel, map it's I/O to the limit override INPUT signal.

989

Mach4 General Discussion / Re: Embedding the "Mach MAD" for 4, into a screen set! Still got stuff to do!

« on: August 05, 2014, 01:15:27 PM »

Nice work Scott!

Steve

990

Mach4 General Discussion / Re: Mach 4 Bug Reports

« on: July 21, 2014, 07:22:06 PM »

I have Mach 4 running on my old Pentium 4 2.8 Ghz with the last gen ATI AGP video card.  4 Gigs of mem.  Mach 4 will run on that without issue.

I also have Mach 4 running on my Atom based D2700MUD board.  This board has the Intel GMA-3650 video chip set and it is not a great performer.  I thought I would buy this board and put Linux on it and that it would be sufficient.  But there are no video drivers for Linux and the GMA-3650 and there never will be.  The ONLY operating system that is supported on this board is Windows 7 32.  Although I'm not real happy about the D2700MUD board, it will run Mach 4.  The video is just not as snappy as I would like it to be.

The only minimum spec we just have to have is a video chip set that is capable of at least OpenGL 1.5 to use the Vertex Buffer Objects (VBO) tool path.  However, I put an old PCI video card in that old Pentium 4 box (above) that only supported OpenGL 1.1 and I got it to work with the config switch to turn off VBO tool path.  

And I actually got Mach 4 running in a virtual machine too.  VMWare Workstation version 7.  It mimics OpenGL 1.1 too.  Although OpenGL is supported in that VM, it is not good.  The tool path is clunky and would not be good for a real machine's controller.  So that brings me to my next point: Just because the specs say it will do OpenGL x.x doesn't mean it will do it well.  

Any machine that runs CAD well will run Mach 4 well.  

Things to stay away from:

1.  Integrated video chip sets.  Some are good.  But it depends on how the MB manufacture implements them.  I have seen the GMA-4500 work well on one board and not on another.  They are a gamble.  Are you lucky?
2.  RealTek integrated Ethernet controllers.  Pure junk.  No transmit capabilities.  For people with external Ethernet based controllers like ESS, HiCON, and Galil, etc...  this combo is just not going to work well.

Steve