Messages

91

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

« on: May 03, 2017, 12:39:07 AM »

@Steve
Yes, I treaten it wrong. Now I understood, that mcProfileGetString is used to determine, whether to show the toolchanger dialog.

@DTG
Thanks for the hint about wxFormbuilder. I installed the linux-variant from github - which was straight forward.

@spindoctor
starting the formbuilder shows up, that the builder is targeted to developers, that don't need it =:O
You need the wxWidgets docs. The key of wxWindows are the sizers - when you got that, the rest is straight forward.
But of cause, building gui with formbuilder is not as easy as java gui

anyway - I got it and I'm quite content with my new toolchanger dialog (see picture below)
My changes are - small changes to Mc Master:

Code: [Select]

--M6 message box
UI.MyFrame1 = wx.wxDialog (wx.NULL, wx.wxID_ANY, tostring(m_title), wx.wxDefaultPosition, wx.wxSize( 620, 270 ), wx.wxCAPTION + wx.wxCLOSE_BOX + wx.wxSTAY_ON_TOP + wx.wxSYSTEM_MENU+wx.wxTAB_TRAVERSAL )
UI.MyFrame1:SetSizeHints( wx.wxDefaultSize, wx.wxDefaultSize )
UI.MyFrame1 :SetBackgroundColour( wx.wxSystemSettings.GetColour( wx.wxSYS_COLOUR_3DLIGHT ))
UI.fgSizer1 = wx.wxFlexGridSizer( 2, 1, 0, 0 )
UI.fgSizer1:AddGrowableCol( 0 )
UI.fgSizer1:AddGrowableRow( 0 )
UI.fgSizer1:SetFlexibleDirection( wx.wxBOTH )
UI.fgSizer1:SetNonFlexibleGrowMode( wx.wxFLEX_GROWMODE_ALL )

UI.bSizer1 = wx.wxBoxSizer( wx.wxVERTICAL )

UI.m_staticText1 = wx.wxStaticText( UI.MyFrame1, wx.wxID_ANY, tostring(m_message), wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxALIGN_CENTRE )
UI.m_staticText1:Wrap( -1 )
UI.m_staticText1:SetFont( wx.wxFont( 18, wx.wxFONTFAMILY_DEFAULT, wx.wxFONTSTYLE_NORMAL, wx.wxFONTWEIGHT_NORMAL, False, "" ) )

UI.bSizer1:Add( UI.m_staticText1, 0, wx.wxALIGN_CENTER + wx.wxEXPAND, 5 )


UI.fgSizer1:Add( UI.bSizer1, 1, wx.wxEXPAND, 5 )

UI.bSizer2 = wx.wxBoxSizer( wx.wxVERTICAL )

UI.m_okay = wx.wxButton( UI.MyFrame1, wx.wxID_ANY, "Ok", wx.wxDefaultPosition, wx.wxDefaultSize, 0 )
UI.bSizer2:Add( UI.m_okay, 0, wx.wxALL, 5 )


UI.fgSizer1:Add( UI.bSizer2, 1, wx.wxALIGN_CENTER_HORIZONTAL, 5 )


UI.MyFrame1:SetSizer( UI.fgSizer1 )
UI.MyFrame1:Layout()
UI.MyFrame1:Centre( wx.wxBOTH )

-- Connect Events
UI.m_okay:Connect( wx.wxEVT_LEFT_UP, function(event)
        UI.MyFrame1:Destroy()
        end ) -- end of m_okay:Connect() !

UI.MyFrame1:ShowModal(true)
return UI;
endand some changes to the screen startup code (signal array):

Code: [Select]

--M6 messagebox
[mc.OSIG_TOOL_CHANGE] = function (state)
    local selectedtool = mc.mcToolGetSelected(inst)
local currenttool = mc.mcToolGetCurrent(inst)

if (selectedtool ~= currenttool) then
        if( state == 1) then
            local tmp = mc.mcToolGetDesc(inst, selectedtool)
            mm.ToolChangeMsg('\n Ein Werkzeugwechsel wurde mit M6 angefordert. \nBitte das folgende Werkzeug einlegen:\n\n#' .. selectedtool .. '\t>>' .. tmp .. '<< ' .. '\n\n und mit Druck auf \"Start\" Verarbeitung fortsetzen!', 'Werkzeugwechsel im Gange!')
        end
    end
end

92

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

« on: May 02, 2017, 10:49:01 AM »

Hello,

The last line of the message in the ToolChangeMsg dialog is cut off, so I startet do search for the code.
I found it in mcMasterModule.lua - but I got messed up: wx.wxFont( ... ) is nothing I found in wx-docs. So what is this. Is it mach code, or is it lua?
I wonder, what happens with the dialog. There's plenty space down the last row, so who is responsible for the cutoff?

In ToolChangeMsg I found something like mc.mcProfileGetString(...) - is this related to gettext and po-files?
I changed the message text in the system load script, but if mcProfileGetString reads from mo-files, I revert my changes.

How can I get the sizes in the dialog right?

93

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

« on: May 02, 2017, 07:20:59 AM »

Hi,

i did a simple test to identify strings containing invalid/unsupported charaters:

Code: [Select]

local chk1 = 'Hörst Du die Glöckchen?'
local chk2 = 'einRichtigLangerText'
local x = string.find(chk1, '%W+')
local y = string.find(chk2, '%W+')
local tx = type(x)
local ty = type(y)

if (tx ~= 'nil') then print('chk1 contains invalid characters') end
if (ty ~= 'nil') then print('chk2 contains invalid characters') endThis could be used with filenames and user input from textfields.

HTH Reinhard

94

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

« on: May 02, 2017, 03:21:24 AM »

Thanks for that info!
I'll keep on digging

95

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

« on: May 02, 2017, 02:47:44 AM »

Hi Steve,

thank you for the additional calls. Works fine so far

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.

I totally agree on that!

But I'm not a machinist, who learned programming, but a software developer who learned machinig. For so, we might have different points of view.
When I startet with software development, my tutor used to say: take care of your gui - one mouseclick wasted means hundreds of customers lost.
Related to the filename-issues he used to say: whenever I see something like that happen, I cut you off a finger.

So I had a hard start and became what I am

by the way: do you use a lua-variant, that supports gettext?
If so, we could extract the user related texts to po-files. What you think about that?

... and what's in the screen-set file? Are the bitmaps part of the set-files? And the macros? Are they in the set-file or are they externally?
Or let me change the question: when I want to share my screen, what files do I have to include?

96

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

« on: May 02, 2017, 01:38:51 AM »

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


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.

97

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

« on: May 02, 2017, 01:02:57 AM »

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

98

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

« on: May 02, 2017, 12:14:21 AM »

Hi Steve,

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?

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?

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

You can add any fields you want to the tool table.

Great! Thank you!

99

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

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

100

Mach4 General Discussion / Re: help text

« on: May 01, 2017, 11:16:22 PM »

Thank you for that hint.

The point is, there's lot of writings in the manual, I don't understand (yet?). Although I had read the chapter about modules, I don't know, how they come into play ...
Anyway - thanks to your hint, I can start translating the help-texts