Local/Global Variables (For users)

[fred]

Hi,

Adding feature to enable users to use some variable would be great. Accordingly, users can build their own canned cycles or probing cycles or any other cycle. This feature is critical for commercial machines and is a must in any high end machines. I think this can make Masso far more valuable.



A small code snippet:

O9001 (X axis Probing)

G38.2 X100 F100

G92 X #115 (Here #115 is the user variable)



My suggestion is reserving at least 20 variables for users. Traditionally, that may begin from #100 and goes like #101, #102 This would result in a more flexible generic controller for wide range of applications.



Fred

 

[fred]

Hi @masso-support,

Have you considered this issue?

Fred

 

[lala]

Having variables would really be great.

Additionally some smaller condition statements would nice.

 

[aussiemike]

Has there been any consideration for this yet? Would thought the G3 could handle variables with ease.

 

[MrWinterbottom]

The original post was from August 2019, a similar idea here:

Customized buttons and variables

In the F2 screen, depending on the usage as mill/plasma/lathe/etc, there are some buttons with predefined activity behind. https://forums.masso.com.au/threads/f2-page-buttons.2350/post-18241 Two ideas: a) let the user make use of custom buttons (with some G code in F1 screen and a self defined...

forums.masso.com.au

No reply from Masso so far. The idea management process is somehow challenging, because the user could/could not get a reply.
This will probably lead to less ideas posts in the future.

I made some suggestions based on first experiences with version 5, also no reply.

First experience with v5

My first experience with v5. It´s a mix of findings, perceptions and ideas. "The stuff that dreams are made of", like Humphrey Bogart said :-) The first 2 hours - https://forums.masso.com.au/threads/loading-firmware.1540/post-17981. Idea: add this hint to...

forums.masso.com.au

 

[aussiemike]

Thanks for those links. Well done. I’m surprised and disappointed that Masso didn’t follow up. until now, I always got great responses. There were things the G2 didn’t have capacity for, but I would have thought the G3 could easily deliver. I still have far to go in learning to write g code, but it seems variables is a common feature in the CNC world. I can’t imagine BASIC or Pascal without variables.

 

[unlockedcomposites]

@breezy
I know you're a busy man, but I have been thinking the same as them, having access to writing and reading variables is a big step but would put the controller another head and shoulders above others.

Even if it was an unlockable feature so that those who really want it can add/support the feature.

Would be great to be able to use it to have another place to write probing data to as well, writing probing data to only offsets is helpful but not a good workflow if one is trying to reference a few data points and not given the standard 10 offsets many others offer (G59.1 - G59.3 missing)

 

[zombieengineer]

@aussiemike & @unlockedcomposites

I am going to add to this conversation as "the devils advocate" as adding variables could potentially open a catering size can of worms.

If the variable is simply a text substitution then this could be implemented fairly easily. Once you start looking at numerical expressions (add, subtract, multiply, divide, etc) then things get really ugly really quickly. Something such as brackets in an expression would throw a spanner into the gears of the G code processor as the line of text could not be processed left-to-right in a single pass.

As part of my day job I build and maintain training simulators for chemical plant operators. Back in 2000/2001 I wrote a utility which converted PLC code (IEC 61131-3 structured text) into a programming language that could be compiled on a PC. The tool that I used to tackle the problem was YACC (Yet Another Compiler Compiler) which actually dramatically reduces the complexity of the problem (from "insanely difficult" to "hard").

WARNING - Complex technical information follows

What happens is the line of text is broken into "words" (token) which is passed to the parser engine code generated by YACC. The parser engine takes one token at a time and adds them to a queue, as soon as a rule matches with the last N tokens it will replace the matched tokens with a token that represents the result of that rule. I know that sounds abstract but a worked example might make it a little easier to understand.

Input buffer: "X = 1 + 2 * 3"
Equivalent tokens: "X", "=", "1", "+", "2", "*", "3", EndOfLine
Processing:
Step #1: "X" (No rules match)
Step #2: "X", "=" (No rules match)
Step #3: "X", "=", "1" (Multiple rules match - hold until unique rule is found)
Step #4: "X", "=", "1", "+" (Multiple rules match - hold until unique rule is found)
Step #5: "X", "=", "1", "+", "2" (Multiple rules match - hold until unique rule is found)
Step #6: "X", "=", "1", "+", "2", "*" (Multiple rules match - hold until unique rule is found)
Step #7: "X", "=", "1", "+", "2", "*", "3" (Multiple rules match - hold until unique rule is found)
Step #8: "X", "=", "1", "+", "2", "*", "3", EndOfLine (Multiplication rule fires)
Step #9: "X", "=", "1", "+", "6", EndOfLine (Addition rule fires)
Step #10: "X", "=", "7", EndOfLine (Assignment rule fires)
Step #11: Assignment, EndOfLine (No further rules available)

Looking at my old code the following are the rules used for a numerical assignment, including the relevant operator precedence (one rule per line):

---

assignment_statement: variable '=' expression​

​

expression: term​

| expression '+' term​

| expression '-' term​

​

term: power_expression​

| term '*' power_expression​

| term '/' power_expression​

| term MOD power_expression​

​

power_expression: unary_expression​

| power_expression '^' unary_expression​

​

unary_expression: primary_expression​

| '-' primary_expression​

​

primary_expression: literal_constant​

| variable​

| '(' expression ')'​

---

If you start adding conditional expressions and flow control then the "Jump To Line" functionality of MASSO is immediately broken.

 

[unlockedcomposites]

@zombieengineer @breezy
I understand the apprehension to opening the can of worms. would this be worth to implement even if only in a more simply fashion. EX: a counter, or a place to write/read probing values that doesn't blow away one of the few offsets given.
A single step in the direction of is worth more than no step at all.

In past we were building/designing automatic greasing systems for robots and when asked by the customers to allow for things like this we said no. That was from a liability standpoint of we didn't want one of the big three automakers to repremand us for a problem that sat between the chair and a keyboard. I understand that apprehension.

@zombieengineer I really appreciate your explanation, I had to read a couple times to wrap my head fully around it, for I am a mechanical engineering orc.

 

[zombieengineer]

@unlockedcomposites - I don't work for MASSO, however given my dabbling in coding I can make some educated guesses at the difficulty to implement some of this stuff. At my day job there is another conversion utility for a sequence language where the conversion utility did not use YACC (or similar) - it was hand crafted to keep track of what to expect next, (e.g. "a conditional expression should follow an IF statement") and it became a support nightmare.

Once you have an appropriate syntax parser engine framework implemented then adding extra functionality to the supported G-code language becomes fairly trivial. Understanding some of the concepts behind writing the language syntax rules is a very steep learning curve (specifically avoiding the case where a line could be interpreted more. than one way - YACC spits out a warning when it finds such cases).

As for a counter - M98 can be used to call a sub-program L times. As long as the sub-program uses incremental movement it is possible to create a linear or grid pattern. However the counter value is not accessible.

 

[unlockedcomposites]

Even having 1 value that is able to be incremented could even allow for the possibility to have rudimentary TLM (tool life management)

EX: gcode that adds or subtracts a value based on the wear the program has had on the tool in the past, then the person manually switches tools when the value get so high/low. That would be great.

 

[breezy]

Even having 1 value that is able to be incremented could even allow for the possibility to have rudimentary TLM (tool life management)

Instead of having variables, what if MASSO could log data to the USB?
If this was possible, what data should be logged?

 

[unlockedcomposites]

Instead of having variables, what if MASSO could log data to the USB?
If this was possible, what data should be logged?

Im not sure what it solves or would look like? What data could it log? And how could it be referenced?

Still very interested in values that can be referenced in a program and interacted with through the gui. that would be great no matter where it is stored, if you needed to store them on the USB i think that could be an option if memory is an issue.

Is memory a barrier to these and/or is it developmental a barrier?

 

[breezy]

would look like? how could it be referenced?

CSV file that could be loaded into a spreadsheet and analysed by the user to their requirements.

What data could it log?

That's what I'm asking for. Some thoughts:- machining time, tool change counts, pierce counts.

Still very interested in values that can be referenced in a program and interacted with through the gui.

Currently when the plasma head is selected the total number of pierces is displayed on F2 screen.
But this is not referenced from the program, it is part of the new G200/M03 command structure.

 

[unlockedcomposites]

@breezy
(CSV usb datalogging)
I think its a noble pursuit, but without the ability to easily reference and interact with data in the GUI it would involve so many steps to just reference the data.

1. remove thumbdrive containing all programs
2. machine sits idle while data is uploaded, or the person has to round robin more thumbdrives while keeping track of the possible differences in each different thumbdrive
3. upload data to pc
4. open data and reference/save data
5. replace thumbdrive
6. manually act upon the data with the machine

This is a feature, but not exactly what we are asking for, it doesn't really accomplish goals referenced before


Beginning of what can of worms @zombieengineer was talking about (used in the most simple form I can think of)

​

Reference of some simple use cases ↑​

​

Use case ex I would use (The need to monitor a critical tools lifespan)↓​

​

variable #1 set to 100 upon tool replacement​

​

(1001)​

(T8 D=3.175 CR=0. TAPER=45DEG - ZMIN=2.2 - CHAMFER MILL)​

G90 G94 G17​

G21​

G28 G91 Z0.​

G90​

(2D CHAMFER1)​

#1 LT 5 GOTO26 (Ends program if tool life is LT (less than) 5)​

M5​

T8 M6​

S28990 M3​

G59​

G0 X6.269 Y2.128​

Z18.25​

M8​

Z8.25​

G1 Z5.25 F762.​

Z2.25​

X6.259 Y2.445 F1000.​

X6.124 Y2.441​

X6.12​

X5.032 Y2.411​

Y-27.98 Z-0.396​

#1=#1-15 (Subtracting 15% from tool life after it runs the tool) ​

X12.641 Y-27.988 Z-0.35​

Z28.25 (Line 26 Z retract before end of program)​

M9​

G28 G91 Z0.​

G90​

G28 G91 X0. Y0.​

G90​

M30​

So different programs can run different tool life subtraction values and it isn't based on something as arbitrary as time
@zombieengineer please let me know in which way I messed up this example lol I bet there is something wrong in there.

the same could be used for probing values Masso could call probe and run straight probing cycles compare the two variables and see if a part is located properly before running the program.

I am working in the shop overnight in the states and my brain is mush without writing code so i wont strain it for that example now but it would only need 2 variables to do so I believe. these are the types of things that those who started this thread and myself are asking for.

​

​

 

[breezy]

I think its a noble pursuit, but without the ability to easily reference and interact with data

If you could access the log file interactively via MASSO link, you wouldn't need to

1. remove thumbdrive containing all programs
2. machine sits idle while data is uploaded, or the person has to round robin more thumbdrives while keeping track of the possible differences in each different thumbdrive
3. upload data to pc
4. open data and reference/save data
5. replace thumbdrive
6. manually act upon the data with the machine

Creating the log file would be the first stage, accessing it interactively would be future stages.
Need it find out what data would be useful to collect.

Googled Haas operating system and found this answer.

Does anyone know what OS Haas control is on top of? I read somewhere that its Debian based.
It's java running off of Ubuntu.

This is the reason you can do

variable #1 set to 100 upon tool replacement
(1001)
(T8 D=3.175 CR=0. TAPER=45DEG - ZMIN=2.2 - CHAMFER MILL)
G90 G94 G17
G21
G28 G91 Z0.
G90
(2D CHAMFER1)
#1 LT 5 GOTO26 (Ends program if tool life is LT (less than) 5)
M5
T8 M6
S28990 M3
.....
Y-27.98 Z-0.396
#1=#1-15 (Subtracting 15% from tool life after it runs the tool)
X12.641 Y-27.988 Z-0.35
Z28.25 (Line 26 Z retract before end of program)
M9
G28 G91 Z0.
G90
G28 G91 X0. Y0.
G90
M30
So different programs can run different tool life subtraction values and it isn't based on something as arbitrary as time

these sort of things, because it is a PC motherboard in their enclosure, not a microprocessor.

 

[zombieengineer]

The biggest issue is going to be program space as the micro-controller used in the G3, I just compiled the parsing engine for the "PLC Structured Text" and the resulting object file was about 200 kB. That may not sound much but currently the G3 firmware image is 6836 kB. Basically an expression evaluator is likely to add between 5% to 10% to the code base. The actual processing time is unlikely to be an issue as back in 2001 the PC clock speed is about the same speed as what the G3 micro-controller (400 MHz).

# Puts on fireproof overalls #

Ten years ago I would of said that an expression evaluation and other "program like" features would of been necessary. This was a time when CAM software packages were rare, and/or the cost was beyond the budget of a small shop / hobbyist. Today there are a number of reasonably priced CAM packages are available, even variants focused on specific work flows (e.g. "SheetCam" is focused on sheets of material).

Where I would of used an expression evaluation would of been to define a co-ordinate using trigonometry ("move from point A a total of 50mm at a bearing of 30°"). Today this style of placement can easily be done in Fusion360 and generate a NC file with the positions defined to an accuracy of microns.

Is there any use for an expression evaluator / scripting / user defined programs in the MASSO world?

I think there is but not in the NC file that gets loaded and used for machining. The place where it belongs is to replace the existing "Conversational Wizards" with a method to allow users to define their own conversational wizards. This may consist of a file that contains a script and user interface definition (think dialog box layout with user entry fields). Once all the parameters have been entered and the user presses save the script is run and the appropriate G-code is generated.

Tool Life
In response to Breezy's query about tool life statistics, the best you could do is have an accumulator of usage time. This is barely an improvement over the number of program cycles (which could be used to calculate the tool usage time indirectly).

I found a research paper looking at tool wear on a lathe as a function of parameters such as depth-of-cut, spindle speed, spindle load and feed rate. The depth-of-cut was the most significant contributing factor (about 60% of the tool wear) which isn't something that can be inferred from a NC file. I was trying to figure out if there was some method to measure the spindle power and correlate this to tool wear (this was about 15% of the tool wear - not significant enough to be wasting time on).

What I did find with respect to spindle power is that as the tool wears the spindle power increases (20%-25% over a fresh tool). There may be an opportunity to include a spindle load measurement with soft alarms for each tool to indicate when a tool should be inspected / replaced due to wear.

Work Piece Probing
An area where expression evaluation / scripting could be useful is automated probing to set work co-ordinate system. Currently there is no G## code to probe for the centre of a bore. This would be useful for when you place a casting in a jig where the location of the bore could vary by a couple of millimetres. You could shift the probe such that it would roughly in the centre of the bore and then run the program. One of the first commands would be a probing run to find the centre of the hole which then becomes the X/Y zero for the current WCS. I have only described one scenario, there could also be situations of using a probe to set the Z zero (top probe) or X/Y zero (side touch probes).

EDIT: The HAAS G36 Automatic Work Offset Measurement would be an example of how work piece probing to set WCS could be implemented.

 

[paul schmitt]

I’m building a labeling machine for custom tool packaging. I would use a conditional statement to index the next label past the optic sensor thus being assured the label is in its correct position to then be sticked.

 

[cncnutz]

I’m building a labeling machine for custom tool packaging. I would use a conditional statement to index the next label past the optic sensor thus being assured the label is in its correct position to then be sticked.

Hi Paul,
Have a look at Gcode M66 and see if that will help you.
You should be able to use it to wait for the Optic sensor to send a signal telling you that it is in the right position before proceeding.

M66 - Wait for Input

docs.masso.com.au

Cheers Peter

 

[tomdieselworks-com-au]

Instead of having variables, what if MASSO could log data to the USB?
If this was possible, what data should be logged?

Logging will not replace variables as variables hold data that can be used real time.
In my case I would need a couple of variable #Bore_Depth and #No_of_Cylinders

If I would have these available to utilize in G-Code, I could do with one generic set of programs, but for now I am generating and using a set for each model.