Hello Guest it is February 28, 2020, 07:38:10 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

Mach4 General Discussion / Re: What do Control Modes Change?
« on: June 13, 2017, 06:28:16 PM »
The control mode changes the interpreter that is used.  Basically, a 3D printer can be used with Mill.  There won't be many differences between the 3D and Mill interpreters.  The major difference is that some 3D printers use the C axis as the extruder feed.  This will be whatever mode the machine is in (ABS or INC) depending on G90 or G91.  So the 3D interpreter adds an E axis that can moves C incrementally regardless of the G90/G91 setting.  Basically E shadows C.  M83 turns E into incremental mode.  M82 turns E into ABS mode.  

At least that is my understanding of it.  But I'm no 3D printer guru either.  


Mach4 General Discussion / Re: subroutines?
« on: June 13, 2017, 06:05:07 PM »
The files in the subroutine folder can contain only one subroutine each.  And the subroutine must have a a proper O line at the top that matches the base file name.  There is no limit to the number of subroutines that you can put in this folder as long as they are unique subroutine numbers. 


Mach4 General Discussion / Re: LOVING the PMC!! Thanks Steve!!!
« on: June 09, 2017, 06:23:59 PM »
Ok Arturo, I think I have it.  Thanks for the example because the math portion was working correctly.  The error was with reading and writing registers.  The fix will be in the next build.  



Yeah, well...  time will tell.  The road is paved with protocols and ideas that never got out of the way of the traffic.  Some of these where indeed better ideas.  There were lots of "better" Modbus type protocols but yet Modbus remains.  Yaskawa had Mechatrolink that they are now abandoning.  Then there was the BetaMax vs. VHS battle.  Technically, BetaMax was better but yet VHS endured.  At this point, it does look like EtherCat is the "survivor" of these type of technologies.  But will the rest of the world move to it?  It is hard to say.  I know people that want to move to something like EtherCat and then I know others that say "No way!  Why?  We already move motors with a proven way.  Why is it needed?"  It does offer a better way of handling a distributed system.  But does every system need to be a distributed system?  

One of the things that EtherCat suffers from is that it gives a set of standards but fails to define how those very standards should be implemented.  For example (and it is a loose example), they may define that an EtherCat slave servo motor drive should have a velocity register.  But the EtherCat specification doesn't specify what the velocity is.  Is it counts per second squared?  Or just counts per second?  Or is it mm/s?  Or some dreamed up unit that the manufacturer came up with?  So all of the EtherCat hardware manufactures seem to do it all a bit differently.  They all seem to WANT to be on the EtherCat bandwagon, but they all want to do it their own way.  All of these manufacturers want you to buy EVERYTHING from them.  The controller, the servo drive, and the motor.  So the tendency to make something "special" is undeniable.  Until they just can't anymore.  

At this point, all of the EtherCat controllers either only support a few servo drive manufacturers or their systems need to be flexible enough to "define" what they are talking to.  Even though the basic technology (EtherCat) is the same!  This makes configuring an EtherCat system a lot more difficult than it really needs to be.  And in no way is it to the point where you can just hook anything EtherCat from manufacturer X to anything else EtherCat from manufacturer Y and have it all work.  So, in my opinion, the jury is still out because it just hasn't matured enough.  Others will disagree.  

Windows does NOT have what it takes to ever be a real-time system.  It will never be "real-time enough" to get the job done.  It has a hard time even calculating what a millisecond of time is.  Forget microsecond and nanoseconds.  All of the systems that use Windows for real-time are not really using Windows at all but are rather using another operating system hidden behind the scenes.  It is very much the case where two machines running, one real-time and the other Windows, on the same hardware.  There are multiple ways to do this, but the common idea is that Windows doesn't do the real-time processing, ever.  It just looks like it does.  


Mach4 General Discussion / Re: LOVING the PMC!! Thanks Steve!!!
« on: June 09, 2017, 12:36:00 PM »

I need an example.  Because what I just tested works.  Can you post the PMC file? 



EtherCat can be done with the Galil.  Their 5000 series controllers are basically 4000 series controllers with EtherCat.  Also, there are several EtherCat controller companies that are working on Mach 4 plugins.  The Galil can go right now, but others are coming. 

BTW, Mach 4 was demonstrated running a Galil EtherCat controller running Yaskawa drives and motors at IMTS 2014.  :)


Mach4 General Discussion / Re: Module Works Simulator
« on: June 01, 2017, 01:28:45 PM »
No HiCON files. 

Two separate licenses. 

Mach4 General Discussion / Re: Module Works Simulator
« on: June 01, 2017, 01:57:08 AM »
Mach personnel didn't write the plugin.  ModuleWorks did.  All we can do is load it up and test it.  Just like you.  And it works fine for me, so I don't know what the problem is.  :(


Mach4 General Discussion / Re: mcRegGetValue returns unexpected value
« on: June 01, 2017, 01:46:18 AM »

LUA is not multi-threaded as there is nothing protecting the global data tables.  So each instance runs in its' own space (with its' own global data and message loop, etc...).  Each LUA panel has one instance of LUA associated with it.  You can share code between the instances by requiring a module.  But the global data of one instance cannot be accesses from one instance to the next, etc...  So storing the address of a module table variable from one instance in a register and trying to use it in another instance will lead to "bad news".  The only really safe way to share data across LUA instances is with the Mach registers (because these registers are thread safe and mutexed).

In Mach, these are the LUA instances:
1. One instance for the GUI (runs the screen scripts)
2. One instance for the mcLua macro script plugin. (runs M codes)
3. One instance for the PMC (runs the ladder code)
4. And one instance per LUA panel in the GUI.

All of these instances have access to the MachAPI functions.
Only the GUI has access to the ScreenAPI functions. 


Mach4 General Discussion / Re: Module Works Simulator
« on: May 31, 2017, 06:52:15 PM »
Plugins don't have to be at the same build level.  All of the Mach supplied plugins (in the installer) are the same level because they get built at the same time as the Core and GUI.  So a plugin from a different developer can be different.  Some developers may choose to put the Mach build level at which they compiled against (looks to be what ModuleWorks has done).  Unless the Mach API changes, there isn't a need to make a new plugin build other than fixing things or adding functionality.