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

241
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.  

Steve

242
Craig,

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.  

Steve

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

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

Steve

244
Craig,

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.  :)

Steve

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

Two separate licenses. 

246
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.  :(

Steve

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

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. 

Steve

248
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.   

Steve

249
Mach4 General Discussion / Re: Mach4 needs reset all the time
« on: May 31, 2017, 05:02:16 PM »
What you are describing is all motion controller/plugin related.  Probing works fine if the motion controller supports it.  The requiring reset all of the time indicates to me that the motion plugin is not correctly telling Mach when it has performed all of the requested movements.  If you open up the Mach log, you will probably see something like "waiting on motor stop report".  Also, this may happen if you have enabled an axis in Mach but not in the motion plugin, etc..  In this case, Mach will be waiting on a stop report for a motor that the motion plugin is not controlling. 

Steve

250
I would first start using the return code on the API functions to discover if there is an error or not.

local h0, rc = mc.mcRegGetHandle()
if (rc ~= mc.MERROR_NOERROR) then
    --- There is an error condition.
end

Steve