Messages

511

Mach4 General Discussion / Re: Screen Set Property Descriptions

« on: February 09, 2019, 09:55:22 PM »

There is no documentation of our internal screen format.  You are own your own in there...  I will say that the font property is specific to the OS and I have NO idea what it comprises. 

No Bg color is transparent in some places and opaque in others.  Again, this is an OS thing.  You pretty much can't have a transparent tab in MS Windows.  So the controls that are laid upon a tab WILL take on the tab Bg Color.

It is not possible for a user to create new label codes.  They have to be programmed into the GUI.  If you have ideas for some, put them in the feature request thread. 

SysVars are G code variables.  #100, #1100, #1200, etc...  SysVars can be used to create custom parametric G code programs. 

SysParams are system parameters.  SysParams define the control behavior.  They are changed with G10L50 and read with PRM[ x ] (where x is the desired parameter).  There are not many things a user would ever need to change in the SysParams.  Most of these only pertain to the Industrial license with Macro B.  Tool life management, Custom G codes, etc... 

The DRO font size is intetionally programmed to fill the height of the element.  If that doesn't fit the desired look, then make the DRO flat with no border and put a faux background bitmap behind it.  The sky is the limit.

Steve

512

Mach4 General Discussion / Re: Sending Info to a Database from a Script

« on: February 08, 2019, 03:48:53 PM »

Because LuaSQL via Luarocks was not installing - maybe I did not need to do that ...
We went to the odbc driver for a MySQL connection and set up the connection in the windows ODBC connection.

We provide the luasql modules in the Mach installation forlder's "Modules" directory.  Luarocks isn't needed or desired unless you have a separate LUA installation that you also want to have lausql connectivity. 

I will double check to see if MySQL installer placed them in the %path% variable but I think that is correct - I try to point to the original rather than a copy located elsewhere - as upgrades may / will require that specific version. Just easier.

The MySQL installer didn't put ANYTHING in my PATH.  I had to add it myself.  My installation is in C:\MySql, so what I added to the PATH environment variable was "C:\MySQL\lib", as that is where the client DLL files were.  I also added "C:\MySQL\bin" for grins. 

" I set one up and the script ran flawlessly. "
Did you run the script from with in Mach4 ? as a Macro or regular .LUA script  ?

I ran the script from the Zerobrane editor.  Mach running, do the menu path Operator -> Open Script Editor.  Then open the file from my last post.  You can then step through the program line by line.  Hit F5 to start the program.  It will pause on the first line, then hit F10 to advance to the next line.  This is called single stepping.  Anyway, when it gets to the line where it "requires" the module step past that.  If you get an error there then that means luasql can't find the libmysql.dll dependency.  The error message is misleading.  It says that lua can't find luasql\mysql.dll in the specified directory.  However, if you look in that directory, it is indeed there.  So yes, that is misleading.  But that is more of a Windows thing than a LUA thing. 

I intend to call this with a MCode from a GCode script that our machinist wrote .

That will work.  I ran it from within the editor to test it.  But that code could be put into a macro script and it would be fine. 

I meant to ask about this line of code
package.path = package.path .. ";.\\Modules\\?.lua;"

It seems to be a generic folder  where we point to .Lua files could you give a quick what it is , and that syntax represents ??

Well.  those are the lines I added to the example on the luasql site.  That is the LUA equivalent of the PATH environment variable (package.path and package.cpath).  They are search directories.  So what those lines do is add our Modules directory to the directories that are searched when we try and load a module.  So lets examine the string that we appended:

";.\\Modules\\?.lua;"

";" is a path separator, just like what is used in the PATH environment variable. 
"." means "current directory".  This is used when we provide a relative path.  An absolute path could be used as well, such as "C:\\Mach4Hobby\\Modules\\?.lua".  But the relative path is used because we always have the Mach installation directory as the current working directory when launching scripts. 
"\\Modules\\" is the part of the path that points to the Modules directory.
"?.lua;" specifies the valid file extention. 

A lot of times you might do something like this:

package.path = package.path .. ";.\\Modules\\?.lua;.\\Modules\\?.mcs"

This will look for files with *.lua and *.mcs extentions. 

package.cpath will always need to look for *.dll files on Windows (*.so files on Linux). 

Anyway, look in your Mach installation's Modules directory to see what all we provide for extending LUA.  There are modules like luars232 for serial comms and luasockets for network comms, etc...

Steve

513

Mach4 General Discussion / Re: Super Simple Screen Set (Mach4 Beta)

« on: February 07, 2019, 11:00:09 PM »

How did you get the texture look on the buttons?

They are bitmaps used with the bitmap button control.  The bitmaps were created by the author of the screen, Graham. 

Steve

514

Mach4 General Discussion / Re: LUA, repeat until

« on: February 07, 2019, 08:54:58 PM »

The reason the OOB axes can't be controlled by G code is because there are no letters left in the G code language left to control them!!!  Think about it.    ABCDEFGHIJKLMNOPQRSTUVWXYZ are all taken. 

UVW are the linear variants of ABC, if you were thinking that they could be used...

Also, mcJogIsJogging() may be interesting for this discussion. 

Steve

515

Mach4 General Discussion / Re: Sending Info to a Database from a Script

« on: February 07, 2019, 08:43:36 PM »

wxLua is LUA with bindings to the wxWidgets library.  You don't necessarily HAVE to use the wxWidgets bindings.  Just don't write code that uses anything with the "wx." prefix. 

The database should be doable.  We provide luasql for mySQL and ODBC.  However, neither will won't work by itself!  Database client software also needs to be installed.  For instance, if you installed an IBM DB2 client, it would install the ODBC driver.  For mySQL, the client files need to be installed on the machine, namely "libmysql.dll".  And these DLLs need to be in the PATH as well so that the luasql driver can find them.  Or copy them into the Mach4 installation folder.  But it is best to put their orignal location in the PATH environment variable though.

Attached is an example file from https://keplerproject.github.io/luasql/examples.html that I munged up to include our module paths.  It assumes that there is a database called "luasql-test" available that requires no password to access and alter.  I set one up and the script ran flawlessly. 

A mySQL database can also be accessed via ODBC with the following: https://dev.mysql.com/downloads/connector/odbc/  Install that and configure.  Then change the mysql specific stuff in that example file from myslq to odbc (lines 5 and 7). 

Steve

516

Mach4 General Discussion / Re: Mach4 LED's

« on: February 07, 2019, 07:48:12 PM »

All of the tools are there in the screen to implement what you want.  There is no LED in the wxWidgets framework.  So that "element" was custom coded.  This is different than buttons, as the wxWidgets framework implements stock Windows buttons.  In other words, a button on the Mach screen will look like a button in any other standard Windows application (that hasn't been dressed up).  The Terminal program Putty is a good example.  That being said, we allow the user to pretty much dress up any button they wish with the bitmap button and custom bitmaps.  My point is just because you don't see a screen element that does exactly what you want at first glance, don't assume that it can't be done. 

Back to the LEDs.  LED is an acronym for light emitting diode, as seen on many physical machine control panels.  And that is what I tried to make them look like.  Generally, people like the round LEDs because a round LED in Mach3 was not possible.  But sometimes a round LED is not what is needed or wanted, so there are properties in the control to set the shape.  You have a choice of round or square (rectangular, really).  But if you just plop a LED down on the screen in the screen editor, it is round by default and if no cursory glance at the properties is given, you may not realize that they can be made to be rectangular.  But either way, the LED screen element is rather graphical in nature under the hood.  Not textual.  It would not be easy to program it to ALSO be textual (although I'm thinking about it). 

BTW, there is a sticky topic in this forum titled "Mach 4 Feature Request".  I look at each and every post.  I don't respond in there very often, as it would consume my time that could otherwise be used to actually make the things happen.  If I think the idea has merit and I think that the majority of our user base could benefit from it, I'll implement it. 

But seeing as how text based LEDs do not exist at the present time, now it is time to start thinking outside of the box.  If I were to want a text based "Boolean" value (we won't call it an LED now), I'd start with a Static Text control and tie it to a register.  You can create a register in the regfile plugin's configuration.  Registers can contain text values, so basically whatever is put in that register will be what the Static Text control displays on the screen.  You can then tie the register's value to any signal in the signal script (or use the siglib) with a small bit of LUA code.  One could even change the color of what is displayed.  Yeah, it isn't as easy as plopping down a control and instantly having it appeal to your taste or sense of style, but it isn't THAT hard either. 

I'm not a young guy either.  And plenty on this forum know my thoughts on LUA.  Just to summarize them, I can't stand LUA.  We chose LUA not for it's looks, but because of it's speed and flexibility.  But I won't let that stand in my way of getting what I want. 

Here is an example of a screen set that looks NOTHING like our stock screens.  https://www.machsupport.com/forum/index.php?topic=35438.0

Steve

517

Mach4 General Discussion / Re: Mach4 build files infected?

« on: February 04, 2019, 05:09:05 PM »

When the anti-virus software becomes the virus... 

Steve

518

Mach4 General Discussion / Re: Keep track of OB axis

« on: February 01, 2019, 02:05:50 AM »

Brett is right.  Once the carousel is homed, and brought to the first pod (either ABS or INC move), the distance between each pod on the carousel is going to be the same.  You don't have to do anything except move incrementally forward or backward from there.  You can keep track of the current pod in the code. 

Say you have a 20 pod carousel that has 3600 counts per rev.  The pods will have 180 counts between them.  Pod one is 20 counts positive from home pos.

1. Home (motor is now at 0)
2. Got to pod 1 (20 counts positive offset from home).  Set the pod variable.  pod = 1;
3. Calc what it takes to move to to pod 10.  Do shortest path math (say we go positive for grins).
4. Move to pod 10:  9 * 180 = 1620.  jog incrementally 1620 counts.  set pod var to 10.
5. Calc what it takes to move to to pod 8.  Do shortest path math.  We are going to go negative this time.
6. Move to pod 8:  -2 * 180 = -360.  jog incrementally -360 counts.  set pod var to 8.
etc...

And we never have to even look at an encoder.  This is how my Geneva drive works on my carousel tool changer.  No encoder what so ever on it.  Just a pod #1 switch.  It is all math from there.

Steve

519

Mach4 General Discussion / Re: Keep track of OB axis

« on: January 31, 2019, 11:48:36 PM »

Well...  get over it already! 

Just think of the scripts as translation scripts.  Update translates the system value into the human readable value.  Modify translates the human value that is input into the DRO into the system value.

The distinction between update and modify pertains to who/what is changing the value of the DRO.  The update script is run when the system changes the value of the DRO.  The modify script is run when the user clicks on the DRO, changes the value, and then hits enter. 

Maybe that helps?  It is about as clear as mud, I know.  But once you see the light, it will make sense. 

Steve

520

Mach4 General Discussion / Re: Keep track of OB axis

« on: January 31, 2019, 10:57:26 PM »

Ok, and encoder isn't a great example for the modify script because typically you only read an encoder.  But here goes...

The update script is for when the encoder updates the DRO.  So you have the ability to translate the encoder's value to what you want to see.  I think we are all on the same page about this one. 

The modify script is to do the reverse when the user (you) edit the DRO.  Convert the displayed (or typed in) value to encoder counts.  But like I said, unless you have hardware that will let you set the encoder value, it doesn't fit.

But you could use the encoder reading, plus the value of another register as an offset if you wanted.  Then using the modify script to set the offset register so that the DRO reads whatever you put in it. 

update: encoder value + offset register value -> displayed value.
modify: input value -> encoder value + offset register value.  (only the offset register value is modified because the encoder is read only.)

Steve