Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: simpson36 on March 09, 2015, 08:25:18 AM
-
Now that Mach4 has image toggle buttons, I think its time to dedicate a thread to making the MACH4 screens attractive . and of course intuitive and 'user friendly' at the same time.
Also a place to pester the developers for cool stuff and provide inspiration and incentive by demonstrating what can be done with the tools they provide.
The attached video is the part of the MACH screen where I put the InTurn™ 4th axis controls. For those who have not played with MACH4 screen mods, jump in! The stuff you see in the little attachment took only a couple of hours to do, including the scripts behind the buttons.
Just to show something a little different, I added a lighted rocker switch in place of one of the boring toggles. Pretty slick (if I do say so myself), however, I am thrarted in attempts to do some really cool stuff because I cannot find a way to get rid of the border around each button.
So two questions to start off.
1) can the borders be removed from buttons
2) what is Z order for? Seems to have no effect on anything
-
While the Mach4 screen designer is very powerful, in some ways it's more limited than Mach3. I requested dual state LED's like mach3 uses about a year ago. This would let you do a lot of cool things.
I also requested more font options, but was told that they couldn't do it, because they someday will be making Mach4 cross platform, and couldn't support additional fonts. :-(
Z Order brings items to the front, or sends them to the back, but it's quirky it seems.
-
Can you explain 'dual state'?
There is provision for two scripts, so that is obviously not what you are looking for. The smoothness of curved lines (or circles) is not impressive, but that looks to me like an antialiasing issue.
Image toggles was just added literally a few days ago. Do you believe that he screen tools will not be improved from this point? To my eye, unlike MACH3, Mach4 seems to be getting a lot of attention and is coming along well, so I am optimistic.
I was speaking to one of the engineers at MachMotion today and they are very high on Mach4. That is one of many indicators that Mach4 will be a stable piece of software. Fingers still crossed, but so far so good, I would say.
In any case, I am having fun with the new screen goodies. FormBuilder gets pretty boring pretty quick.
-
By dual state, I mean Image LED's that use one image for on, and one image for off. This allowed me to create checkboxes and radio buttons in Mach3.
Do you believe that he screen tools will not be improved from this point?
No. I just don't think that they're a priority right now.
Like you, I haven't really looked at Mach4 for the last 6 months. I'll start looking at it again soon.
I do see that it's definitely more stable than it was back then.
-
By dual state, I mean Image LED's that use one image for on, and one image for off. This allowed me to create checkboxes and radio buttons in Mach3.
Workarounds of course are never the first choice, but I'm thinking that checkboxes and radio buttons could be made from the image toggle buttons. They are a lot more versatile than the LEDs.
There are some number of scr.********* functions that can get and set properties of the screen controls. I do not know if these are documented officially anywhere, but I just fell over them in some scripts and used them in my controller screen. Pretty slick stuff.
Thus far I have only used toggle buttons and a couple of sliders, so I'm just scratching the surface at this point. I am inclined to want to avoid tools like FormBUilder and the Widget thing and just build my own library of doo-dads or maybe make the screens up in C# and just talk to them with Lua. Certainly there ar eplanty of libraries for dx and OpenGl. Not really sure yet. Just tinkering at this point. :-\
I am just starting to tinker with a touch screen for my next gen of controllers and there is a graphics primitives library for that so if I go that rout it *might* be fairly simple to port over to any platform by swapping in equivalent functions. That would be the extreme optimistic viewpoint . . . I should lie probably just down until that passes. :D
-
Steve,
NICE!!! Love your toggle Pic/button It looks like a Rolls Royce emblem on a VW hood...... hehehehee
again, nice work!!!
What Graphics designer are you using for your pic's?
thanks for showing your work.
Scott
-
Here is an example of scr.calls
http://www.machsupport.com/forum/index.php/topic,29452.msg205711.html#msg205711
scott
-
The scr.********* functions do not work in all cases. At least not for me.
It will be a matter of experimentation to find which are useful . . . unless somebody has already made a list.
For example, I cannot get the color to change on an LED. I have tried passing a string i.e. 'Red' 'Blue' etc. without success and also tried passing RGB values i.e. '(200,100,10)' also with no success.
I'll try hex values before giving up on that particular effort. LED's don't seem all that useful anyway.
-
it is Hex values
-
it is Hex values
Tried this. NO success so far.
How do you put a hex value in a string field?
scr.SetProperty('ledTEST', 'Color', '200');
scr.SetProperty('ledTEST', 'Color', "Light"); Light is a var with an integer numeric value
scr.SetProperty('ledTEST', 'Color', '0x60');
-
I'm not at a computer right now, by try (tostring('VALUE') on the value you want to pass.
-
I'm not at a computer right now, by try (tostring('VALUE') on the value you want to pass.
Damn phone, damn Tapatalk... (tostring('VALUE')) is what I meant.
-
I'm not at a computer right now, by try (tostring('VALUE') on the value you want to pass.
Damn phone, damn Tapatalk... (tostring('VALUE')) is what I meant.
No problem, got that. I'll give it a try.
-
No joy.
Just to clarify, the 'Color' property is not working. Some of the others do work so I suspect this is just a dead ant.
ON/OFF and position work. It's sort of fun to make the thing jump all over the screen, but not particularly useful :)
On the other hand, the 'hidden' property has no effect so jumping the LED into oblivion and back may be a workaround for making it 'disappear'.
In another thread, it was stated that some or the scr.********* command have been replaced by mc.*********, but so far I cannot find any mc.*********xx functions that even have the word 'prop' on them. I'll keep on tinkering . . .
-
I poked at it a little here.
color = scr.GetProperty('led73','Color')
wx.wxMessageBox (color)
It reported back some numbers as I changed the Led. Red is 0, Purple is 32, Blue is 4. If these follow some convention, tell me about it. :)
-
It shouldn't be that hard to get some documentation on this stuff.
Just a simple list would go a long way.
-
I poked at it a little here.
color = scr.GetProperty('led73','Color')
wx.wxMessageBox (color)
It reported back some numbers as I changed the Led. Red is 0, Purple is 32, Blue is 4. If these follow some convention, tell me about it. :)
You are wise, Obi-Wan! :-*
That was the ticket. Reading out the codes was brilliant! Use those values and Bada-Bingg! The colors change!
One big cookie for the man with the flag (the 'made in USA flag')
-
OK, time for some more fun. Checkboxes . . I'm on it!
Somebody just say how they are supposed to work . . and look.
Do you just want a Boolean? . . can do . . but it just seems so . . minimalist . . . ;)
-
Wouldn't cascading checkboxes be more fun?
Check . .
Are you sure ? . . . .
But are you REALLY sure? . . . .
Is that Really REALLY SURE? . . .
Do you have a note from your MOTHER? . . . .
::)
OK, just say how they should work and I'll see if I can make them up . . . :(
-
Idea . . .
How about instead of boring check box, a push button? Same control, but lookin' good?
Mo' better . . .
How about a toggle switch?
Actual toggle switch? Oh yeah! Looks real? Oh yeah - a photo of a real switch . . Moves? . . oh yeah . . Handle lights up? . . Oh YEAH. ;D
I already have the transparency part (alpha channel) working . . . just need to get rid of the button outline as it looks a bit stupid just popping up out of nowhere. :-\
-
I poked at it a little here.
color = scr.GetProperty('led73','Color')
wx.wxMessageBox (color)
It reported back some numbers a string as I changed the Led. Red is 0, Purple is 32, Blue is 4. If these follow some convention, tell me about it. :)
A little further info:
Oops, it actually reported back color as a string. That can make a difference, depending on what you want to do with it.
Things such as 'Value' (whether an led is on or off) is actually a number of 0 or 1.
There is always the "type" function in Lua to check.
color = scr.GetProperty('led73','Color')
colortype = type(color)
wx.wxMessageBox (colortype)
-Nick
-
I have not tried to attach code before, so hopefully this will work. [edit] OK it worked. The attached file is the same code that is in the scroll box. I don't know which is preferable, so I did both.
With kudos to Bodini for the ides of reading out the values, I took it a bit further and made what I call a 'code fragment' for my library. This is probably all that I will ever do with LEDs because I find the other stuff more interesting to mess with.
NOTE: this code only covers the colors for LED (plus on/off for practical reasons). It will seem disjointed because I am showing multiples ways of doing things instead of making nice tidy lists. There are many other parameters that can be manipulated in the same way by simply changing the parameter name and using appropriate values. Bodini has posted a method to determine the actual values . . which may or may not match what is in the input box for the particular screen control in the Mach4 screen editor.
This is my first posting of actual code, so I'll provide a 'blurb' on how to look at it and use it for those unfamiliar with such things.
This code is shared here for anyone to use. Note that it is not a finished code intended to be 'run'. It probably would but everything would happen so fast it would not be useful.
For those who are not familiar with the Lua editor, you can step thru code one line at a time using the F11 key. It doesn't seem completely stable to me as it often will just quit for no apparent reason, but just use the dropdown menu and pick 'start debugging and then you can step thru using the F11 key. A small green triangle marks the line the interpreter is running at any given moment and when the code 'calls' a function it will jump to where that function is which may be far away from the line that calls it, but it will return to where it started after the function has finished executing.
If you want to stop 'debugging' go back to the drop down and click the obvious choice. Note that you must stop the debugging before you can edit (cut and paste).
-- Lua Code Fragment
-- © 2015 www.theCUBEstudio.com
-- color codes and usage for Mach4 screen LED
--color = scr.GetProperty('led10','Color')
--wx.wxMessageBox (color)
-- NOTE: color numbers are exponents
-- NOTE: color names red/green for LEDs is a state change that follows the On/Off state
-- NOTE: Parameter named 'Value' in an LED is the On/Off switch -- usage example below
-- Observation: The exponent value (color number) for Red/green and Yellow colors have equal delta
---------------- therefor could be used to create a 'stoplight' effect by calculating the color value
---------------- the exponent values are 0,1,and 2, so by using a default, the control value can be booleani
-- USAGE: color numbers can be imput expressly in the function -or-
--------- intuitive variables can be pre-defined - see example below -or-
--------- color number can be calculated and then used by either method
-- SYNTAX: scr.SetProperty('NameOfScreenControl','NameOfParameter','NewStringValue');
-- ****************** creating and loading Variables for each Color **********
--******************* (these are the actual correct values ******************
red = "0";
amber = "2";
blue = "4";
green = "8";
nocolor = tostring(2^4); -- string value saved is "16"
purple = tostring(2^6); -- string value saved is "32"
white = 64; -- example using numeric value - musyt be converted to string in the screen call
yellow = 128;
-- odd duck:
green_red = "9";
-- ************************ Variables for ON and OFF
ledON = "1"; --example of storing the variable as a string
ledOFF = 0; --can also be stored as a number
-- see examples below for the proper syntax for each method
-- *************************
-- example usage by string variable
scr.SetProperty('led10', 'Color', blue);
scr.SetProperty('led10', 'Value', '1'); -- note that a string value can be created 'on the fly'
scr.SetProperty('led10', 'Value', '0');
-- if numeric formula is pre-coverter to a string, just use the variable name
scr.SetProperty('led10', 'Color', purple);
scr.SetProperty('led10', 'Value', ledON);
scr.SetProperty('led10', 'Value', tostring(ledOFF));
-- if the Color variable contains a number, it must be converted to a string in the function call
scr.SetProperty('led10', 'Color', tostring(white));
scr.SetProperty('led10', 'Value', '1');
scr.SetProperty('led10', 'Value', '0');
--************************* Example using exponents
local i = 0;
for i = 0,7,1 do
--- color string value can be calculated and coverted on the fly
scr.SetProperty('led10', 'Color', tostring(2^i));
scr.SetProperty('led10', 'Value', '1');
scr.SetProperty('led10', 'Value', '0');
end
--************************* stoplight example ********************
StopLightColor = "";
UserInput = 0;
-- ********************************* set up a function to change the light
function ChangeStopLight()
-- wx.wxMessageBox (tostring(UserInput));
if (UserInput > 1) then
StopLightColor = tostring(128);
elseif (UserInput == 1) then
StopLightColor = tostring(8);
else
StopLightColor = tostring(0);
end
scr.SetProperty('led10', 'Color', StopLightColor);
scr.SetProperty('led10', 'Value', '1');
end
-- ****************************** simulate user input
for i = 0,2,1 do
-- wx.wxMessageBox (tostring(i));
scr.SetProperty('led10', 'Value','0');
UserInput = i;
ChangeStopLight()
end
-
Thanks for sharing that.
-
It reported back some numbers a string as I changed the Led. Red is 0, Purple is 32, Blue is 4. If these follow some convention, tell me about it. :)
As you will see from my posting, the color 'numbers' are actually exponents, which seems a little weird at first blush, but can actually be very useful.
A caveat with Lua is that you never really know the data type because Lua changes it on the fly. I'm not very familiar with Lua yet, but it seems the only time it is really unhappy with the wrong data type being in a var is when passing the value to a function, otherwise you really need to track it back, or test it as you pointed out, to know what the heck is in there.
Lua is sort of like "programming for people who don't like to follow rules".
I typically identify variables with a 'tail' thus IntuitivelyNamedVariable_FL or IntuitivelyNamedVariable_INT if the distinction is important and of course if the variables have the same name.
It is noteworthy that the version of Lua current implemented in MACH4 is ALL floats. I can think of zero reason to do something like that and it is a huge PIA, but apparently they have come to the same conclusion because the latest version 'introduces' the integer data type.
On the other side of that coin is that Lua does have some unconventional math functions that are rather bizarre . . . probably as a result of having only floats to work on . . but also very useful in some cases and they left them in!
So forwarned is forearmed as they say. This is a MAJOR change and will blow large holes in most calculations (well, mine anyway), so it would be a good idea to code in such a way as to minimize the impact of the introduction of the integer data type.
-
Thanks for sharing that.
No problemo. Kudos to Bodini. He provided the key. I just opened the door. . . . ;)
Now if someone knows how to turn off the box around the buttons, I can do some very cool stuff.
-
Here are some ideas for cool radio buttons and checkboxes.
Should be apparent why the button borders have to go.
No new stuff for a while. Slammed schedule as always.
-
With kudos to Bodini for the ides of reading out the values,
Phfft. Scott (poppabear) and Craig (ya-nvr-no) and bfr549 (Terry) have provided a lot more info on this stuff than I ever could. I was just able to hone in on what you needed to hear this time. ;-)
-Nick
-
For added help in screens you may want to look at WX.Smith. It is an addon to lua for screens. AND they actually have a manual and speak normal humon.
(;-)TP
-
With kudos to Bodini for the ides of reading out the values,
I was just able to hone in on what you needed to hear this time. ;-)
My point exactly. ;)
-
For added help in screens you may want to look at WX.Smith. It is an addon to lua for screens. AND they actually have a manual and speak normal humon.
(;-)TP
This may seem like a silly question, but are the MACH4 screens actually Lua. ???
I was assuming that the MACH screen was written in some flavor of 'C" and that Lua was just hooked in as the scripting language.
There was no time to dig into that FormBuilder thing, but it looked like it was just a screen tool and separate from MACH.
Put another way, if something were written using WX.Smith, is there a mechanism by which to connect it or integrate it to the MACH4 screen?
Eventually I might understand how all the players fit together, buy I'm still feeling my way along the wall for the light switch at this point, so if you can shed some light on how these things fit together, it would be mucho helpful.
-
I think you would have to ask smurph that one
-
I think you would have to ask smurph that one
He is aware of the effort to spruce up the Mach4 screens. I asked for image toggle buttons and got them within something like a week!
I'm not inclined to bother him unless I an stuck . . . dead in the water . . and that is not the case.
All I really want at this point is to get the boxes out from around the toggle buttons, but that does not hold up creating new buttons, check boxes, radio buttons or other stuff. They will just not look their best until the border goes away, so I am not motivated to work on them at this point, which is an ill wind because I am Uber busy and don't have time for it anyway, so removing the temptation is a good thing . . . :)
-
I requested dual state LED's like mach3 uses about a year ago. This would let you do a lot of cool things.
Is the red/green dual state led going to work for you?
I also requested more font options, but was told that they couldn't do it, because they someday will be making Mach4 cross platform, and couldn't support additional fonts. :-(
I'm not buying the cross platform reason, unless there is some Jurassic platform that I am unaware of that has a single font, but it might be worth playing around with renaming fonts as a 'trick' as can be done with the g-code editor.
Z Order brings items to the front, or sends them to the back, but it's quirky it seems.
This has not worked for me yet. Is there an example you can cite where this works?
-
I should have been more clear. What I was referring to was using images for LED's. But as I sit here looking at Mach4, it looks like I could use "images" as LEDs. I can swap images on the fly, and have them linked to LED's, correct? So that answers that question.
I found the post about the fonts here:
http://www.machsupport.com/forum/index.php/topic,25952.msg182957.html#msg182957
It's an old post, but I still see only 5 fonts, so I guess that's all we get.
I can work around the 5 fonts with images, except for in DRO's.
Haven't played with screens in close to a year. Now that I think about it, I recall the Z order being very buggy. I may have reported it, but don't really remember.
-
;D
Just a thought, (;-) TP
-
Just an update . THE WXSmith is used with Code::BLocks and Wx Widgets and WxFormBuilder BUT it does NOT output in LUA. It is only usefull IF you use the XRC method of screen building. THAT PART will work with LUA.
The Code:Block has a GREAT screen builder that is drop and drag and WYSIWYG . BUT it does not output code in LUA (yet). It uses all the resources of all the screen building moduals to make it easy to create a GUI screen.
Hopefully we can get them to output in LUA . It would not seem to be that hard BUT? (;-)
(;-) TP
-
I should have been more clear. What I was referring to was using images for LED's. But as I sit here looking at Mach4, it looks like I could use "images" as LEDs. I can swap images on the fly, and have them linked to LED's, correct? So that answers that question.
If I am decoding this correctly, the answer would be Definitely yes . . sort of :P
It depends on which direction you want the link to 'go'. There are not scripts available IN the LED type, however, you can manipulate an LED with a script from another type.
ex; you can use the scripts behind an image toggle (which satisfies both your dual state and image requisites) to turn on an LED (or change color, make it dance around the screen, whatever)
In my view, while doable, the above would be redundant since you can create a 'smart' checkbox or radio button out of the image toggle. Examples of each are shown in the last video I posted here. I may have neglected to point out that the button and checkbox are image toggles.
I don't see much use for the LED's . . and they are ugly anyway . . unless they fix the anti-aliasing. It does not make sense to have a border around an image toggle, but that is probably fixable.
-
they are getting there there is improvement needed but all the basic features are there, we have free rain to do what ever we wont with M4 if you wont just post anything you wont to supply of what you have done if its a good thing to have they will added it.
there are others doing cool stuff with M4 what are giving over some stuff but showing what they can do or you can help as well, or they are sending it to Brian or they other development team the round team not squire team ( they know what I mean ) it all helps to get everyone what they wont in the end I only hope that M4 can kill linuxcnc what`s ok to use now but is harder to use than lua.
also just a thing that can be done macro b can be used to do some of what is missing at this time some not all yet
-
Just an update . THE WXSmith is used with Code::BLocks and Wx Widgets and WxFormBuilder BUT it does NOT output in LUA. It is only usefull IF you use the XRC method of screen building. THAT PART will work with LUA.
The Code:Block has a GREAT screen builder that is drop and drag and WYSIWYG . BUT it does not output code in LUA (yet). It uses all the resources of all the screen building moduals to make it easy to create a GUI screen.
Hopefully we can get them to output in LUA . It would not seem to be that hard BUT? (;-)
(;-) TP
Terry,
All of these GUI tools are great for making stand alone screens, but can they tie into the MACH4 screens?
Dredging data from MACH4 and displaying it on a nice screen in convenient for maintenance and setup, but those are utility functions.
My interest in in operational functionality and unless I am missing something (which is quite possible since I am just starting to dig into this stuff), that has to be done on the MACH4 screens.
Ultimately, what I would like to have is a mechanism by which a graphic could be made and integrated or overlaid on the MACH screen and hooked into the data. Maybe that is doable with one of the tools you have mentioned. I have not had time to look at them yet, although I have some ideas for work-arounds if there are not specific tools available.
In any case, I don't think I am anywhere near exhausting the tools provided by MACH. The graphics handler supports alpha channels, so that opens a barn door of possibilities. I just don't have much time available to play with the stuff at this point. I came back to the forum to get my controller ported over to MACH4 and that's done. There are lots of other torches at the castle gate.
-
What I meant was have the images change state based on the state of the LED's. I don't need to manipulate the LED's, just read their state and swap the images accordingly. So the image would be (or mimic) the LED.
I don't have Mach4 in fornt of me, but is there a border style option of "none"?
-
What I meant was have the images change state based on the state of the LED's. I don't need to manipulate the LED's, just read their state and swap the images accordingly. So the image would be (or mimic) the LED.
I'm trying to imagine the task that would be best done with this method, but to your question, yes, it is doable. There may be a number of ways to do what you want, but only one comes to mind, and I can describe that;
LEDs do not have associated scripts, but they do have an input and an output. The output has a pulldown with a bunch of choices, none of which would do what you want. I do not know if you can just type in some other option nor what those options might be if you could .
That leaves you needing to continuously monitor either the LED itself or something that the LED can output to. The only mechanism for monitoring something, to my knowledge at this point, is the screen script (I don't recall its actual name at the moment) that is accessed in screen edit mode by clicking the very topmost item in the upper left window (wxMach01).
This script runs continuously and you can add whatever code you want and it will loop indefinitely. In this script, you can look at the LED using scr.GetProperty or look at whatever the LED is outputting to, say output#7 or something like that.
When the state changes, the script will catch it and do whatever you told it to do in response, in your case swap an image. I don't know what image you want to swap, so can't help there.
[/quote]
I don't have Mach4 in fornt of me, but is there a border style option of "none"?
On some types, yes. But not on the image toggle
-
That leaves you needing to continuously monitor either the LED itself or something that the LED can output to. The only mechanism for monitoring something, to my knowledge at this point, is the screen script (I don't recall its actual name at the moment) that is accessed in screen edit mode by clicking the very topmost item in the upper left window (wxMach01).
This script runs continuously and you can add whatever code you want and it will loop indefinitely. In this script, you can look at the LED using scr.GetProperty or look at whatever the LED is outputting to, say output#7 or something like that.
When the state changes, the script will catch it and do whatever you told it to do in response, in your case swap an image. I don't know what image you want to swap, so can't help there.
This is what I would want to do.
I just want to use images instead of the built in LED's, which as you've noticed, look like crap.
-
Ger,
Use the Lua Script Panel, as you custom background (and you CAN edit its boarder, color etc., see wxTemplate in the tool box).
At any rate, drop your LED pics (states) onto that panel as a change-able bitmap.
For that matter you ENTIRE Screen could be one GIANT luaPanel that is really a wxdialog or whatever that is filled
with all kinds of high end GUI stuff.
Yes, it is more work, but, you would have control over what and how things show.
Scott
-
Ironically, I found this with a google search and it happens to be here on the forum.
Main documentation overview can be viewed here: http://wxlua.sourceforge.net/documentation.php
1. Lua
Replacing Basic, this is the new scripting language used in UI callbacks, scripts and wizards. API documentation: http://www.lua.org/manual/5.2/
2. wxLua
This UI library was originally built on C++. It makes you able to build windows, frames, input fields, buttons and has been ported to Lua (not all of it, but most). You can either refer to wxWidget original API documentation (starting at http://docs.wxwidgets.org/2.8/) or to the sparse wxLua doc (http://wxlua.sourceforge.net/docs/wxluaref.html, please scroll down for partial API).
There are tons of docs and examples on SourceForge and after a few nights of reading, I should be up to speed.
-
(and you CAN edit [Lua Panel's] boarder, color etc., see wxTemplate in the tool box).
Do you know how to turn off the border on image toggle buttons?
-
Attached is a quick video of the 'cascading buttons' idea I described a few posts back.
Also note that the larger 'master' button setting off the cascade is not an image toggle, but just an image button. I discovered that the single 'enabled' image can be changed 'on the fly' which opens up some interesting possibilities.
There are some other goodies as well, but I have now managed to make MACH4 unusable by not commenting out a wx.messagebox in the PLC script, so not it just continuously puts the box up in a split second after dismissing it and the net effect is that I can't do anything else. :'(
I have tried a number of things to escape this loop, but so far no joy. Anybody know how to recover from this?
-
I like my buttons FIRMLY attatched to an exact spot on the screen. That way I KNOW where they are when I need them.
(;-) TP
-
I like my buttons FIRMLY attatched to an exact spot on the screen. That way I KNOW where they are when I need them.
You would need to go back in time to DOS for that. The windowing environment had had things popping on and off the screen as needed since Xerox invented it many moons ago. That is more or less the whole point. Mach is a windows program and already has, in addition to the normal windows pull-downs, tabbed 'pages' as well as a separate set of tabbed windows within those pages.
Widgets pop on and off the screen, are resizable and can be moved anywhere, not to mention dialogue boxes for everything from alarms to user input.
If you click on a tab, a new set of 'buttons' appears. If instead, you click on a button and a new set of buttons appears, there is no operational difference, except that you have more control over placement and how much space is consumed. All I will do is make the process more ergonomic and context sensitive.
The great thing about MACH is that you CAN have all of your buttons 'glued' to one spot if that is your preference.
-
The thing to remember with machine tools IS the operator HAS to maintain focus on the job. THE more GAMEBOY like you make the screen the harder it is for the OP to concentrate on his job. That is WHY you NEVER see Gamboy type screens on real CNC machines.
Stop and take a look at HAAS screens. State of the art for controllers and very DOS like in nature. AND there is the reason for that.
Also keep in mind that new flashy things are NOT always best for Machine controllers. Kinda like the saying that not all things FANUC are a good idea to duplicate when building a new controller(;-)
This is just my experience YOUR mileage may vary.
Just a thought, (;-)
-
The thing to remember with machine tools IS the operator HAS to maintain focus on the job.
Well, that explains why so little ergonomic research goes into heads-up displays and control systems for fighter aircraft. ::)
THE more GAMEBOY like you make the screen the harder it is for the OP to concentrate on his job.
You should have said so before all those millions were spent on those 'GAMEBOY like' HMI control systems. :)
This is just my experience YOUR mileage may vary.
My mileage varies a lot from CNC machine tools. HAAS and Fanuc may or may not be 'state-of-the-art' for CNC machine tools, but that is not representative of true 'state- of- the- art' in HMI. Nobody dies if a CNC operator pushes the wrong button at the wrong time.
You may have noticed that MACH4 out-of-the-box has some of this 'fancy' stuff and even some context sensitive controls. Apparently they also did not get the memo where it was explained that you don't need to disable buttons so that they will not function when they SHOULD not function. It is not a big leap to go from disabled to disappeared. Functionally, these methods are the same, but one makes the screen less cluttered and uses the real estate more efficiently.
In any case, the purpose of this thread is to figure out how to make the screen pretty, not to debate whether it should be pretty or not. If ugly is your preference, you don't need to learn anything. Ugly is included for free.
Incidentally, from what little I saw of the wizard you are working on, it looked pretty jazzy to me. There were big photos in the middle of the screen, provided by yours truly. Which HAAS or Fanuc control was that idea copied from? ;)
Incidentally, didn't you get a script stuck in a continuous loop? How did you get out of that?
-
Update:
I was able to get out of the bad PLC script loop, so no longer need an answer on that.
-
Steve you never saw that Wizard released with those pictures did ya ?? That was more about stroking ego's than anything else and it seemed to work.
(;-) TP
-
Steve you never saw that Wizard released with those pictures did ya ??
You posted pictures with the old photos in it and you also posted pictures of your widget with the new photos in it, but to answer your question; No, I never saw it 'released' at all.
Terry,
A good sniper does not reveal his position before taking the shot.
It is your prerogative to choose ugly for your screens, your widgets, or your comments. It is my prerogative to react or ignore. I shall choose the latter from here on.
-
Attached is a short vid of an LED being manipulated by a DRO. The code to accomplish this is also provided here for anyone to use.
There is a bug in the LED wherein the LED will hide, but will not unhide. I have reported this in the bug thread and when it gets fixed, I can continue with the idea of having LED's appear and indicate the status of various operating conditions via size, color, location or other parameters.
The videos are intended as 'proof of concept' and not what an actual practical screen might look like. I do have in mind to have an LED similar to that shown in the vid to pop up and indicate an 'overspeed' or 'overpower' condition at a spindle. The video shows cycling thru all colors, but most likely in practice only green yellow and red might be used for the application described.
So we have covered both kinds of image buttons and LEDs and how to retrieve and set the parameters of all. That should get people started down the road to 'Purdy' Screens. I have deadlines coming up so this will be it for me for a while, but I'll stay subscribed and answer questions if I can. As is typical of this forum, there are lots of reads and very little participation. Please don't be afraid to post questions, or whatever you are working on. There is no such thing as a stupid question, so don't even worry about that.
I mentioned earlier in the thread that using exponents as color numbers could be an advantage and that is shown in the calculations in the code fragment.
-- Lua Code fragment for calculating LED color from dro Values
-- Mach4 Screen
-- © 2015 www.theCUBEstudio.com
-- NOTE: dro is named 'droRPM'
-- the dro gets its values from a slider that is not shown in the code
local CurrentRPMstring = scr.GetProperty('droRPM','Value'); -- grab the value in the RPM dro NOTE: is is a string
local CurrentRPM = tonumber(CurrentRPMstring); -- convert to number
-- convert slider value into an integer between 0 and 7 to use as color number
-- NOTE: color 'numbers' are exponents
-- dro values come from slider. Slider values are 0 to 2000 so for max of 7, divisor will be 2000/7 = 285
-- only the integer part of the number is required so find that using math.modf
local colorCalcVar = math.modf(CurrentRPM/285);
--*********************************** -- debugging stuff leave commented out *************************************
--wx.wxMessageBox (CurrentRPMstring)
--wx.wxMessageBox (tostring(CurrentRPM))
--wx.wxMessageBox (tostring(colorCalcVar))
-- mc.mcRegSetValue(RPMcmdRegHandle,RPMSliderValue); -- this sends data to modbus for use by the InTurn™ Controller
-- datat can be sent anywhere desired by adding the appropriate code here
--****************************************************************************************************************
if (CurrentRPM == 0)then -- if spindle is stopped, turn off LED
scr.SetProperty('ledBarRPM','Hidden','1');
else -- if Spindle is moving, turn on LED and set calculated color
scr.SetProperty('ledBarRPM','Hidden','0');
scr.SetProperty('ledBarRPM','Color',tostring(2^colorCalcVar)) -- note calculated color 'number' is the exponent
end
-
It is your prerogative to choose ugly for your screens, your widgets, or your comments.
It is my prerogative to react or ignore. I shall choose the latter from here on.
A good rule to follow during discussion is to question for understanding if intent of a comment
was not understood. One should consider the comment if it is additive to what is being discussed
or just keep in mind the point made. Comment nor reply need not be defensive but would just clarify intent.
Continue exploring the new interface and by all means post the how to do it...... :)
RICH
-
Steve that sounds like a great idea ..... We can agree to ignore each other.
Just a thought, (;-) TP
-
you got a bit missing from you code condition or if one then the other
-
you got a bit missing from you code condition or if one then the other
The code I have posted here are not complete programs that are intended to be 'run', so there would be are a lot of bits missing. They are 'fragments' to show one method to accomplish a specific task. You will need to lift all or part of the example and insert into your own program. Change the screen item names and variable names to whatever you have used.
ex: in the code fragment, the dro is named 'droRPM'. That is a name that the programmer makes up and it has no special meaning to Lua or Mach, but it is a good programming practice to name things intuitively so that the code 'read' in a more comprehendible way.
That being said, if you can be specific about what you are trying to do, I might be able to help you.
-
What I meant was have the images change state based on the state of the LED's. I don't need to manipulate the LED's, just read their state and swap the images accordingly. So the image would be (or mimic) the LED.
It just occurred to me that the LED 'state' can be any of the eight colors, so if you monitored 'Color' instead of 'Value' you could track 8 conditions.
So there actually is an advantage to using the LED type. As far as the ugly factor on round LEDs, I would not let that stop me from using them because I think the Ugly will go away once they fix the anti-aliasing. I can't imagine any modern graphics handler that does not support this feature. I would speculate that it is available, but just turned off. Anti aliasing is compute intensive so it is often defaulted to OFF (for low end graphics cards).
-
But if the goal is "Makin it Purdy", then we can do much better than the built in LED's.
-
But if the goal is "Makin it Purdy", then we can do much better than the built in LED's.
An LED bar graph would be easy enough, and the square LEDs don't have the Ugly syndrome. You can stack a bunch of them to make the bar, but there are not enough colors to make it 'Purdy'.
I was leaning toward the image toggle buttons with one photo of a lighted lens and one of a dark lens (there are examples posted). However, I have discovered that the image on the regular (non toggle) image button can be swapped out in real time, so actually you have an OFF state and an unlimited number of ON states . . all of which can be 'Purdy'. There is an OFF image, so you could also have a bunch of OFF states, but that does not seem very useful . . . at least not at the moment.
You can get a feel for how fast the images change in the video where one of the buttons changes from a round light to a cap that says accell.
Several colors of light could follow some parameter and trigger a buzzer if a certain level was exceeded. I think MACH4 can play sounds (not in front of it at the moment)
I'm wondering if you could not make a speedometer type gage by swapping in images of the speedo face with the needle at different positions, or overlay the needle on a background image using the alpha channel.
The problem with putting an image over a button, is that either the Z order does not work as expected, or the buttons override the setting. Not sure which at this point, but I'll figure it out eventually, and I've been looking at wxLua and wxWidget as I get time and there are a lot of goodies there .
-
Update: the problem with controls not re-appearing after being hidden seems to happen only if the control is in a panel (group). I have updated this in the bug reporting section.
Attached videos:
First: demonstrates the idea of monitoring something (a dro in this case) and having action taken based on the values monitored. Also LED appearing only when needed (the vertical bar is actually an led). And also making a dro flash in response to reaching a certain level. IN this test, the RPM dro is being used, but the target for this feature will be a dro (or a fancy gage) that measures power output on the a spindle. The action taken on an overload situation might be to start a cooling fan or slow the federate in response to a motor overload in order to prevent a fault.
-
Size limitation required a second post for the second video . . . .
Second: demonstrates a simple context sensitive control. The two sliders are for RPM and SFM and can be set from the dro or the slider or a macro. They work in real time so moving the slider changes the rpm of the 4th axis while it is running. the SFM slider is only active in 'AutoSpeed' mode and the RPM slider is only active in 'SetSpeed' mode. Since the controller takes it's data directly off the dro, it is not possible to change the spindle speed using the wrong method. ex. setting 1000 SFM could result in an entirely different speed than 1000 RPM.
Note that any monitoring task, so far as I can determine, must be run in the PLC script. Working in this script should be done with consideration for how much processing power you are consuming with your script and keeping in mind that you should not loop anything as it can easily get into a 'deadly embrace' wherein whatever need to happen to break out of the loop . . will never happen while in the loop.
Question: I can find no way to create a variable in the PLC script that will not be reinitialized on each running of the script. It seem that rather than loping within the script, it runs from the beginning each time. I suppose this might be good in some ways, but having no variables to carry data forward to the next run is uber inconvenient. As a work around, I am using a gReg to carry forward a simple counter that controls the speed of the flashing on the dro.
Does anyone know how to create a var that will not be reinitialized? Lua syntax to create a variable is: var ::= name, but that does not work in MACH4. I have been unable to figure out how to create a variable without initializing it.
-
I have figured out how to eliminate the border around the buttons, but to do so would require either;
Mach4 team to add this to their screen editing routing
- or-
Access to the source code for the Mach4 screen set
So the question is:
Do we have access to the MACH4 screen source code?
-
Attached video shows the completed spindle power monitoring.
I have been unable to get the 'gauge' screen item to work at all, but I am developing some tricks to make interesting 'gauges' using different techniques as shown in the attached video fragment.
The analog data is being collected by the Arduino DUE board which does the A/D conversion and maps the values to 0 thru 150% and ships them across TCP Modbus to a DRO on the MACH4 screen. The PLC program grabs the data from the DRO and controls the 'gauge' bar and the warning light.
The percentage can be a percentage of the maximum or a percentage of the current torque limit setting, which I have in mind to use for rigid tapping.
I *think* I saw a bunch of user accessible data fields in the tools data base, so if that is correct, then each tap size can have an associated torque limit as a parameter and that could be sent to the spindle drive and the displayed torque range could then display from 0 to 1XX% of the torque limit.
With that scenario, the drive could be relied on to fault if the torque limit was exceeded -or- the Torque limit data from the tool table could be used by the script to pause the running G-code if the torque limit is exceeded for the particular tap being used. The pause and associated error message would allow the operator to change the tap and then simply continue along instead of tracking back the line of untapped holes like following bread crumbs until you find the one with the snapped off tap stuck in it.
There are a lot of other interesting and useful things that can be done with the spindle load data once it is in MACH . . which is now is.
-
Hi there,
I'm doing a big rework on my custom Mach3 screen to port it to Mach4. I've already played around a bit with the designer, read through the manuals and threads but now I'm at the point at which I need some questions to be answered to get some nice graphics stuff working; since this thread contains some promising suggestions I allow myself to take it up again for further inspiring discussions :)
1. working with multiple pages: I have multiple pages in my screenset (don't want to have them be organized in tabs because of graphical reasons) and I want so have a "Master page
" whose objects (buttons, labels etc.) are visible on all other pages. In the machscreen screendesigner there was such a master page. In the screen 4 designer I can see all objects from all other pages, but during runtime I only see the objects of the active page. So: why can I always see all objects of all pages in the editor, but more important, is there a way to make certain objects visible to all pages?
2. transparent image buttons: another important questions for me as it would save a lot of work.. for this I took up this thread (http://www.machsupport.com/forum/index.php/topic,28217.0.html).
3. LEDs with images: I need images on a LED toggled by the state of the LED. Since LEDs in Mach4 doesn't support images by now, did I get it right that one possible solutions is to monitor the led state in the PLC script and then change the image of an image object according to this state? So I have to write code for every "image LED" I want to have, but I have the advantage of having more than two states, right?
some other issues I've encountered, not sure if they are bugs, features etc. so I first wanted to ask..
4. objects moving by themselves (if screenset is larger than monitor): I've noticed that some, if not all of my object change their position nearly every time I switch from editor to runtime mode. Maybe because my screenset is bigger than the editing area? It's for 1280x1024, so the actual design size is 1272x950 (res. minus taskbar and menue), my monitor has 1680x1050; so it might be the issue mentioned here?:
Yes, it works fine for me. You do need to get used to it, and do things a certain way. Also, I use it in XP, it may not work as well in newer OS's.
Also, I've heard that if the screenset is larger than your monitor, and it uses scrollbars to display it all, it can have issues.
5. What's the "Lock Position" Button for? I don't see any effects..?
6. The "o"-Key isn't working in the screen designer tree manager window and the object properties window for me. Anyone has the same issue?
Thanks for any suggestions, Jerry
-
That sentence you quoted from me was talking about the Mach3 screen editor, which is called Screen4. It has nothing to do with Mach4.
-
Oh ok, I got that wrong.. Still I have a similar issue in the Mach4 screen designer so I wonder if anyone noticed that too.