Hello Guest it is April 26, 2024, 02:39:13 AM

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

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

Steve

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

Steve

623
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

Steve


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

Steve

625
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.  ftp://machsupport.com/Mach4/DevlopmentVersions/Mach4Hobby_Installer-4.2.0.3713.exe

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

Steve

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

Steve

627
Mach4 General Discussion / Re: Mach4 does not support Unicode?
« on: March 08, 2018, 06:18:29 PM »
The RS274NGC spec is ASCII.  So nothing in a G code file can be other than that.  The parser parses 8 bits (one byte) at a time and has no support for two byte wide characters.  This limitation was also in Mach 3 and will most likely will never change.  

However, the GUI elements can contain UNICODE.  So users can see the text on buttons and other controls in their native character encoding.  But the core (where the interpreter resides) is all ASCII.  This includes the API to the core as well.  Strings passed to the API functions are char * (single byte NULL terminated strings).  This is why filenames must be ASCII.  The reason for this is cross platform capability (Linux and Mac) because only "char *" is standard between them.  I'm investigating ways around that but I have not found a solution yet.  I KNOW that wide character strings (where each character is always two bytes or more) can never work with "char *", but multi-byte encodings such as UTF-8 may.  It is a complex problem.  I certainly don't know much about mult-ibyte characters, as I grew up in a world of single byte characters. And I am hampered by the fact that my native language is English.

Mach 3 was Windows only and used ONE compiler.  Therefore, it used the Windows wide character format and MFC wide character strings.  This removed the constraints of the string format but forced the constraint using just one compiler without the hope of Mach 3 EVER running on another OS other than Windows.  I suspect that this is the reason that DeskCNC worked as well.  But as I said, even Mach 3 could only use ASCII characters in the G code.  

So this will remain a work in progress.  

Steve

628
Mach4 General Discussion / Re: Motor Configuration Problem
« on: March 08, 2018, 01:03:16 AM »
In the motor tuning tab of the configuration dialog, select the motor on the right first.  Just click on one.  Not the check box, but the item itself.

Steve

629
Mach4 General Discussion / Re: Coordinate Rotation
« on: March 05, 2018, 09:50:41 PM »
Anytime you use mcCntlGcodeExecuteWait or mcCntlGcodeExecute, you are firing up an new interpreter (which hasn't any rotation applied to it).  So you will need to check for rotation in those macros and apply it to the G code that those functions will execute. 

-- SV_ROTATION_X                   2135 stores X value from G68
-- SV_ROTATION_Y                   2136 stores Y value from G68
-- SV_ROTATION                       2137 stores Z value from G68


local inst = mc.mcGetInstance()
local grp15 = mcCntlGetModalGroup(inst, 15) -- G68 and G69 are in modal group 15.
CodeLine2 = ""

if (grp15 == 68) then
CodeLine2 = 'G68 X#2135 Y#2136 R#2137\n'
end

CodeLine2 = CodeLine2 .. 'G00 Z' .. PierceHeight .. '\n'
CodeLine2 = CodeLine2 .. 'F' .. ProgramFeedrate
mc.mcCntlGcodeExecuteWait(inst, CodeLine2)

Steve

630
Another one (work in process), but you will get the idea.

Steve