Messages

751

Mach4 General Discussion / Re: more lua (?) questions

« on: May 02, 2017, 12:45:31 AM »

Hm, ok - so an output can switch a relais, but if I want to connect a hardware toggle-button to the screen toggle-button, than I have to use an input event?

Yes.

Yes, I realized, that some buttons are bound to external signals and have a function call attached.
If I want to use the signal-line as connection between external and screen switch, shouldn't I then perform the action in the signal script?

Yes.  With and input signal.  There are lots of examples of this on this forum.  Also, one can use the PMC interface.  Search for examples of this as well.

You will have to read up on wxWidgets to see what all you can do with the codepage stuff.  Yes, you will be using LUA, but wxWidgets is what is bound to LUA.  We have other German users that have accomplished this stuff.  Focus Paul is one of them.  The codepage is set to an ASCII codepage in the GUI because G code does not allow anything other than ASCII.  Other NLS settings such as the decimal character are purposely set as well.  Meaning using a comma for a decimal character is not allowed in G code RS274NGC standard.  So most things in the GUI are purposely set this way so that things like that don't accidentally end up in the interpreter.  Excluding any custom LUA screen elements that you create, of course, so be careful how you integrate so that nothing non-ASCII gets into the interpreter.  Filenames, profile names, etc..  are all a source of potential problems. 

Steve

752

Mach4 General Discussion / Re: more lua (?) questions

« on: May 02, 2017, 12:02:38 AM »

That output is meant to drive a LED or panel indicator.  It does not activate anything.  All outputs are this way.  Only inputs can activate anything. 

Look at a stock screen set and see how the Single Block button activates single block. 

As far as the codepage goes, G code is only ASCII.  The API only supports ASCII.  So assume that anything other than ASCII may not work correctly.  The only thing that will support NLS is the stock Windows controls (anything in the .po files). 

You can add any fields you want to the tool table.  View->Tool Table.  Then Edit->Table Fields...  Then the User Fields tab.   

Steve

753

Mach4 General Discussion / Re: Probing Question PoundVar 5062 amd 5072

« on: May 01, 2017, 03:22:01 PM »

The term absolute is used because the positions in those variables are always absolute.  G53 is always absolute.  However, work offset coordinates (G54-G59, etc..) can be called out as incremental or absolute depending on G90/G91.  What they are trying to convey is that no matter if you are probing in G91 mode, those variables will always be the absolute positions. 

For example.
G90 G00 X1
G91 G31 X1 F10

Say the probe struck at X==1.5.  The value in 5061 will be 1.5 and not 0.5. 

Steve

754

Mach4 General Discussion / Re: Probing Question PoundVar 5062 amd 5072

« on: April 30, 2017, 02:24:17 PM »

I don't see that in the documentation.  What doc file are you referring to?  The one I'm speaking of is "Mill GCode Programming.pdf", page 19.  There is a table showing the system variables that are updated.  5061-5066 are for the current fixture coordinates.  5071-5076 are for G53 coordinates.  This is correct.

You may be looking at some old docs.  Especially if your browser cached an old file from the website.

We ship the manuals in the distribution (<Installation Dir>/Docs) .  Those are the ones you want to look to anyway, as they will match the build that you are using.  Looking at current docs on an older build might not be prudent. 

Steve

755

Mach4 General Discussion / Re: Mach4 M6 Macro problem

« on: April 30, 2017, 01:57:16 PM »

Sure, you can put that API call in a M code macro script.  Then just call that M code in your G code.

If I don't have a fixture setup, I typically start my machine and do a tool change via MDI to my edge finder or probe anyway, no matter what tool is the current tool.

Steve

756

Mach4 General Discussion / Re: Problem in front or behind the screen?

« on: April 30, 2017, 02:15:08 AM »

I tried using Eagle, but the board size was too limited.  And the next version up was a bit out of my price range.  So I started using DipTrace and liked it so much that I bought the full version.  I hope they don't get bought out!  I used to use Altium Designer (and DXP 2004 before that) when I worked at a company that had it and got spoiled.  Before that, I used a program called CircuitMaker 2000, which was part of the Protel lineage.  Altium has resurrected the CircuitMaker product as a free "maker" EDA software.  I have not tried it though.  If the software is free, I tend to worry.  Because YOU then become the product.  

Sad to hear AutoDesk ruined Eagle.

Steve

757

Mach4 General Discussion / Re: Mach4 M6 Macro problem

« on: April 30, 2017, 01:02:27 AM »

Only when Mach 4 is started.  That is when the screen load script is run.  It will also run after editing the screen, as that is like starting Mach loading the screen.  If you wanted it to happen for every file load, you could put that string in the "Load File" button's up action script.  If you wanted to make it do that every time you start a file, put that in the Cycle Start buttons' up action script (checking for the G code line to be 1, etc..).

Steve

758

Mach4 General Discussion / Re: Problem in front or behind the screen?

« on: April 30, 2017, 12:50:52 AM »

You edit the screen scripts in the screen editor.  They are on the root tree item.  Click on the root tree item and then look to the properties/event window.  Click on the little lightening bolt. 

The API documentation has both a C/C++ syntax and a LUA syntax.  The LauCalls.txt file will be gone in the next release.  It is old and not relevant.  In fact, I didn't even know it was there.  Someone else put it in the documentation repository and it gets automatically included in the builds.  I was just recently made aware of it's existence and I looked at it and found that the return variables are called out in the wrong order!  So that is not the document to use at all.

We go in the direction which keeps us in business.  We don't choose to have to resort to protection methods.  If everyone were honorable then we would not have the issue at all.  So please do not blame us.  We offer a great product for not a lot of money and do what ever it takes to keep it affordable.  And part of keeping it affordable is not having it pirated.

Sure, send the po-file fixes to support@machsupport.com and we will merge them in!

BTW, I don't see a problem with little 'Oh" in buttons text and element names.  Perhaps the keyboard plugin is capturing the keys?  you can disable the keyboard capturing with the small task bar icon.
 
Steve

759

Mach4 General Discussion / Re: Mach4 M6 Macro problem

« on: April 29, 2017, 08:34:06 PM »

I want my tool to be the last one I used at startup.  So your version of "correct" doesn't match mine.    Luckily, we wrote Mach 4 in a manner so that it will work any way you want it to.

Read the API manual and see what all is there.  You can make it work the way you want with a single line of code in your Screen Load script. 

Code: [Select]

mc.mcToolSetCurrent(inst, 0) -- if tool zero is the desired startup tool. 

Steve

760

Mach4 General Discussion / Re: Problem in front or behind the screen?

« on: April 29, 2017, 08:14:09 PM »

Mach 4 is not Mach 3.  There really isn't anything that directly correlates between the two as far as screen design goes.  So the first mistake is to think what/how/why things work in Mach 3 vs. Mach 4.  Just force yourself to not do this!  You life will get easier.  

Most of what you want can be done with custom scripting.  For example, you can get the cycle time with the API and format it any way you want it with LUA.

Code: [Select]

if (machEnabled == 1) then
    local cycletime = mc.mcCntlGetRunTime(inst)
    if (machState ~= mc.MC_STATE_IDLE and mc.MC_STATE_JOG and mc.MC_STATE_HOME) then
        scr.SetProperty("CycleTime", "Label", SecondsToClock(cycletime))
    end
end
That code is in the PLC script on a screen I have.  The LUA function SecondsToClock() does the format.  This function is defined in the screen load script and is thus available to all screen scripts.

Code: [Select]

-- In screen load script.
function SecondsToClock(Seconds)
if Seconds == 0 then
return "00:00:00.00";
else
local Hours = string.format("%02.f", math.floor(Seconds/3600));
local Mins = string.format("%02.f", math.floor(Seconds/60 - (Hours*60)));
local Secs = string.format("%04.2f",(Seconds - Hours*3600 - Mins*60));
return Hours..":"..Mins..":"..Secs
end
end

As you can see, you can format the time in any manner you wish!  You can also solve your "feedrate overridden" this way as well.  

As to the flicker, all that you have to do is slow the rate at which the cycle time is updated.  In the example above, is is called every PLC script interval.  This interval is defined in the screen set.  Say it is fifty milliseconds.  Just put in a counter that is checked before calling the API to get the cycle time.  That way, you can slow the update down to every x * 50 milliseconds.  

I would suggest reading the API documentation and getting familiar with what all can be used.  You will soon be dreaming up all kinds of ways to do things!  LUA is the way to call these API functions in a screen, so reading up on it will help too.  

There is no way to inhibit the scaling.  We are using a cross platform framework with Mach 4 instead of MFC that was used in Mach 3.  The cross platform capabilities are nice but it comes at a cost sometimes.  i would suggest designing the screen at or near the resolution you wish instead.  

We will never make that demo timeout message evident at the time the demo times out.  The reason is that lets the hackers know what to look for to try and disable the timeout!