Hello Guest it is March 29, 2024, 01:13:28 AM

Author Topic: more lua (?) questions  (Read 7929 times)

0 Members and 1 Guest are viewing this topic.

more lua (?) questions
« on: May 01, 2017, 03:27:33 AM »
Hello,

with my first steps in lua I created a faked table control for the tool table. Awful how fast lua is - even in a VM!
With the '+' and '-' buttons I can scroll through the tools table.
Now I'd like to add the slider as scrollbar. The '+' and '-' buttons already use the slider value to read the tools, but there's no link to moving the slider. The slider has no 'on-update' script, so how can I create something similar?

And next question:
Tabbing through the entryfields works fine, but after the last field, the tab disappears in deep space ...
Is it possible to create a tab-group, so that the tab jumps to the first entryfield after leaving the last one?

Offline DazTheGas

*
  •  778 778
  • DazTheGas
    • View Profile
Re: more lua (?) questions
« Reply #1 on: May 01, 2017, 04:48:44 PM »
You could use the PLC and compare the value of the slider to the current tool number and if the current tool is not equal to the slider value then change tool number to the value.

DazTheGas
New For 2022 - Instagram: dazthegas
Re: more lua (?) questions
« Reply #2 on: May 01, 2017, 11:35:36 PM »
Thank you for your support!

Uh - I have to confess, I don't understand the mach-way yet.
Seems like I have to think more than an embedded programmer, than a pc-programmer.
I'll try it out.

It looks like I don't understand the meaning of "single block" function/signal. I thought, the meaning was: execute a single gcode and then stop, but that does not work at all. I have a togglebutton attached to the output-signal "single block" and running a gcode script it makes no difference, whether the button is pressed or not.
From the experience with cooling and the like, I guess, the togglebutton does its job right and the signal is switched. May be the other part of the signal handler is missing?

The codepage issue is not limited to the interaction of external editor and mach. It is related to entryfields and static text too. See the pictures below.
Additionally it looks as if the field to hold the description text is too small. Is it possible to increase the size?
And then I would like to add another field to the tooltable:
usually mill cutters have at least 2 length informations - the blade length and the shaft length.
For machining only the shaft length is relevant, but on toolchange, the blade length could be relevant to the (human) tool changer :)
Having enuf size at the description field I could enter that length there, but I'd prefer an extra field for this information.

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: more lua (?) questions
« Reply #3 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
Re: more lua (?) questions
« Reply #4 on: May 02, 2017, 12:14:21 AM »
Hi Steve,

Quote
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.  
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?

Quote
Look at a stock screen set and see how the Single Block button activates single block.
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?

Quote
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).
Hm, that's not good :(
I guess, to change code page of macro editor is quite easier, than change the screen entry field.
Are the string codepage change calls available in lua?
I guess every non-english wants to enter localized data in textfields.

//edith:
I had a quick look at wxwindows and they write, that unicode is used by default. So localized data handling should be possible ;)
Afaik the windows codepage supports german special characters too ...

Quote
You can add any fields you want to the tool table.
Great! Thank you!
« Last Edit: May 02, 2017, 12:30:18 AM by django013 »

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: more lua (?) questions
« Reply #5 on: May 02, 2017, 12:45:31 AM »
Quote
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.

Quote
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

Re: more lua (?) questions
« Reply #6 on: May 02, 2017, 01:02:57 AM »
Quote
The codepage is set to an ASCII codepage in the GUI because G code does not allow anything other than ASCII.
Sorry, but that's a bad choice.
Every user is accustomed to his locale and no non-programmer knows about the problems of ascii-string versus wide-character-strings and codepage conversion, so rising the interpreter problems to the user is not a good thing.
The better choice would be, extend the interpreter to patch any non-standard characters to meet the standard. So i.e. if the interpreter finds a comma as decimal separator, it would be easy to overwrite that comma with a dot. No user has ever to be bothered with that kind of problems.
Additionally many cams write localized text in comments. A "good" interpreter takes that comment and shows it to the user - so the user reads its own language.
I think, one has to distinguish between command-level (all NC-words), which of cause is pure ASCII only, and comments and rest of application. Same is true for filesystem-handling:
No user understands, that the application vomits a "file not found" for files, he selected from file selection dialog. The user knows, that the file is there :)
I think, a today application should accept any locale from user interface and handle conversions and validations so that functionality is not affected by any wrong user input.

cheers Reinhard

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: more lua (?) questions
« Reply #7 on: May 02, 2017, 01:29:09 AM »
I worked for a German company for 15 years and had to learn the meanings of the German words in the software we used.  So I'm probably not going to be sympathetic at all.  :)  It didn't kill me.  I lived!  I have to admit that I did complain about it though.  

I have talked with several German users about this in the early days of Mach 4's development and they all agreed that it is best to stick with the standard.  It is a machine tool.  It should operate the same no matter what part of the world it is in.  I should be able to walk up to a CNC machine in Germany and execute G21 G01 X5.000 and expect to move 5mm and not 5000mm.  The Japanese created Fanuc and all of them use a period for a decimal point.

As long as your comments are made of single byte cahracters, they will be ok.  They may not display correctly do to the codepage, but it will not affect the interpreter.  

Steve
Re: more lua (?) questions
« Reply #8 on: May 02, 2017, 01:38:51 AM »
Quote
I have talked with several German users about this in the early days of Mach 4's development and they all agreed that it is best to stick with the standard.  It is a machine tool.  It should operate the same no matter what part of the world it is in.
Hm, may be, you talked to the wrong guys ;)

mach is a PC-program and any user will recognize it as such. Nowadays pc-applications are localized and can handle any codepage, the user uses in his operating system.
A quite different view is the interface between mach and cnc-machine. That interface is of cause pure ASCII and should never change.

... but hey: its your decision. I only can write my opinion and that does not have to match yours :D


due to user-fields in tool table ...
How can I access those fields from lua?
In API-docs I see no function to access user fields and the type in mcToolGetData does not have entries for user-fields.

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: more lua (?) questions
« Reply #9 on: May 02, 2017, 02:05:59 AM »
I disagree.  I spent 20 years in the automotive manufacturing business.  When we deployed machines with PCs, be them test fixtures or some type of machine control, they were no longer treated as PCs.  If you used them for any other purpose than what they were put there to do, you were fired.  No questions asked.  Just because you can, doesn't mean you should. 

When you install Mach on a PC, you have turned that PC into a machine controller.  And it should be treated as such.  It is no longer a PC to surf the web, do word processing, play games, email, or CAD/CAM design.  We can't control what the users do in the end with their new machine controllers.  But we would rather then NOT do any of that stuff. 

I keep forgetting to add those tool table functions to the API documents.  :(

local rc = mc.mcToolSetDataExStr(number inst, number toolnum, string fieldName, string value)
local value, rc = mc.mcToolGetDataExStr(number inst, number toolnum, string fieldName)
local rc = mc.mcToolSetDataExDbl(number inst, number toolnum, string fieldName, number value)
local value, rc = mc.mcToolGetDataExDbl(number inst, number toolnum, string fieldName)
local rc = mc.mcToolSetDataExInt(number inst, number toolnum, string fieldName, number value)
local value, rc = mc.mcToolGetDataExInt(number inst, number toolnum, string fieldName)

Steve