Messages

751

Galil / Re: Galil controller compatability (what works with the plugin)

« on: May 02, 2017, 12:56:13 AM »

Steve,
Many thanks, I'll wait to hear. Are we talking days, weeks or months for that to happen?

Well...  I was hoping soon but I just got another project that will delay the Galil plugin demo.  Maybe a moth?  It is very hard to say.

Steve

752

Galil / Re: Galil controller compatability (what works with the plugin)

« on: May 02, 2017, 12:54:47 AM »

Eddy,

This question would best be posed to Galil.  There are restrictions on dual loops setups.  For instance, the rotary encoder has to have more counts than the linear scale.  Also, Galil may charge a fee if special firmware is needed.  So talk to their pre-sales support to clarify this stuff.

Steve

753

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

754

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

755

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

756

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

757

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

758

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

759

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

760

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