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: Spindle at Speed
« on: May 09, 2018, 06:50:59 PM »
If you are using the stock spindle wait, there is no return code because no m3 script exists.  I did increase the wait timeout to 20 seconds because it may take longer than 10 seconds to bring a 20K RPM spindle up to speed.  

If you are are using a m3 script, mcSpindleSetDirectionWait() will now return MERROR_TIMED OUT and the API docs reflect this.  I juuuuuuust fixed this and it will be in the next build.  

Also, the mcSignalWait() function will wait on ALL input signals instead of just the 64 general input signals for quite some time now.  As it was always supposed to.  So the docs do not mention a limitation, as there wasn't supposed to be one.  The issue was that the function was incorrectly ignoring the rest of the inputs.  

If you want more control over the spindle waits using signals, and don't want to wait up to 20 seconds for a timeout, then using the mcSignalWait() API function on ISIG_SPINDLE_AT_SPEED and AT_ZERO may be what you need.

I have been using the stock spindle wait with the signals on my personal machine since the beginning of Mach 4 time without issue.  The reason those signals are there is because I WANTED them for my machine! :)  I don't use any custom M3, M4, or M5 scripts.  In fact, I don't think I have ANY custom scripts other than M6 to run the tool changer.  The machine is a Matsuura MC500.  I installed Mach 4, wired my VFD outputs to some inputs and mapped the "at speed" and "at zero" input signals, and enabled them.  No drama at all.  It was intuitive.  I could run that very complex industrial machine (with all of the safety bells and whistles) with Mach 4 "out of the box" with no scripting required if I didn't want to use the tool changer.  

So when people complain about Mach 4 being difficult because you HAVE learn LUA to program it, I just don't get it.  If you THINK you need something custom, then either you have a Rube Goldberg device or something that just can't be shrink wrapped.  Tool changers are pretty much the only thing that falls into this category.  Otherwise, you may need to take a step back and think about if you have made a fundamental flaw in the retrofit or machine design.  VFDs can get a bit more complicated if you are using modbus.  But 99.9% of the hobby AND industrial milling machines really should not need much scripting at all.  It is when you want something SPECIAL that scripting is needed.


Mach4 General Discussion / Re: Spindle at Speed
« on: May 09, 2018, 02:30:12 AM »
I have just tested the at speed and at zero signals and they works perfectly.  

There are multiple spindles waits.

1. Time based (setup in the spindle range tab)
2. RPM feedback based (spindle stabilization)
3. Signal based.

Pick one method.  Not 2 or 3, but 1.  :)  

The stock (and default) default method is time based.  It does not require anything but setting up the ramp times in the spindle tab.  It does not require a m3.mcs script in the profile.  99% of the hobby users use this.

The signal based waiting also does NOT require a custom m3.mcs script.  If you have a m3 script, it will override the default behavior of the Core and you will have to duplicate the default behavior.  

For the signal based method.

1. Map and ENABLE the at speed signal.  You have to map it to an I/O object.  In this case, a coil from a modbus device.  Enabling the signal mapping is important as it will NOT work if it is not enabled.  That is how Mach know to look at the signal.  Otherwise, it will use the time based wait.  And if you have no times defined, the spindle will start instantly.  
2. DO not check the spindle stabilization check box in the spindle settings.  That is RPM feedback based.  And because the VFD will hopefully tell us it is stabilized with the signal.

So I downloaded a nice little modbus simulator and configured it along with the modbus plugin configuration.  I then mapped that modbus input to the spindle at speed input signal and enabled the signal.  I can now control my spindle at speed signal at will with it and thus, my spindle start wait.

If you are having problems with the spindle immediately starting, I suspect that the signal is not enabled.  Again, it has to be enabled and mapped.  Once it is enabled and mapped, issuing a M3 should block until it times out.  (approx 10 seconds).  Or your m3 script is not doing the right thing.  If you need a custom m3 script, have a look at the scripting manual.  It has spartan example of one.  It ALMOST duplicates the stock M3 behavior with the exception that it does NOT wait.  Use mcSpindleSetDirectionWait() to enable waiting on the spindle.  

Another thing you may need is the spindlespeed.mcs script.  This is run every time a S word is issued.  It is a handy way of setting a speed for a modbus controlled VFD.  

There is a plethora of documentation in the Doc folder in the Mach installation directory.  Scripting Manual, Mach4CoreAPI.chm, Operators Manual, G code manual, etc...  They may not cover everything, but I feel like they are pretty decent.  Try reading Fanuc manuals!  The problem is, as with most anything like this, the only way to REALLY understand the system is to read every one of the manuals, cover to cover, and then read them all again.  Sometimes several times!  :)  

And the manuals keep getting bigger.  I just updated the G code manual with a whole lot of things for the newest development builds.  3784 is on the FTP site if any are interested.  


Mach4 General Discussion / Re: Lua Stats
« on: May 03, 2018, 06:10:41 PM »
Any LUA compatible 5.2 module library can be placed in the Modules directory and used.


Maybe.  It depends on wxLUA.  I have to get 5.3 compiling with that first.  I want to move to wx3.2 when it comes out before I try getting 5.3 going.


No docs yet.  :(  And there is nothing that will list the properties of a control.  But there is a function to enumerate the controls of the screen.  But only in the very latest builds of Mach. 

For all controls that have a background image, there is a scale method property.  When a screen is built, you choose a resolution.  But the screen may not be actually run at that resolution.  Therefore, all of the controls and images are scaled accordingly.  Scaling controls is easy.  But scaling images is a bit harder.  Especially if the scaled image is BIGGER than the original image because pixels have to be added!  So that isn't a good thing at all.  The fix for that is make the image bigger (pixel wise) than it will ever be displayed scaled.  That way, the image is always scaled down.  But even scaling an image down has it's issues.  Now we are going from more pixels to less.  So there are multiple formulas (scale methods) that accomplish this in different ways.  Some images will look better when scaled with certain scale methods.  You have to choose the one that looks best for your image. 

In the hobby version, the buttons are standard Windows controls.  And they do things that I may never be able to "undo".  In the industrial versions, I wrote my own button that I have complete control over (Advnaced GUI controls).

Now, buttons with transparencies are problematic.  Because when the button is pressed, it does move up and to the left to give the effect of being pressed.  This is not an issue on an opaque image or regular button because all of the background is repainted.  But the background is transparent!  So that part of the background is NOT repainted.  It is not a bug, per say, but just how the windows operating system works.  In the hobby version, the buttons are standard Windows controls.  And they do things that I may never be able to "undo".  In the industrial versions, I wrote my own button that I have complete control over (Advnaced GUI controls).  I would need to see your screen set to determine what is going on.  If it is an actual bug or if it is the Windows stock button issue.  But I think from your description that it is the stock windows button issue.  So make a ticket with Bryanna and attach your profile package (Help -> Support -> Package Current Profile).  Tell her to send it to me. 


Mach4 General Discussion / Re: Debugging Lua code...
« on: March 12, 2018, 07:37:54 PM »
LOL!!!  You think?  I dunno...  It hurts my brain sometimes.  LOL

Paul Kulchenko (the author of ZeroBrane Studio) did a really nice job and he has been a pleasure to work with.  The version that comes with Mach is a special version that he did up for us since the original mcLuaEditor.exe that we did had some special things inside it.  So he duplicated all of that and made it a really nice integration.  I was at the point where I really needed to spend some time making mcLuaEditor better (add remote debugging capability, etc...) but why re-invent the wheel?  Oh, BTW, that whole ZeroBrane Studio editor is done in LUA.  That shows you the power of the wxWidgets/LUA combination.  


Mach4 General Discussion / Re: Debugging Lua code...
« on: March 12, 2018, 06:09:16 PM »
You can remote debug any script you want with ZeroBrane.  The script just has to have access to the mobdebug module and the lua sockets module.  The screen scripts have the package.path and package.cpath already setup for this.  Just do Operator->View Screen Script and look at the top of that code.  Cut and paste as needed. 

With ZeroBrane, you can now debug the screen scripts.  However, they are running in the screen (not the editor).  So to edit the code, one must exit out of the LUA editor and go back into the screen editor.  That is just the way it is.  Mainly because the scripts are compiled into one larger script.  But also because they are compiled and there is no way that the LUA editor is going to be able to compile the changes and insert them into the running screen.  It is why the ScreenScript.lua file is read only. 

Also, when editing a screen script from the properties of the object, a LUA editor is launched to edit it.  The script resides in the screen as a string.  So the screen writes that script out to a temporary file (so that the editor can open it).  The key thing here is that the screen launches the editor with a temporary file.  How do we know when you are done editing that temporary file?  Well...  because you closed the editor.  We can't tell that the editor closed the file, but we can tell if you closed the editor (because the Mach GUI opened it).  Currently, there is no way in the ZeroBrane editor to tell the Mach GUI if the temporary file is close and furthermore, there is nothing inside the Mach GUI to listen if there was.  Once the editor is closed, the screen compares the script in the temporary file to the string in the properties.  If they are different, then screen replaces the string with what was in the temporary file.  So leaving the editor open is not really an option.

Also note that if you try and open the screen LUA editor more than once, you will not succeed.  It will raise the existing instance of the LUA editor.  This is the default behavior of ZeroBrane Studio.  However, that can be changed in the user configuration.  Have a look at the ZeroBrane documentation on how to do this.  But also note that there can only be one LUA editor with a debug server running.  It uses TCP/IP ports in the background.  But a solution to the problem may be evident here.  Open the ZeroBrane editor from the GUI menu (this one will be the debug server).  Then edit the screen.  Each time you edit a script from an object property, a new editor will open.  So that you can edit it (and more importantly, close the editor to pick up the changes).  You'll just have to try it out.  Keep in mind that editing the any of the screen property scripts will cause the screen to regenerate the ScreenScript.lua file.  It only does this AFTER you exit the screen editor.  So if the ScreenScript.lua file is open in the first ZeroBrane editor will be stale.  The fix for that is to just close the ScreenScript.lua file before you exit the screen.  But your breakpoints may be lost or moved. 

All of this is why I outlined the way to debug the scripts in the manual like I did.  It is a solid and fool proof method for getting the job done.  It may have a lot of steps, but it has the desired results.  At least you guys now have the capability of using a debugger in the screen scripts where as before it was a lot more cumbersome with message boxes and SetLastError (called printf debugging in the programming world).

But the easiest thing to do to make debugging easier is "don't mess up" in the first place, right?  LOL


Mach4 General Discussion / Re: Debugging Lua code...
« on: March 12, 2018, 05:15:27 PM »
ZeroBrane is in the latest builds.  The ScreenEditor document (in the Docs folder) has a section on how to debug the screen scripts. 


Mach4 General Discussion / Re: Mach4 does not support Unicode?
« on: March 09, 2018, 04:01:01 AM »
There is a new build, 3713, that may help you and those looking for multi-byte character support.

Be aware the LUA strings can contain multi-byte characters, but it cannot properly count the length of such strings.  So be careful if you are using multi-byte characters with LUA.  Things will display correctly, but any string manipulation functions might not work are expected.

Also, the machine.ini in the profile's directory can't be edited and multi-byte characters inserted into it.  It will store them, but they are stored as UTF-8 encoded ASCII.  Once mach reads these, they are then converted to UNICODE.  But if you put a multi-byte character in that file manually with a text editor, it will not be read by Mach properly. 

Also, the G code file still need to be ASCII, so no multi-byte characters can exist in them.  But filename and paths should work now.  However, do not install Mach in a path that contains multi-byte characters.  That may not work.

Notice the filename in the screen shot below.  My wife is Korean and she taught me that.  :)


No, it is not possible.  Why?  Because of the Inter-Process Communication (IPC) that goes on behind the scenes.  There can be only one.  :(