Machsupport Forum

Mach Discussion => Mach4 General Discussion => Topic started by: Chaoticone on May 02, 2014, 03:02:52 PM

Title: Mach 4 Feature Request
Post by: Chaoticone on May 02, 2014, 03:02:52 PM
List any features you would like to see in Mach 4 in this topic. Lets keep it clean so Brian and Steve can see them at a glance without having to filter too much noise.

Brett
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 03, 2014, 04:30:18 AM
G-code EDITOR:

In the search and replace feature, allow multi line replacements for single line finds. Example can be found in Notepad++

A slash and single character represent standard editing control codes like carriage return and newline. ex. '/n' is newline

example: FIND: 'G1 Z0'
              REPLACE: 'G0Z.050 /n G1Z0F1 /n F30'


Each instance of 'G0 Z0' would be replaced by three lines of G-code,
Title: Re: Mach 4 Feature Request
Post by: matrix on May 03, 2014, 07:21:02 AM


Tool Path,

Clicking with the mouse anywhere on Toolpath window and the machine move for that point.

Clicking on a line on Toolpath window (GCODE FILE) and the machine moves to the precise coordinate of the, X/Y/A/B/C.

Thanks
Title: Re: Mach 4 Feature Request
Post by: matrix on May 03, 2014, 08:12:23 AM

Still in toolpath,



Camera interface (webcam or other)  for the Toolpath window, Direct view of the table x / y appropriately scaled.

Select the lines of work and drag to move the job to another coordinate, Very useful in combination with the camera.


Thanks
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 03, 2014, 10:23:33 AM
Protected Move mode to protect the probe. (vital)

Reverse mode G31 where the it probes into a part then stops and reverses back out to the switch remake then stop and record positions. This speed up some routines as you do not have to back off the switch to be able to probe in another direction.

Probe tip compensation so that the positional values are accurate to the tip used. (very handy,vital). Do it as a tool table entry to define tip radius AND switch travel.

Built in Probe calibration routine based on the ball and bar routine(vital)

Torque limited move mode to protect the machine. (nice to have)

Full Function G12/13 mode. (HAAS style, Nice to have, not vital)

Control  page showing ALL the System # vars values  accessable from Gcode (VITAL)

Gcode window to dispaly Gcode #var as VALUES on the fly. ( Very Nice to have)

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: smurph on May 03, 2014, 01:20:01 PM
Torque limited move mode to protect the machine. (nice to have)

Control  page showing ALL the System # vars values  accessable from Gcode (VITAL)

Gcode window to dispaly Gcode #var as VALUES on the fly. ( Very Nice to have)

(;-) TP

The first one is motion controller dependent.  I don't know if we can ever do that.

The last two can be done in the screen set.  Almost anything is possible now!  However...  you must remember that the G code variables get updated in look ahead time. 

One thing that I was thinking of doing was letting the user put a G code vars in a comment so when the comment is processed those G code vars get evaluated and printed as part of the comment.

Steve
Title: Re: Mach 4 Feature Request
Post by: smurph on May 03, 2014, 01:24:35 PM
But my point is that a lot of the special features that people want are capable of being done in the screen sets.  It won't be long before there are tons of examples.  Some guys are already blowing my mind with the ideas that they have implemented in the screens!  And I think that is most cool.

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 03, 2014, 03:52:47 PM
HIYA Steve, IF the #vars are processed at look ahead time(buffer load) HOW are you to use variable that are not updated until a line is processed. Take for example.

N001  G1 X12 Y0
N002  G1 X [#5601/2]

 Lets say that the #5601 is the A axis current position value. The value is NOT known until the N001 line just above it is processed and motion stops. Then the N002  line values would be

N001 G1 X12 Y0
N002  G1 X6

That is not a great example just a simple one that deals with #vars that are system #vars

HOW is that going to work out with look ahead . Normally a control emptys the look ahead and drops back to real time in that instance.

Yes I agree with your idea for #var values AS (comments) on the same gcode line. BUT not if the user has to control it. It should be an auto function with no input from the user.

 FOR example

#100 =24.000
#101 =48.000
G1 X12 Y0 F10
G1 X#100 Y#101    ( X24.000 Y48.000)  

THAT would be great for Conditional / parametric programmers.

(;-) TP

Then it shows up in the Gcode window automatically. Brian and I discussed this long ago (;-)

BY the way IS THERE a list of System # vars  for Gcode USE??



(;-) TP



Title: Re: Mach 4 Feature Request
Post by: smurph on May 03, 2014, 05:13:08 PM
Look ahead doesn't work that way.  It is not at buffer load.  It is continuous.  Each movement IS known at the look ahead time  Because it is a continual track of what has been read so far.  Look ahead knows where the machine is supposed to be in the future.  Otherwise, how would we ever calc CV?  So all of the position information is known at anytime during the look ahead process.  Now, what is NOT know at look ahead time is any external inputs.

My comment thing is like this:
if #100 == 1 and #200 == 3

G1 X#100 Y#101 (X#100 Y#200)

Would output "X1.000 Y2.000" in the message line and show in the history (if comments in history is turned on, of course).

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 03, 2014, 05:53:56 PM
HIYA Steve. I assume that the programer has to ADD the (X#100 Y#200)  Comment to the line???  The Control already KNOWS what the values are can it not just display it SOMEWHERE as each line processes. Preferrably on the same line as the Gcode is displayed. Displaying it on the staus line is much harder to read as your eyes have to shift from teh gcode line to the status line . During that time the value could change. At least on teh Gcode line you have a few lines that scroll before you loose the reference.

Hopefully we can get the Control to work for US instead of US working for it. (;-) That is a JOKE in the CNC job shops  by the way. But for them it is a serious joke.

 Have seen this done before on other controllers.

Just a thought, (;-) TP

Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 05, 2014, 03:58:08 AM
Can we have the DRO's persistent after restarting MAch4?

Dan
Title: Re: Mach 4 Feature Request
Post by: smurph on May 05, 2014, 01:16:16 PM
Dan,

Explain to me what you are wanting.  Because the DROs seem to be persistent for me.  But I might just be missing the point of your request.

Steve
Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 05, 2014, 02:01:16 PM
Hi Steve,

Start Mach4, go to the MDI command "G0 X0 Y0 Z0" (or whatever), restart Mach4 and I want to see the DROs show the last location: X0 Y0 Z0. We used to have a setting for this in Mach3 under general Config.

Also related to this, while not as important, is having the option to be asked if I want the fixture to be saved before exiting, like it was in Mach3.

Dan
Title: Re: Mach 4 Feature Request
Post by: Overloaded on May 05, 2014, 02:33:04 PM
Hi Dan,
    Nothing persistent here either. Axis' ref'd or not.
Stock M4 Hobby Screen.
I think Steve said earlier that this may not be the same screen as he is using.

http://www.machsupport.com/forum/index.php/topic,27041.msg191241.html#msg191241

Steve, could we maybe expect the later screen that you have fixed up to this point ?

Thanks,
Russ
Title: Re: Mach 4 Feature Request
Post by: smurph on May 05, 2014, 03:28:06 PM
I think this is a Sim issue.  Because Sim always starts at machine 0 for any given motor.  So when Mach fires up, the motion controller provides the machine position to Mach.  Sim is sending 0 because it is not a real motion controller and we don't save the positions anywhere during shutdown.  With my Galil, I always get what the encoders says.

I'm working on a new build.  It will have the updated screen plus a lot of other stuff that you guys have asked for.

1. Pop up keypad for editing DROs (Auto Calc).
2. Feed Rate tracks G20/G21 correctly.
3. Recent files can have a path longer than 80 characters.
4. File->Open "remembers the last directory instead of starting with the current working directory.
5. Button actions to show the tool and fixture tables.
6. Fixed the softlimit enable check boxes in the configuration.
Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 06, 2014, 02:34:17 AM
Thanks Steve. For the protocol, it seems to be machine 1.0000 for each motor here.

What about the single click highlighting of the DROs - are you considering this? I still think that this is a must for touch screens. Also, the cursor is quite confusing. I enter as number in the X DRO, hit Enter, and then the cursor moves down to the Y DRO, allowing me to type in there, but hitting the Enter key, doesn't save the number there. So could the cursor just disappear after you hit Enter and not move to subsequent DROs?

Dan
Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 02:41:01 AM
Dan,

Brett posted a new install in the Announcements and updates thread.  Have a look at it.  I think you will like it.  :)

There is now a choice of editors for the DROs.

1.  In place (with the changes you wanted).
2.  Basic keypad.
3.  Extended Keypad (math funcs).
4.  Read only.

You will have to edit the screen and change the DRO's "Editor" property to get the Keypads.  The in place editor is the default.  Once you change a DRO to the Keypad type editor, you will then have to enable "Auto Calc" (like Mach 3) in the Operator menu.  The setting is persistent. 

Steve
Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 02:44:18 AM
Oh, and the keypads are resizable.  Make them as big as you want.  Easy touch screen access!!!  The size is remembered so you don't have to do it every time.  They are also intelligent as to their position.  They try to sit below the DRO so that the changes can be seen.  If the DRO is not in a position on the screen for this to be possible, the keypad will move to another location (above or beside) the DRO.  If all that fails, the keypad will pop up in the upper left corner of the main window.

Steve
Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 06, 2014, 02:54:17 AM
Hi Steve,

Thanks. Just downloaded the new build and playing with it. So far looks good.

Yet another question: In Mach3 you had to close the program for changes and settings to be remembered. So if you had power loss, and you didn't restart Mach prior to it, all your changes have been lost. How is it in Mach4? If I change offsets, tool offsets, etc., are they being saved instantaneously, or waiting for restart of Mach4?

Dan
Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 06, 2014, 03:02:14 AM
Dan,

Brett posted a new install in the Announcements and updates thread.  Have a look at it.  I think you will like it.  :)

There is now a choice of editors for the DROs.

I like it a lot, Steve. Much, much better!!! Thank you!

Dan
Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 03:05:53 AM
Most settings are written to the INI file when they are changed.  (All of the Mach config is like this).  This is because they are part of the core and not the GUI.  However, some of the GUI settings are only saved at close.  This is the case for Tool and fixture offsets because they are really just modifying G code parameters.  So no, they are not saved to disk at the time they are modified.
Title: Re: Mach 4 Feature Request
Post by: Dan13 on May 06, 2014, 03:39:34 AM
Is it possible to do a button that will save the offsets? So to not need to restart Mach4?

Dan
Title: Re: Mach 4 Feature Request
Post by: Overloaded on May 06, 2014, 08:31:11 AM
Oh, and the keypads are resizable.  Make them as big as you want.  Easy touch screen access!!!  The size is remembered so you don't have to do it every time.  They are also intelligent as to their position.  They try to sit below the DRO so that the changes can be seen.  If the DRO is not in a position on the screen for this to be possible, the keypad will move to another location (above or beside) the DRO.  If all that fails, the keypad will pop up in the upper left corner of the main window.

Steve

Very NICE job !
As you enlarge the pad, the font stays small. Is it easy enough to increase the font size ? maybe BOLD also ?
When stretched to "Fat fingered touch screen" size, the labels are disproportionately small.

Thanks,
Russ
Title: Re: Mach 4 Feature Request
Post by: Overloaded on May 06, 2014, 10:01:34 AM
Cannot "Cycle Start" from MDI screen page.

The button looks active, but no response.

Russ
Title: Re: Mach 4 Feature Request
Post by: Chaoticone on May 06, 2014, 10:42:58 AM
 :) I'm just enjoying all the progress..............
Title: Re: Mach 4 Feature Request
Post by: Ya-Nvr-No on May 06, 2014, 11:06:13 AM
Russ check out how I wrote my m3.mcs file
it works for me
in gcode, MDI or the button

http://www.machsupport.com/forum/index.php/topic,27141.new.html#new

In the MDI Tab only MDI commands are used
Found that out when I added a MDI to my Diagnostic Tab
Title: Re: Mach 4 Feature Request
Post by: Overloaded on May 06, 2014, 11:35:27 AM
In the MDI Tab only MDI commands are used
Found that out when I added a MDI to my Diagnostic Tab

Ahhhh, yes. Should have realized that.  :P Thanks !
Even with the MDI empty, it's still reserved to execut MDI's only.

Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 01:51:15 PM
Oh, and the keypads are resizable.  Make them as big as you want.  Easy touch screen access!!!  The size is remembered so you don't have to do it every time.  They are also intelligent as to their position.  They try to sit below the DRO so that the changes can be seen.  If the DRO is not in a position on the screen for this to be possible, the keypad will move to another location (above or beside) the DRO.  If all that fails, the keypad will pop up in the upper left corner of the main window.

Steve

Very NICE job !
As you enlarge the pad, the font stays small. Is it easy enough to increase the font size ? maybe BOLD also ?
When stretched to "Fat fingered touch screen" size, the labels are disproportionately small.

Thanks,
Russ

I'll work on the fonts.  But that is not an easy task.  GUI programming is a royal pain!

Steve 
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 02:16:45 PM
HIYA Steve Please consider having the LOAD and edit program go to the proper directory that holds the files INStead of where you were last .

If I press load gcode  it should go directly to the Gcode Directory.

As a reference Les over at SheetCam has that down to a science. You can specify WHERE you want everything to go to Directory wise. Then when you select a task it takes you to the correct spot as the first option. AND that is how it works with the COmmercial controllers I have used.

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 02:32:30 PM
Well...  if you loaded the G code from that directory last, that shouldn't be an issue, right?  I JUST added that in at the request of many others.  It is what it is now.

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 02:46:04 PM
AND IF we had dedicated directories it would not be a problem either AND it would MATCH how main stream controllers do it (;-) HOW does A Fanuc do it or Haas or Mazak?

Moving about just to find the correct directories is not an easy task on a control panel without a mouse. This is not working in sheetsheets or word processors or playinjg games it is a serious machine tool with dedicated tasks.

Just as a reference no other controller I use does it that way.

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: Jeff_Birt on May 06, 2014, 03:11:02 PM
I have one folder where I keep all my GCode. In that folder are sub folders for different product families. It is never that difficult to find the right file unless I go wild and try to load a file from the desktop then that is where it will go next time. The point being if you don't screw it up it won't be broken :)
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 03:23:34 PM
HIYA Jeff,

Just another case of you working for the machine instead of it working for you. (;-) With dedicated directories that the machine KNOWS where to go to or put things it is NEVER a problem to know where something is at. THere is no lost time wondering around in the desert trying to remember where something is at or where you were AT last time.

Like I said Les over at Sheetcam has it down to a science and it works exceptionaly well. Just like commercial controllers where every lost minute in the day cost you money.



(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Jeff_Birt on May 06, 2014, 03:46:02 PM
Terry, the way I do it I am never more than two directory changes form any GCode I'm going to run. Since all product families are in their own subfolder it is very, very easy to find what you want. No lost time. Like I said unless you send Mach off into the wild blue it will always stay where you last told it to look. It is up to you to screw things up, or not...
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 04:17:14 PM
I created a Button to open and view the Gcode Manual using os.execute

os.execute ( "Notepad.exe C:\\Mach4Hobby\\Docs\\M4Manual.txt")

I could not get it to load the native PDF as I could not get "Fox it" to open/load the manual file so I converted the PDF back to a text. I up loaded the Manual Text file here IF anyone wants it

It is NICE to be able to edit the manual on the fly To correct anything I find that needs to be changed or added to.

I works VERY well   BUT , I did notice that if you are running Mach4 Gcode you cannot open the manual. If you do Mach4 looses focus and stops. When you close the Manual Mach4 then resumes running.

Is this to mean that Mach4 cannot multi task when running a program ??

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 04:23:23 PM
HIYA Jeff, Probably not a big problem(though aggravating) for me as well BUT we are not the problem it is that red headed shop monkey that pushes the Big Green Button in the shop that it confuses beyond all means.

"I can't find the file that is the job package and I have been looking for 10 minutes for it. It must have just dissappeared POOFFFFF!"

Been there MANY times directing shop monkeys, (;-) TP

Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 06:50:53 PM
Nice idea!!!  But the os.execute stops the program that runs it (your button script) and waits for the called process to end.  I bet there is another way of doing that which won't "block".  I'll dig around.

Steve
Title: Re: Mach 4 Feature Request
Post by: smurph on May 06, 2014, 07:10:44 PM
os.execute('start "Docs" "Notepad.exe C:\\Mach4Hobby\\Docs\\M4Manual.txt" ')

Try that.  You may need to provide the fill path to Notepad.  But that should not block the script.

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 09:47:47 PM
HIYA Steve, I tried it this way

os.execute('start "Docs" " C:\\Windows\\system32\\notepad.exe C:\\Mach4Hobby\\Docs\\M4manual.txt" ')


but I get an error saying windows cannot find  " C:\\Windows\\system32\\notepad.exe C:\\Mach4Hobby\\Docs\\M4manual.txt"

I do not know what the "Start Docs means. I have triple checked the path.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 10:42:42 PM
I have a function button in mach3 that is a Gcode Load function BUT it looks at a directory of pictures (BMP) and then you can select the correct picture and it LOADS the GCODE for that part.

In SheetCam you can SAVE a picture(BMP) of the job to a directory.

OR take a picture (camera) and save to the directory

Is this possible in Mach4?

HOW about a barcode to load gcode function that is a BIG hit here in Mach3.

SheetCam can write the barcode if MACh4 can read it.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 10:58:24 PM
Using G31 I see there Parameters for the trip point of a call. IS there a parameter set for the endpoint of the call line

G31 X10 Y10 Z1 A10   

The Trip points for the G31 - G31.4 are already there and working I believe.

TO create an error trap for probing I need access to the endpoint values for the call .

 It would need to be a set of #Parms that are accessable from Gcode and looks like would need all 4 probe sets G31 -G31.4.

ALSO I need the #parm for the trip condition  ON/OFF. to create a Protected Move MODE to protect teh Probe from dammage while jogging or moving into position.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 11:00:37 PM
We need to be able to create HOTKEYS ({F5} , etc in the screen set to be able to access buttons for function. (Control Panel without Mouse)

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 06, 2014, 11:29:53 PM
Would it be possible to Link some of the most common # Param s to DROs so that if you update the #param it updated the DRO and Vise Versa.

 it would make dealling with the common parms much easier

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Brian Barker on May 07, 2014, 12:14:26 AM
You can do that in the PLC script. The screen editor is your friend
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 07, 2014, 01:00:22 AM
os.execute('start "Docs" "Notepad.exe C:\\Mach4Hobby\\Docs\\M4Manual.txt" ')

Try that.  You may need to provide the fill path to Notepad.  But that should not block the script.

Steve



Hiya Steve I found this roaming the web.  The process OPENs Notepad fine AND Mach4 still runs OK. But it will not allow you to open the Txt file on load. It keeps telling me windows cannot find it for some reason I do not understand. YET

strProgram = '"Notepad.exe"'
strCmd = 'start "" '..strProgram
os.execute(strCmd)
Title: Re: Mach 4 Feature Request
Post by: FocusPaul on May 07, 2014, 01:16:25 AM
os.execute('start "Docs" "Notepad.exe C:\\Mach4Hobby\\Docs\\M4Manual.txt" ')

Try that.  You may need to provide the fill path to Notepad.  But that should not block the script.

Steve



Hiya Steve I found this roaming the web.  The process OPENs Notepad fine AND Mach4 still runs OK. But it will not allow you to open the Txt file on load. It keeps telling me windows cannot find it for some reason I do not understand. YET

strProgram = '"Notepad.exe"'
strCmd = 'start "" '..strProgram
os.execute(strCmd)

Following works on my system (W7x64):

Code: [Select]
os.execute('start "Docs" "Notepad.exe" "C:\\Mach4Hobby\\Docs\\M4Manual.txt" ')
Please note the different use of quotation marks: Notepad.exe and your text file cannot be in the same quotation mark sequence.
Title: Re: Mach 4 Feature Request
Post by: FocusPaul on May 07, 2014, 01:31:02 AM
Feature request: Create a new G code file from the main menu (menu "File")
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 07, 2014, 01:37:12 AM
Thanks PAUL that did the trick here as well.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 07, 2014, 12:33:51 PM
Next Idea , the Manual button now works great but how about a LOAD manual function that allows one to View the Manuals  " Directory" and pick which one to view.

Probably best to JUST do PDF files though.

Just a thought, as one idea ALWAYS breeds another

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: ger21 on May 10, 2014, 09:29:30 AM
Feature Requests:

Not sure if any of these features are already there, or not, but I didn't see them.

1) Image based dual state LED's like Mach3 has. In my 2010 Screenset, I was able to create fake checkboxes and radio buttons using dual state image LED's. You can use these to "fake" quite a few things that are normally not available. It would also be nice to just create better looking LED's, as the default LED's look like crap compared to the rest of the screen controls. ;)

2) Tooltips. A lot of my 2010 Screenset users have asked for tool tips, for help in knowing what a particular controls function is.
Title: Re: Mach 4 Feature Request
Post by: Ya-Nvr-No on May 10, 2014, 09:38:48 AM
The default state of an LED should be at least off
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 10, 2014, 06:11:43 PM
A G27 and  G29 would be nice to have.

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 10, 2014, 06:23:04 PM
Button controls such as FRO to 100%  RRO to 100%  SSO tp 100% I do not see them in the function list for buttons.

Dry Run  is normally a STD feature ???

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Overloaded on May 12, 2014, 07:46:34 AM
View/Load Screen = Could it go directly to the Screen folder ?
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 12, 2014, 08:36:40 AM
Already mentioned in the Modbus thread, but as these are actually feature requests, duplicating them here in case someone is collecting them up.

1) check Modbus function AFTER startup (currently done before) and provide error message is there is a Modbus problem.

2) provide a convenient way to stream data from screen features (sliders, DRO, etc) to Modbus registers. Perhaps an 'echo' or 'output' field among the config choices.

3) provide for passing Floating point numbers in adjacent Modbus registers or Extended registrers.
      This can be done in scripting, but would probably be faster and would definitely be more universal if the method and structure were dictated by MACH4.

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 12, 2014, 01:23:11 PM
In the tool table there needs to be an option for each tool to be linked to the tool changer SLOT so that when you call   for a tool change the tool # is linked to the TC slot. Set it so that IF the option is checked the tool number call will select what it in the slot# and IF the option is not checked (used) then it call the tool#. That way you can do both auto tool changes OR manual tool changes of tools NOT in the Tool changer slots.

(;-)TP
Title: Re: Mach 4 Feature Request
Post by: smurph on May 12, 2014, 03:39:23 PM
I always set up the tools in the order that I use them.  My machine has a 16 pod Geneva.  So the most frequently used tools are entered from 1 to 16.  Then, my manual change tools are numbered 17 and up.  In my tool change script, if any tool is greater than 16, it goes into manual mode.  Is that not sufficient?

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 12, 2014, 04:14:16 PM
NOPE that is really old school where you have to physically edit the tool table every time you load the tool changer

Normally here i have a tool load of 136 tools in the tool crib AND in the tool table  where ALL the tools are defined. There is a place to link the tool # to the SLOT # in the TOOL TABLE.

The Tcall calls the slot number of the tool to be used. OR in the CASE that THAT tool is NOT in a defined tool slot it calls it directly from the tool table (manual TOOL change of a tool NOT in the tool changer)

To reload the tool change for each job is as simple as linking  the proper TOOL# to the correct TOOL SLOT#

 OPEN tool table and assign Slot#s to the tools you require for that job.  LOAD the tools into the proper slots and you are ready to go. ALSO the SLOT# entry is the FIRST in line of the tool table so that you do NOT have to tab al the way into the table just to change the slot#.

All you need to do to the tool table is add a n entry on each line for TOOL SLOT assigment( type in a Slot number) if there is NO slot assigment then Mach4 would KNOW to goto the tool# for the TOOL load.

Also on Program load you can push a button and it LIST all the TOOL# assigned to that program. That is so you can verify what you NEED and what you HAVE loaded are the same.

Just a thought, (;-) TP

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 12, 2014, 04:51:40 PM
HIYA STEVE we also need a tool table exporter so the tool table can be imported into the CAM program .  A simp0le comma delim file would be great and easy to deal with.

HECK while you are at it a tool table import /export feature would be best. Operators do it both ways.

Just a thought,(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 15, 2014, 12:06:30 AM
HIYA Steve could you consider rearranging the order of the tool table entry in the normal order that we enter data

TOOL#1     Diam , Description, Length, Wear Diam, wear Length

OR for future consideration of tool changers

TOOL#1     SLOT# , Diam , Description, Length, Wear Diam, Wear Length

IF you stand in front of a machine 10-12 hrs a day making it a little bit easier goes a LONG WAY

Just a thought, (;-) TP


Title: Re: Mach 4 Feature Request
Post by: BR549 on May 15, 2014, 12:27:19 AM
An Email alert would be nice.

In Mach3 we have an "email alert" (M3 call home) that emails you on ERROR or Program end.

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 15, 2014, 12:29:39 AM
A Load file from picture is nice at times. That is also a working Mach3 function that works VERY well with Sheetcam.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 15, 2014, 12:34:57 AM
A function for printing the tool table and fixture table.  OR just Export the table to a text file THEN we can print it in notepad from there. also the Test file could be imported into you CAM program.

Also an import function to import tool tables from CAM

Those are  working Mach3 functions as well.

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 15, 2014, 11:40:43 AM
HIYA Steve just so you know that I am not pulling on your leg here is a picture of the tool table and you can SEE it does have an entry for the Slot#. Then IF it has a value will link the Slot# to the Tool# without having to physically swap the tool and UPdate the values all the time.

Easy Peasy, (;-)TP
Title: Re: Mach 4 Feature Request
Post by: swarfboy on May 17, 2014, 11:20:34 AM
Mach 4 is missing "A-rotations enabled" so that rotary toolpaths can be properly backplot in the toolpath viewer.
Title: Re: Mach 4 Feature Request
Post by: swarfboy on May 17, 2014, 11:26:04 AM
"CV distance tolerance" and "stop CV on angles >" parameters are missing from mach4
Title: Re: Mach 4 Feature Request
Post by: ger21 on May 18, 2014, 10:50:48 AM
Any chance of allowing DRO's to be on top of the toolpath, or somehow embedded in the toolpath window?
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 18, 2014, 03:02:55 PM
Long ago Brian send down a screenset to test for Mach3 that HAD the xyza dros imbedded in the toolpath display, so I know it is possible, But will we get it Mach4 ??

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: shad71 on May 18, 2014, 04:28:48 PM
It would be great if  will add three very important functions for plasma cutting system.
1. Switch off possibility of THC Automatic voltage control (AVC) on the end of  cut and set the distanse to the end of cut.
2. Switch off AVC just before corner and switch it On after passing the corner.
3. Switch off AVC on holes with small radius.
For both function add software bool variable in Mach4 variables, for example bool THC_AVC and then if(THC_AVC == false) disable AVC else enable AVC
Thanks!
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 18, 2014, 05:37:52 PM
Those are Plasma functions that should be controlled at the CAM side. The machine side is just suppose to follow the gcode BUT without pauses in motion when Mcodes does switching.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Bodini on May 19, 2014, 01:25:56 PM
On compiling macros at startup: a bad macro should give an error message and not cause Mach hang forever. (don't ask me how I know about that ;-) ) 
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 19, 2014, 01:51:33 PM
OH,OH I know that one well.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: shad71 on May 19, 2014, 02:16:36 PM
Those are Plasma functions that should be controlled at the CAM side. The machine side is just suppose to follow the gcode BUT without pauses in motion when Mcodes does switching.

(;-) TP

It is really very difficult to do?
At the moment there is no possibility to set these points automatically in CAM, only manually. Imagine a program of thousands of parts on a sheet of metal and in every corner  the operator must set the switch-off AVC points  :'(.
This option would simplify the process of preparing programs and works.
Thanks!
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 19, 2014, 04:03:33 PM
Sorry but you are wrong it is VERY easy for the CAM post to determine what you need and ADD a corrective Call AUTOMATICALLY based on conditions.

No hand coding needed or required.

IF you are required to hand code these things you may want to consider a NEW cam.  SheetCam does a wonderfull job in these areas.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 19, 2014, 04:10:45 PM
On compiling macros at startup: a bad macro should give an error message and not cause Mach hang forever. (don't ask me how I know about that ;-) ) 

If you are talking about Lua, there is a selection to compile in one of the drop downs in the editor. I have learned to always compile before leaving the editor to get that satisfying  'Compile successful' (or something to that effect).
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 19, 2014, 04:20:30 PM
I have seen it COMPILE OK  in the editor and error (Lua error running chunk) on load in mach4.   Can't explain it but i have seen it here.

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: Bodini on May 19, 2014, 04:28:18 PM
I could be totally wrong but i think I read on this forum that a script has to be "wrapped in a function" in the macros folder.  when mach starts, mclua.mcc compiles all the macros (as functions, meaning that it reads them but does not do them).  then when you call the macro, it runs the function (probably totally wrong wording there but from one dummy to another, you get the point).  If your macro is not in function form then mach will run it right there on startup (put a message box in a script, not in a function, and see it for yourself).  as far as ive seen most macros that compiled and ran just fine in the lua editor will cause mach to stop right there (i suppose its in some infinite loop or something).  this was my laymans understanding of what i read on the forum so PLEASE correct me if i'm wrong! :-)

-Nick

ps- here we go talking about things when this thread is supposed to be for requests only.  >:( ::)  New 'mach hangs on loadup' thread anyone?
Title: Re: Mach 4 Feature Request
Post by: Ya-Nvr-No on May 19, 2014, 04:40:06 PM
That's the reason I posted, how to find and fix a xml file that does not load, happened to me more than once. PITA... but beat starting over.
Title: Re: Mach 4 Feature Request
Post by: shad71 on May 19, 2014, 05:07:10 PM
Sorry but you are wrong it is VERY easy for the CAM post to determine what you need and ADD a corrective Call AUTOMATICALLY based on conditions.

No hand coding needed or required.

IF you are required to hand code these things you may want to consider a NEW cam.  SheetCam does a wonderfull job in these areas.

(;-) TP

OK! It well be great if the machine side under Mach4 control is just suppose to follow the gcode BUT without pauses in motion when Mcodes does switching.
In Mach3 any M command will cause a pause in the motion if it comes in the cut path.
Now I'am  not using an M command. Necessary to me data I receive from Mach3 variables. But in Mach4 SDK I do not see any of these variables, and I'm interested in how to implement the desired function.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 19, 2014, 05:33:00 PM
I could be totally wrong but i think I read on this forum that a script has to be "wrapped in a function" in the macros folder.  when mach starts, mclua.mcc compiles all the macros (as functions, meaning that it reads them but does not do them).  then when you call the macro, it runs the function (probably totally wrong wording there but from one dummy to another, you get the point).  If your macro is not in function form then mach will run it right there on startup (put a message box in a script, not in a function, and see it for yourself).  as far as ive seen most macros that compiled and ran just fine in the lua editor will cause mach to stop right there (i suppose its in some infinite loop or something).  this was my laymans understanding of what i read on the forum so PLEASE correct me if i'm wrong! :-)

-Nick

ps- here we go talking about things when this thread is supposed to be for requests only.  >:( ::)  New 'mach hangs on loadup' thread anyone?

No need for a new thread. We went thru this at some length in a thread titled 'modbus' started by myself a short while ago. The developers were kind enough to participate and explained a lot of this exact topic in some detail.

Edit: You are on the right track, BTW with the function wrapping, but there is more to it. Explained well in the thread.
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 19, 2014, 10:47:33 PM
"OK! It well be great if the machine side under Mach4 control is just suppose to follow the gcode BUT without pauses in motion when Mcodes does switching.
In Mach3 any M command will cause a pause in the motion if it comes in the cut path.
Now I'am  not using an M command. Necessary to me data I receive from Mach3 variables. But in Mach4 SDK I do not see any of these variables, and I'm interested in how to implement the desired function."

It just means you are using the wrong approach to have it work WITHOUT pauses.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: shad71 on May 20, 2014, 03:51:13 AM
"OK! It well be great if the machine side under Mach4 control is just suppose to follow the gcode BUT without pauses in motion when Mcodes does switching.
In Mach3 any M command will cause a pause in the motion if it comes in the cut path.
Now I'am  not using an M command. Necessary to me data I receive from Mach3 variables. But in Mach4 SDK I do not see any of these variables, and I'm interested in how to implement the desired function."

It just means you are using the wrong approach to have it work WITHOUT pauses.

(;-) TP

Well, then do not tell me the right approach?
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 20, 2014, 10:18:43 PM
Mach4 NEEDS a dedicated Directory structure with EVERYTHING pointed to the correct Directory.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 23, 2014, 02:47:17 PM
Mach4 needs a Probe calibaration routine that when implemented will OFFSET the probe trip values based on the calibration results.  You run this routine every time you mount your probe. It requires the use of a simple ball and post OR a calibrated slip ring.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 23, 2014, 02:50:06 PM
Mach4 needs an alternant RPobe routine G31.15  G31.25 ?   where it probes into a trip then reverses back to the UNTRIP position and this will be the trip point.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 23, 2014, 06:58:57 PM
In the tool table could you make a table entry for TRT (tool Run Time Total accumalated run  time of tool) Each time the tool is called Mach4 could start a M3 (spindle on)timer that runs until the next tool change. Then add the time to the ToolTime slot in the tool table.

It would REALLY help with tool management and should be fairly simple to do.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 25, 2014, 12:28:26 AM
How about a sequencial serial number engraving function. Set a System #var to enter the current S/N.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: ger21 on May 25, 2014, 09:13:41 AM
In the toolpath window, is there any way to get the "Highlight and Past Move Color" to be more bold?

In Mach4, it's very difficult to see, regardless of the colors used. In Mach3, it's much easier to see.

Also, it would be nice if the toolpath move and rotate mouse buttons were the same as Mach3.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 25, 2014, 12:14:01 PM
In reading the various feature requests it becomes clear that there is some difference in how the developers and the users define 'feature'. The sampling is very small, statistically insignificant, but if you pick any 5 users, add the MACH developers and you could have 6 different 'favorite' or 'correct' methods to accomplish almost any processes.

Most of the 'features' requested thus far can be easily accomplished with the new far more powerful scripting. Adding a 'feature' via script has several advantages, the most fundamental of which is the fact that each programmer is free to take whatever path he/she chooses and users might have the benefit of choosing among several different scripts to accomplish the needed task.

Consider:

1) Most of the 'feature' requests thus far are doable in Lua.

2) Different programmers may have very different paths to get to the same place.

3) Skill set varies greatly among programmers as well as specific knowledge of CNC needs and wants.

4) A highly skilled programmer can make the system do whatever and however the users (customer) wants, provided the developers have provided access to the required data.

5) There are already a few programmers who demonstrate programming skills and knowledge of MACH4, so there should be no question that there will be many as discussion continues and particularly when documentation becomes available.


GENERAL SOLUTION:

Given these concepts, it occurs to me that there should be a thread for 'Script Request' in addition to Feature Request. Scriptable 'Features' posted here could be moved to that thread. Programmers will cruise the Script thread looking for interesting challenges, believe it!  Code will be posted and comments, corrections, additions and mods will be made by both programmers and users.

SPECIFIC NEEDS:

What I see as reasonable contributions by the MACH4 developers is to provide access to the data (obviously), but also to provide several 'User Fields' in any table used by the software.

Using the example of the mods requested thus far to the MACH4 tool table, all could be done with scripts, but it would be a PIA to have to create new tables and try to link and sync each record to a line in a MACH table. An 'advanced' option should reveal several script accessible 'User Data fields' in each record in the tool table. This would facilitate a programmer being able to store, recall and manipulate data that has a fixed association with a MACH4 var.

In my opinion, accumulating tool run time is not particularly useful, but in any case, the proper place for such a process to execute is within the tool changer control software (which is not part of MACH4). But whether any given 'feature' is useful or not, there need to be 'User Fields' in a data structure for use by scripts.
Title: Re: Mach 4 Feature Request
Post by: ger21 on May 25, 2014, 12:34:54 PM
The problem is that 99% of the users don't know what's "scriptable" and what's not.
If requested features can be added via Lua, can someone just point that out?
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 25, 2014, 01:48:14 PM
It should NOT be the responcibilty of USERS to have to learn LUA in order to create NORMAL CNC machine functions that are not in MAch4 . That is the developers job.

The USERS have enough on their plate just learning the CNC process.

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 25, 2014, 05:33:34 PM
The problem is that 99% of the users don't know what's "scriptable" and what's not.
If requested features can be added via Lua, can someone just point that out?
From my post: Scriptable 'Features' posted here could be moved to that thread.

My idea was that if a user posted a feature request here (which is the correct place to post) and what is being requested can be done with Lua (and therefor will get no traction with the MACH4 developers), rather than have it rejected or ignored, it could be moved to an appropriate thread where it could get the attention of Lua programmers looking for such projects.

The Developers might tag a request as 'scriptable' or someone else could be assigned to do that. I am not involved in the management or organization of this forum. I just provided the idea. The forum would need to execute on it.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 25, 2014, 06:21:39 PM
It should NOT be the responcibilty of USERS to have to learn LUA in order to create NORMAL CNC machine functions that are not in MAch4 . That is the developers job.

The USERS have enough on their plate just learning the CNC process.


That's your opinion and you're certainly entitled to it. My observation over the last few years since I first picked up MACH is a large body of users waiting, waiting, WAITING for stuff to get done or fixed. Not only in the MACH software, but also in the plug-ins for peripherals.

Modbus was broken when I first touched MACH3. It is still broken (in Mach3). The popular SmoothStepper board had significant issues that dragged on for years.

If that kind of track record is what you want repeated, then you are on the right course piling your wish list at the doorstep of the developers instead of being pro-active and looking for solutions.

The way you want certain things implemented is counter productive in my view. Doesn't make me right or wrong or you right or wrong. It just means that if MACH 4 is built the way you want it, others are going to be unhappy and vice versa.

I don't have a lot of time to cruise forums, but in the reading I have done here, it is clear that the methods that you want implemented are contested by others. Probing for example, would definitely be an eternal football for the developers if they accommodated your preferences. I am NOT saying you are wrong or 'they' are wrong. That does not matter. The point is that there are hot debates going on as to how to get from point A to point B on certain issues and to implement under those circumstances is guaranteed to make someone unhappy. The beauty of a powerful scripting capability is that YOU can have it the way YOU want it and so can the other guy.

I have to correct one thing; I did not offer any opinion of who's RESPONSIBILITY anything is. That is an academic argument that is not useful in getting off the dime. My purpose is to be pro-active and look for solutions. You know better than most that I am typically pretty cynical, and I do not agree with every track that MACH4 is on, but they HAVE provided tools that allow users to NOT BE STUCK WAITING for someone else to react to their pet issue.

Last point is that we have our hands on a demo version of a $200 HOBBY software and I suspect you are demanding that it have what you deem to be 'standard CNC Features' that are in very much higher end products. That's not realistic in my view. How many hobby users really have tool changers? Having written a tool changer controller, I would submit that ONLY within that environment is all of the data necessary to provide useful tracking and accumulations as you describe. I do not claim to be an expert from writing one tool changer control, but that is one more than you have written, I might imagine.  Tool tracking should properly be done in the tool changer software in my opinion. I would not want to be restricted to whatever MACH4 dictates, especially if it is modeled after a method that I disagree with. As I said previously, I WOULD like to see MACH4 contain user data fields indexed on the tool chart so that there is a convenient P.O. box for each tool where we can put and retrieve mail for that tool. That type of 'feature' is universal. It is a tool. Has to be done by the MACH4 developers.

All I am suggesting is to follow that course instead of waiting waiting WAITING for the developers to see things your way and implement what you want. Personally I would not want to see them do that because I disagree with the way you want certain things done. However, I have seen you working with another member here sorting thru the behaviors you want to see and him reacting to your suggestions. The fellow is willing to spend his time doing exactly the thing you are trying to get done. What a great resource!

You desire 'X' feature. Don't you think it would be great to have 4 or 5 different utilities to choose from, all of which do 'X' feature? I could write one, Poppabear could write one. From what I have seen it looks like Ya-Nvr-No could write one, and he seems willing to work with you.

All I am suggesting is that we take the approach of picking up the tools MACH4 has provided and build our own house . . or houses  . .  instead of setting up another waiting game as we have with MACH3.
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 25, 2014, 08:30:17 PM
What you  are preaching is EMC ism.

"IF you want something learn to program it yourself OR talk someone that can to do it to do it for you."

That very idea is why EMC is still dormat today.

That would be like HAAS coming out with a controller that ONLY did the G0,G1,G2,G3 and say if you want anythng else learn to program HAASeze and do it yourself.

Look around at all the OTHER controllers in this class they are all full featured CNC controllers AND provide all the NORMAL cnc functions that operators require to do their job. AND have ALL the buttons in place for you to use.

And notice I did not say DO anything motion controllers.

At this point Mach4 has "possibillties" and that is it.  How much better it becomes depends on HOW refined the Builders finish it out to. It could be another EMC and if you want it learn to program it,  or a new fully featured CNC controller that is ready to sling chips by industry standards.

I know which one I want/need/ will buy. (;-) NOW that is just experience from 35+ years of 10-12 hrs a day standing in front of a CNC machine  making  a living and still working with others to help THEM make a living. Notice I do not sell anything related to CNC. Just offer help for free(;-)

AS to Probing you are seriously miss informed on HOW it needs to work to be PRODUCTIVE. I have been there done that and have the tee shirt ,hat and special underwear with probing on a CNC machine.

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 25, 2014, 09:51:48 PM
What you  are preaching is EMC ism.

I'm not preaching anything, Terry. I have no dog in this fight and as you probably know, I can do my own programming to do whatever I please and however I please. I'm just trying to help, and that takes up my time, so don't MAKE me come over there and slap you ;)

Quote
That would be like HAAS coming out with a controller that ONLY did the G0,G1,G2,G3 and say if you want anythng else learn to program HAASeze and do it yourself.
Look around at all the OTHER controllers in this class they are all full featured CNC controllers AND provide all the NORMAL cnc functions that operators require to do their job. AND have ALL the buttons in place for you to use.

Reality check needed. for $200, you'd be lucky to get coffee and a donut from HAAS.

Quote
At this point Mach4 has "possibillties" and that is it.  How much better it becomes depends on HOW refined the Builders finish it out to. It could be another EMC and if you want it learn to program it,  or a new fully featured CNC controller that is ready to sling chips by industry standards.

I agree with your premise, but I think you miss the point. Your compare to HAAS is not valid. You pay big time for all of those buttons and the smarts behind those buttons.  It is unrealistic to expect a $200 HOBBY program to compete against a well financed professional level CNC from a very well experienced corporation. MACH4 comes in a self proclaimed Industrial version for a very significantly higher price. Having made that claim, it would be fair to compare HAAS to that level of MACH4.

In my view you ignore the biggest of the 'possibilities' that MACH4 comes with . . .  the MACH community. There are a lot of very talented people using MACH and many of them are willing to spend time advising and guiding these neophytes you seem to be concerned with. Is that available from HAAS for free . .  I think not.  

I can tell you with 99% certainty that what you want to accomplish can be done with scripts. Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.

You would agree that M3, M4, M5, M6 and others are part of what you label 'industry standard CNC', yes?   You also know that they are scripts, correct?

If I or any other programmer here wrote the code you are asking for and charged you say US $6,000 then you would have HAAS feature for HAAS pricing. AND you would not have to argue withy anyone over your choice of methodology. That seems fair to me.  My contention is that it is very likely that you could get that done for FREE here in the hobby community. It's like you are in the pool and you don't even realize you're wet. You have people helping you already, but it seems you don't acknowledge that.

Quote
I know which one I want/need/ will buy. (;-) NOW that is just experience from 35+ years of 10-12 hrs a day standing in front of a CNC machine  making  a living and still working with others to help THEM make a living. Notice I do not sell anything related to CNC. Just offer help for free(;-)

I do sell stuff related to CNC and anything that is proprietary to those products is not given away on hobby forums. But I do get help here occasionally and I do try to give back in kind. Everybody here helps for free. You and I are nothing special in that regard. I have about the same number of years experience as you, but I don't stand in from of machines. I design them. I was never an 'ivory tower' engineer. I was down on the floor bothering the machinists (pre CNC) to find out how things REALLY work. What is the ACTUAL process they had to go thru when I specified 'textbook safe' tolerances and finishes. Similarly, I would look to benefit from your years on the floor, but you have made some assumptions, I'm afraid, as to what is involved in getting you what you want.

It is not as complicated as you think. The way MACH4 is structured, you can have exactly what you want. AND you are literally swimming in the resources you need to get there.

Quote
AS to Probing you are seriously miss informed on HOW it needs to work to be PRODUCTIVE. I have been there done that and have the tee shirt ,hat and special underwear with probing on a CNC machine.

If you are trying to get a rise out of me . . fail. I never offered ANY opinion of how probing should work, so you're just talking out of your 'special underwear' with that comment. The point you completely missed is that it DOES NOT MATTER how you or I or Obama or anyone else thinks probing *should* work. The point is that with scripting, you can have probing work in whatever twisted unconventional and bizarre way you like.

Here is the question you should dwell on; If the developers of MACH4 provided your every wish, would you care if it was happening in a script? Would it surprise you to find out that MACH4 core is in all likelihood a long string of compiled functions probably not much different than the Lua scripts? C is C and flow is flow and structure is structure. I doubt the MACH4 boys reinvented programming.

Second question; do you think that the MACH4 developers have 35 years on the shop floor 'standing in front of a CNC machine' or are they dweebie propeller heads without a clue? You have a fixation against scripting for some reason. If that comes from some limited experience with MACH3's VB implementation, then it is understandable, but you need to realize that this is a new game.

I have some opinions about how MACH4 industrial is going to be marketed, but that's for a future thread. For now, the only way I can see MACH4 being completely screwed up is if there is as little emphasis put on quality documentation as there was with MACH3. It is an incredible lack of respect for peoples time to make them dig and dig and jump through hoops and experiment and beg, borrow and steal to get even the simplest tasks accomplished  . . all due to nonexistent docs. My hope is that MACH4 fares much better in that regard.

I am going to be writing my second ATC control software in the next few months. I would love to have your years of experience behind that effort. You would get a free copy for your efforts. I can make a normal version for me and a weirdness version for you, no problem. ;)  Just sayin'

 

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 25, 2014, 11:11:14 PM
 ::)  ::)  ;D

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 26, 2014, 03:34:44 PM
Now that I am thinking about ATC's again, I am curious about the recently requested 'features'.

What is the purpose of accumulating run time on a tool? The only thing that comes to mind it to predict tool wear, but simply accumulating run time is not going to be particularly useful I would think. Is that really all the high end machines do?  Accumulate run time?  ???

Wouldn't you need data about the material cut, the length and depth of cut, federate, RPM, and so on?

I started working on an Amp draw based predictor but I did not have time to pursue that feature for the first ATC effort due to schedule conflicts. I'll pick it up again for the next ATC, but it would be great to have some info on what's out there now and how it works.  As I said, I don't see how the run time alone is going to provide much useful info unless  the other variables are factored in.

My idea was to use data from an external predictor such as the CNC cookbook speed/feed calculator and enter (or retrieve directly from the software if Bob will allow that) the predicted HP requirement. The ATC software then monitors the actual load on the spindle motor in real time. If the spindle load exceeds the predicted level, then a warning is generated and stored so that the operator has a head's up to change the tool out.

As an alternative, as each NEW tool in introduced on a job, the spindle load could be recorded in a user field in the tool table (which is why I would like to see extra fields, even if they never display on the screen). As production progresses and the tool gets duller, the load increases. Breakpoints for each tool could be set by amount or percentage and a warning generated when the spindle load exceeds that threshold.

This feature also runs in 'reverse' in that you can set the desired amount of torque to be used with a particular tool and choose a warning or a fault if that threshold is exceeded. The motivation for that feature is a pile of broken taps. I would be happy to sacrifice a new tap by putting it in a scrap hole and ramping up the spindle torque until it snaps off. Then back of by some amount or percentage and input that into the system. When the tap dulls to that point, I would have the system fault . . which is mo' better than trying to dig the tap out without an EDM machine available.

All I would need from MACH4 (I think) would be the extra fields in the tool table. Curious though about what a wish list might look like as a follow on the ATC features requested earlier in this thread.    
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 26, 2014, 03:51:59 PM
HIYA Simpson, in the field machines normally run specific tooling for each material cut. Aluminum runs specific tooling, stainless runs specific tooling. If you abide by the Manf's specs as to chip loading the tool has a specific life at that load. The tool Life indicators ASSUME that you are running at that spec all the time you are cutting so the tool life is based on INCH of cut or can be cut time.  IF you are not running fully loaded you can rate YOUR tool life longer as experinece dictates.

It is normally a good "INDICATOR" of when to change out tools in production. COnditions can vary so can actual tool life

HAAS has a decent TLI. I think they have a manual on it as well

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 26, 2014, 04:05:44 PM
A short example of one of the features of Tool Life Management on a Haas.

http://atyourservice.haascnc.com/whats_new/haas-advanced-tool-management/
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 27, 2014, 03:27:03 AM
HIYA Simpson, in the field machines normally run specific tooling for each material cut. Aluminum runs specific tooling, stainless runs specific tooling. If you abide by the Manf's specs as to chip loading the tool has a specific life at that load. The tool Life indicators ASSUME that you are running at that spec all the time you are cutting so the tool life is based on INCH of cut or can be cut time.  IF you are not running fully loaded you can rate YOUR tool life longer as experinece dictates.

It is normally a good "INDICATOR" of when to change out tools in production. COnditions can vary so can actual tool life

HAAS has a decent TLI. I think they have a manual on it as well

OK, that totally makes sense.

However, even given the specialized tooling per material, it seems you would want (ideally) to only accumulate cutting time and not total run time. Does the HAAS (or equiv) CNC controller isolate the cutting passes or is there some average percentage that is applied?

Mach3 identified travel and traverse with different colors in the graphic window, but I don't know if that data is available in a readable var. If it is not, then a readable LENGTH OF TRAVEL SINCE LAST TOOL CHANGE var would be something to request from MACH4. Scripting is only as good as the data that is available to it, so making data available is a critical part of having truly extensible software. However, I am not inclined to sift thru dozens of undocumented calls and guess at which one might be the data I'm looking for, so this kind of stuff will have to wait for the docs to catch up.

In fact, it occurs to me that the tool change is a <insert evil music> script, so it should be relatively simple to pull not only the length of cut, but also the spindle RPM and feed rate and store those as well. Or perhaps calculate a 'total chip load' based on those factors and accumulate those numbers. That's getting a bit over my head as I don't know if that is a useful way to track tool life. You would be in a better position to comment on that or perhaps I could run it by Bob Warfield.

My pet project of course is tracking tap life. Rigid tapping is done via a macro on my setup. With MACH3 you can only pass a couple of params to a macro, but MACH4 has a boatload, so calling the macro with a specific tool number should be easily doable and the macro could poke the usage data into the accumulator field (user field) for that tool.

In fact, it occurs to me that data specific to tool type could be gathered to make the life prediction more accurate. Using the example of taps, since the macro 'knows' how deep the tap will go (it is one of the passed params), the accumulator can total the actual number of inches tapped which is a much better number than total run time. Mind you, I still believe spindle load is a better indicator , but (so far as I know) only high end industrial drive provide load data in real time, so for those who have hobby level servo drives or VFDs, this would be the BAM (best available method).

BTW, if this stuff is in the HAAS manual, feel free to tell me to RTFM. The link is added to my ref library, but I have not read it yet. But I will. This is an interesting topic.

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 27, 2014, 11:10:50 AM
HIYA Simpson, A lot of controllers have a version of the TLM even lower end controllers (FlashCut as just one example). In the Haas version you have a menu to select the type on wear function you plan to use for each tool .  Be in cut inches, #holes drilled # tapped holes,etc,etc.  

In the industrial scene you rarely cut much air (can't afford to) so to base it on cut time does work out well.  AND for the most part it IS part magic.  To work well you start with your TOOL manf recomendations as to tool life UNTIL you collect enough of your OWN data to make adjustments.

AND yes there are ones that use load parameters as well as heat sensors,rpm,chipload, etc. You can have whatever you want you just have to want/need it bad enough to pay for it(;-).

In the Haas version you can also spec out replacement tools in the ATC so when TOOL#1 gets to the service life it automatically switch over to use tool #101(same type tool) and carries on. I have seen machines that had tool changers to feed tool changers where the machine cut for weeks at a time .  

SO TLM is nothing new in the machining world. Heck I have a version that runs on a plasma machine to track consumables and it also gives out the average CO$T per CutTimeUnit of the electrode , nozzle.

You can ALSO use your CAM to help track CUT units. SheetCAm does a great job with that. It transfers the Cut data into Mach3 though the Gcode #vars and we pick it UP from there and process it as we please.

In TLM there ARE many options to play with.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: stirling on May 27, 2014, 01:34:28 PM
For now, the only way I can see MACH4 being completely screwed up is if there is as little emphasis put on quality documentation as there was with MACH3. It is an incredible lack of respect for peoples time to make them dig and dig and jump through hoops and experiment and beg, borrow and steal to get even the simplest tasks accomplished  . . all due to nonexistent docs. My hope is that MACH4 fares much better in that regard.

IMHO the importance of this statement can not be over emphasized.

Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.

Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 27, 2014, 01:55:54 PM
HIYA Simpson, A lot of controllers have a version of the TLM even lower end controllers (FlashCut as just one example).
<snip>
This is great info. Thanks for the explanations.

Quote

In TLM there ARE many options to play with.


Well, hold that though because is speaks to my original premise; that MACH4 can be the 'Burger King' of CNC. i.e. 'Have it Your Way'!.

The notion that you are getting an incomplete piece of software that you have to 'finish yourself' would be a very unsettling prospect for users who are not programmers. I get that.  AND unfortunately the MACH marketing team, if there even is such a thing seems to specialize in shooting themselves in the foot, so I would not hold my breath for participation by the developers in any incentives to stimulate the community in producing these needed utilities and scripted features.

Providing a chain saw to a remote village is a noble act, but if the villagers have no idea how to use it and no gas to run it, really you have not accomplished anything useful.  So they have this great tool with massive capabilities, but while they are waiting waiting waiting for someone to bring some gas and show them how to use it, it just sits and gets rusty. It will be unfortunate if MACH4 takes this path. After all the work put into this project, it would be a shame if the result is moving from providing broken tools that are difficult or impossible to use to providing GREAT tools . . . .  that are difficult or impossible to use.









Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 27, 2014, 02:35:04 PM
Quote

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?  

I grant that it was technically incorrect for me to state 'Lua is C' because to be literally accurate; it is a scripting language based on C. This is the statement made by the author of Lua and by the org that is maintaining and distributing Lua.

Portuguese and Spanish are not 'the same' language, but the languages of these neighboring countries has the same roots and persons speaking the languages can have a conversation . . . at least as well as an American and a Brit . .  both of whom claim to be speaking 'English' :P. Ever talk to a Bayou Cajun or someone from Rural Arkansas? Is that actually English?  Are you supposed to need subtitles for English speakers?  ???

There are currently 3 flavors of C and they are not compatible with each other, BUT, any C programmer can look at any of the code and clearly recognize it as C code. I was moaning about having to learn vet another new language to develop on top of MACH4 . . until I researched Lua. As soon as I saw the Lua code, I though "Hell, this is not so bad, just another flavor of C, no biggie."

Lua is scripting and it is designed to be embedded in apps, so you are correct in that it is not ACTUALLY 'C' or more accurately one of the official flavors of C, however, I disagree that comparing it to C is unlikely to produce anything useful. Who ever heard of Lua? My initial reaction was not uncommon. Had I known that Lua looks like C, walks like C and quacks like C, I would not have wasted all that good whining on it.  ;)


Title: Re: Mach 4 Feature Request
Post by: yahuie on May 27, 2014, 02:59:43 PM
I have followed the Mach4 threads for a while.  I don't have the expertise of either simpson36 or BR549, but I can see both of your viewpoints.  I can program and I plan on trying to make a contribution in that area, but I'd obviously prefer to get as many features without programming as possible.  I like both of simpson36's views that the community can contribute a lot of the features to Mach4 through scripting and that there needs to be good documentation.  Every programmer likes to develop features, and very few programmers like to develop docs.  How will documentation for the 'core' features and community contributed features be related?  The more tightly integrated they are, the better.  The current forum is great if  you post a problem and someone answers you.  It's not so great for trying to find the answer to your question by searching through previous posts.  It seems like an actively curated, organized wiki might be a good solution.  There should be multiple indexes organized based on different criteria.  This would allow a lot of the work for the documentation to be taken off the backs of the dev team.  The docs for the core functionality would be curated by the dev team or some other expert, the structure of the add on features could be curated by someone like simpson36, :) and the entries for the specific features could be curated by the feature creators.  Links could be made from the wiki to the forum.  I know this will take work to set up, but I think it would be worth the investment after the core functionality is set up. I would much prefer a solid but limited core with good documentation over having more core features without documentation.   I also think it needs to be as easy as possible to add the desired community-generated functionality to Mach4 from within Mach4. 
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 27, 2014, 03:57:47 PM
The docs for the core functionality would be curated by the dev team or some other expert, the structure of the add on features could be curated by someone like simpson36, :)
Appreciate the vote of confidence, but I am far too busy to contribute in this way. I am already spending a lot more time on this forum than I should, but in my opinion, there is a 'make or break' topic on the table (as it should be) re: documentation, so I'm trying to get my 2 cents worth in on the assumption that the developers are paying attention to this this thread.

Quote


I would much prefer a solid but limited core with good documentation over having more core features without documentation.


Can't agree more. The demo release is identified by the top developer as have an objective of 'letting people play with the screens'. Well, it take about 2 minutes to make a pretty button . . so if that satisfied the objective, then they have done a great job. Making the button do something useful is an entirely different matter and that feels like a rewind to the guessing game that was MACH3.

In my never-so-humble opinion, the great emphasis on fixing bugs at this point is misplaced. The emphasis should be placed on providing at least rudimentary documentation WHILE there are people available and willing to evaluate how the screens work in a manner that has some bearing on the usefulness of MACH4 as the foundation it has been hyped to be. I got Modbus going under TCP and finally got some data moving between my processor and MACH4. While I very much appreciated the help provided by the developers (and it would NOT have been possible without that help), the effort was just unjustifiably great for such a small fragment of accomplishment, and I have chosen not to continue evaluating MACH4 until there is enough docs that I am not literally wasting my time digging and guessing.

Riddle me this: how much actual impact would the eval process take if a particular bug gets fixed now or in two days. OK, how much actual impact would it have on the eval process if those two days were used to provide at least some crude useable documentation?

I was excited to have the opportunity to evaluate MACH4, but I have stopped. There are some big dogs around here who have contributed massively to MACH and are getting unhappy. The nasty part about that is the negative feelings are primarily due to misconceptions and it seems I am the only one trying to explain why MACH4 extensibility is actually a very good thing . . . but without the ability to provide an example without spending ridiculous amounts of time. It's getting old fast.

Quote


  I also think it needs to be as easy as possible to add the desired community-generated functionality to Mach4 from within Mach4. 


If MACH4 were my product, and was close to release, I would already have somebody assigned to this task full time. However, I don't see this happening and I for one would be happy to have some documentation instead. MACH4 looks really good and I'd be happy to evangelize for it, but not if amounts to selling snake oil. We need to be able to produce examples of what MACH4 extensibility can actually do. THAT is what will excite the skeptics and generate the buzz.

When some docs appear, I'll jump back on board, but for now I'm just collecting info on interesting topics and then adios.

Title: Re: Mach 4 Feature Request
Post by: smurph on May 27, 2014, 07:47:37 PM
Guys, we are simply not going to have API documentation until Mach 4 is done.  We already tried documenting it, spent nearly a whole month doing so, all to have it become totally useless because Mach 4 changed so much.  4 weeks blown to high heaven!  A lot of the changes have been based on your comments, suggestions, and feature requests.

But the docs that we did were really nice for the two weeks they were valid.

So docs will come in time.  And we are WELL aware that everyone wants them.  But we are not a 500 employee company.  We don't have someone to put on the documentation task full time, as bad as I wish it we were able to do so.  That and the fact that whomever it is that does the documentations will also need to be a C++ programmer.  So it will be Brian or myself doing the documentation.  BTW, I was the poor sap that did the month long documentation stint that became relegated to uselessness.  Has anyone else experienced working a solid month on something and having it all be for naught?  It is NOT cool.  Not at all.  :(

Which came first, the chicken or the egg?  All I can say is the guy developing the egg was pissed when the guy developing the chicken changed the chicken.  Or vice verse.  Even if it was the same guy developing both!

Steve
Title: Re: Mach 4 Feature Request
Post by: stirling on May 28, 2014, 08:38:05 AM
Quote

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?

You evidently don't understand what makes a SCRIPTING language a SCRIPTING language or you wouldn't need to ask that question. However, from the Lua site - Page 1 para 1.

Quote
Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection,

These are (some) FUNDAMENTAL language defining characteristics. Not ONE of them applies to C.

You evidently think similar syntax is THE defining factor in language comparison. You also evidently misunderstand the term "compile" in that you think "compile" automatically implies the target is machine code. It does not. As a scripting language it would not make sense to compile Lua to machine code.

any C programmer can look at any of the code and clearly recognize it as C code.

What a silly thing to say - I've been programming professionally in C (and many other languages) for over 30 years and I see Lua as Lua. Just as any C programmer looking at Java would see it as Java just as any C programmer looking at C# would see it as C#. Why do you assume that the whole world sees things as you do after your five minutes of exposure?

Who ever heard of Lua?

Literally thousands - if not hundreds of thousands of people who use it all the time. Why oh why do you think nothing exists until YOU'VE heard of it?

Lua looks like C, walks like C and quacks like C

On a dark night, to those who are not that familiar with ducks, it might LOOK like a duck but it most certainly does not WALK or QUACK anything like a duck.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 28, 2014, 11:01:09 AM
Quote

Simpson:
Lua is C and it is fast and unlike MACH3, MACH4 pre compiles all of the functions so it *should* be indistinguishable if a script or native code is running.
Sterling:
Lua is most definitely NOT C and to confuse or compare the two from this perspective is unlikely to produce anything useful.

What is the source of your information?

You evidently don't understand what makes a SCRIPTING language a SCRIPTING language or you wouldn't need to ask that question. However, from the Lua site - Page 1 para 1.

Quote
Lua is dynamically typed, runs by interpreting bytecode for a register-based virtual machine, and has automatic memory management with incremental garbage collection,

These are (some) FUNDAMENTAL language defining characteristics. Not ONE of them applies to C.

You evidently think similar syntax is THE defining factor in language comparison. You also evidently misunderstand the term "compile" in that you think "compile" automatically implies the target is machine code. It does not. As a scripting language it would not make sense to compile Lua to machine code.

any C programmer can look at any of the code and clearly recognize it as C code.

What a silly thing to say - I've been programming professionally in C (and many other languages) for over 30 years and I see Lua as Lua. Just as any C programmer looking at Java would see it as Java just as any C programmer looking at C# would see it as C#. Why do you assume that the whole world sees things as you do after your five minutes of exposure?

Who ever heard of Lua?

Literally thousands - if not hundreds of thousands of people who use it all the time. Why oh why do you think nothing exists until YOU'VE heard of it?

Lua looks like C, walks like C and quacks like C

On a dark night, to those who are not that familiar with ducks, it might LOOK like a duck but it most certainly does not WALK or QUACK anything like a duck.


You conveniently side stepped my contention that the author and org site refer to Lua as 'based on C' and instead launch into some esoteric definition of a scripting language. The line you quoted has to to with Lua being embedded . . which I already stated. I also already stated that you are CORRECT in that Lua is not LITERALLY yet another flavor of actual 'C'.  What more do you want? I don't understand what your rant is all about.  

You also have your own definition of 'compiled' which for some reason is only valid if the end result is machine code. Instead of educating me, you should be informing Lua and the MACH4 developers and anyone else who does not have your 30 years of experience and is using the term 'compiled' all over the place. Egad! What is wrong with these people?

On a dark night, for those not familiar with forums, it may seem that the alleged thousands of people who know all about a new scripting language has some relevance to this conversation. Your incorrect assertion that I somehow control what the 'WORLD' thinks is also irrelevant. I never said anything at all about the 'WORLD'. I have two words for you to contemplate: HOBBY FORUM followed by 'where people have posted that they are lamenting having to learn a 'new' language just to use MACH4.

You expanded this from a local forum to the 'WORLD' and from a genealized observation to an Uber Tech Debate that really has no bearing on MACH4  . . at all. Behaving  as if I purchased commercial time on CNN to spread some contrived self serving evil agenda is a bit over the top, don't you think? Geeze, get a grip.

You clearly also turned this into a personal attack. Very naughty, especially for a moderator. No soup for you!  :D

Let me recap what ACTAULLY happened; SOME members of a group that I belong to was lamenting what they perceived as a large learning curve to climb as part of a move to MACH4, namely Lua.

ALL I said was "Hey guys, not so bad, the part you see is like C"   I left out the part where I said "Except those of you 'hobby guys who are worried about learning a new language' and yet are also computer scientists who author entire scripting languages and write compilers. For YOU guys, LUA is very different."

Sorry I missed mentioning that last part and thanks for filling in the blanks. Now everyone has a clear picture of my ignorance and will not be swayed by my heretical ramblings.

If I promise to behave, and then you won't need to spend so much time critically evaluating every word I post, could you then possibly put those 30 years of professional C experience to good use by writing some freaking documentation for MACH4?  Pretty please. I'll be good, I promise.
Title: Re: Mach 4 Feature Request
Post by: stirling on May 28, 2014, 11:47:43 AM
You sir, are as slippery as an eel - changing your argument as you go and making out that's what you said in the first place. I quoted the bit that I disagreed with - nothing more - nothing less. I'm not going to follow you around the block as you pretend you said something else and worse, pretend I said things that I didn't.

As far as a personal attack is concerned - I don't recognise that at all. could it be that that's just the way YOU see it whenever anyone has the bare faced cheek to disagree with you?
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 28, 2014, 11:50:58 AM
Guys, we are simply not going to have API documentation until Mach 4 is done.  We already tried documenting it, spent nearly a whole month doing so, all to have it become totally useless because Mach 4 changed so much.  4 weeks blown to high heaven!  A lot of the changes have been based on your comments, suggestions, and feature requests.

But the docs that we did were really nice for the two weeks they were valid.


It a little difficult to understand how MACH4 could change so drastically this late in the game when MACH3 has existed for so long. It not like the topic was new and unfamiliar. Just sayin'

There are a couple of hundred calls that are just in a list. All of these changed? Can we get a one sentence description at least of the ones that are less-than-self-explanatory?

Specifically can we get USER FIELDS added to the tool table or other data structures for use by Lua scripts to do clever and amazing things?

Quote

So docs will come in time.  And we are WELL aware that everyone wants them.  But we are not a 500 employee company.  We don't have someone to put on the documentation task full time, as bad as I wish it we were able to do so.  That and the fact that whomever it is that does the documentations will also need to be a C++ programmer.  So it will be Brian or myself doing the documentation.

Just as a suggestion, you might consider that the skill set for documentation writing is different from Technical expertise. Being able to put a complex process into layman's terms is what is needed, methinks. At least for the hobby version. This typically involves the skilled use of analogy.

You hired my friend Ray Livingston to write the desperately needed programmer's reference for MACH3. Prior to that document being produced, MACH3 was nearly impossible to comprehend . . at least for me.

Why can't you guys hire Pappabear or other qualified person to get something moving?

This is the fear: the reality is that there will always be bugs. There will always be new features to add. When will this time materialize to concentrate on documentation . . .  I mean realistically?

You guys are programmers. Writing docs is about like being poked in the eye with a sharp stick. I got that clearly from you comments where 'well I REALLY ENJOYED my 4 weeks writing documentation, but it is unusable, so I get to do it AGAIN . .yippee!  . .  was missing from the paragraph.

No need to preach to the choir . . I hate writing docs. I'd rather do dishes than write docs.

Quote

BTW, I was the poor sap that did the month long documentation stint that became relegated to uselessness.  Has anyone else experienced working a solid month on something and having it all be for naught?  It is NOT cool.  Not at all.  :(


You definitely don't want to live in my world. Proof of concept, cost/benefit analysis, failure analysis, etc, can take a long time and often result in the decision to abandon a project. I guess it is debatable if that constitutes 'for naught'. My criteria is 'did I get paid for the work'. If yes, then no harm no foul. If no, then I picked the wrong horse . . or chicken in this case, I suppose.

Quote

Which came first, the chicken or the egg?  All I can say is the guy developing the egg was pissed when the guy developing the chicken changed the chicken.  Or vice verse.  Even if it was the same guy developing both!


Unless the Chicken Change was adding a live birth feature . . . in which case the whole egg issue was for naught . . . typically right after I finally designed a perfect award winning egg.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 28, 2014, 12:01:39 PM
You sir, are as slippery as an eel - changing your argument as you go and making out that's what you said in the first place. I quoted the bit that I disagreed with - nothing more - nothing less. I'm not going to follow you around the block as you pretend you said something else and worse, pretend I said things that I didn't.

This nonsense is not as important to me as you may think. I would rather talk about something useful. Can't you do that even if you don't like me?

Quote

As far as a personal attack is concerned - I don't recognise that at all. could it be that that's just the way YOU see it whenever anyone has the bare faced cheek to disagree with you?


"This is not a PERSONAL attack, its just that I don't like the way YOU see things!"

Too funny.

You are mistaken. I like it when people disagree with me because that makes for a good debate. A debate is intellectual. You ignore facts and focus on personalities. That's an argument, not a debate. You'll have to sit in that sandbox by yourself, I'm afraid.

Bye now!  :D
Title: Re: Mach 4 Feature Request
Post by: smurph on May 28, 2014, 05:18:25 PM
We picked LUA because it was the fastest script language available.  And it was written in C which means it is portable and can run on any platform that has a C compiler.  We looked at Python because it seems so popular.  But it was rather slow when compared to LUA.  I don't like the "looks" of LUA very much.  It is true that it does have some C constructs.  But it also has some BASIC like elements to it as well.  And then it has some stuff that really can't be labeled as being like anything else on the planet!  It is bizarre in a lot of ways.  But it is fast and powerful.  The next best thing to true compiled code. 

I wanted to use AngelScript, which is more C like in syntax.  It was pretty fast too.  Not as fast as LUA, but it was faster than Python.  But with AngelScript, we would have had to write all of the wxWidgets bindings and that would have been a real pain.  Plus LUA is so versatile as far as embedding it was concerned.  So LUA won the script battles.

Steve
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 29, 2014, 06:09:08 AM
I don't like the "looks" of LUA very much.  It is true that it does have some C constructs.  But it also has some BASIC like elements to it as well.  And then it has some stuff that really can't be labeled as being like anything else on the planet!  It is bizarre in a lot of ways.  But it is fast and powerful.  The next best thing to true compiled code.

Seems the choice of Lua was well studied. My initial comment on MACH4 was that it is fast. Later, I commented that running a Lua script is indistinguishable from native code. Your comments support that contention. Granted, it is subjective, but it is I my impression none the less. In any case, you don't need a test lab or even a stop watch to tell the difference between VB and Lua.

Having a good portion of 'geek' and 'propeller head' in my DNA, what goes on 'under the hood' is interesting to me, but a lot of dialogue dwelling on the differences only feeds the perception that Lua is 'new' and scary.

The typical user who develops or just dabbles with scripting in Mach4 will be blissfully unaware of the tech details of how and where Lua is connected to MACH4 or the OS. I use C# mostly and while the syntax is different here and there, the structure is similar and the code that a USER sees . . . looks like C     at least it doers to me.  i.e. NOT scary.

General support for the base Lua language is excellent with a programmers reference available on-line for less than US$25 and there is an org site specifically for maintaining and distributing the software. For anyone familiar with C, the Lua learning curve is like an hour.  That's my story and I'm stickin' to it.   
 

So, do we get USER FIELDS or not?

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 29, 2014, 02:25:24 PM
I say just let THEM add teh tool life management and Tool changer stuff. THAT way we know it is integrated correctly (;-)

AND THAT is the rest of the story, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 29, 2014, 06:30:15 PM
Cylindrical mapping would be nice,  :o  We had it in MAch3  >:D

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 29, 2014, 10:38:57 PM
Tool Length measurement function  Gcode or Mcode .

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 29, 2014, 11:01:06 PM
I say just let THEM add teh tool life management and Tool changer stuff. THAT way we know it is integrated correctly (;-)

AND THAT is the rest of the story, (;-) TP

The rest of the story is more bug fixes and then initial release. This little demo release is not going to be anything like the actual release. There will be a flood of bug fixes and support issues all while trying to get MACH4 industrial version completed and released. Then more bug fixes for that as well as contractual support obligations for the buyers, another flood of bug fixes for the industrial version. Consequential damages in some states, regardless of what the contract states. It will only take one of these and MACH will be frozen in time.

Two or three guys who insist on wearing all of the hats. Documentation has always been an afterthought with low or zero priority and that does look like it will change. Realistically, I see unfinished fragments scattered all over the place. After a year of this, users will start to pieces together collections scraped together from all over and maybe two years later someone other than the developers will put together a programmers reference.

There is a flurry of activity right now on bug fixes. Once the focus shift to MACH4 indusrtrial, I wager MACH4 hobby will enjoy the same leper treatment that has been given MACH3 for a long time now. ,

Tool life management and ATC . . . in the industrial version . .  maybe in a couple of years unless a very major buyer demands it. In the hobby version . . .  never.

For the last few years the excuse for ignoring MACH3 was work on MACH4. The excuse for ignoring MACH4 hobby will be MACH4 industrial. I would probably buy MACH4 industrial for US$ 1000 in a heartbeat, but I would not be able to recommend anyone sign a support contract with these guys. Their track record is dismal at best and there is no sign that will change.

As time passes, it becomes more clear to me that this demo release is all about the users giving the developers what they want . . . not the other way around.  Your feature requests make for interesting challenges that would dovetail nicely into my upcoming projects, but It will just be an exercise in frustration without support from the MACH4 team.

I jumped in here to eval MACH4. I think I have the answers I was looking for, so it is time to unsubscribe  here and get back to my projects. I will likely stay with an external processor or investigate running the new code on a Kflop.

You can wait for your features to be added by the MACH3 team.  Hope you are not in a hurry . . .   
Title: Re: Mach 4 Feature Request
Post by: smurph on May 29, 2014, 11:52:14 PM
Err...  not correct.  Mach4 is Mach4.  There is no difference between Hobby and Industrial, code wise.  The only difference is the license.  The Industrial license "turns on" Industrial features.  But the code base is the same.  That demo version has the capability of running 6 planners.  But since there is no license, it only runs in demo mode with only 1 planner.

The API documentation will come.  I write good API docs.  I just can't write them at the same time I'm developing.  It turns out that I need two hands on one keyboard at a time.  :)

We don't have the resources to not wear many hats.  I guess we could go out and hire 5 to 10 more people.  But the price of the software would go up.

And what's with the ATC?  My machine has an ATC and it works fine.  The m6 macro handles it.  The m6 that is in the demo is just that, a demo.  Or am I missing something?

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 12:39:24 AM
I was hoping for a modern tool table with Tool changer support built in. Each tool that was IN the TC you assign it a slot number and the M6 calls the slot# OR if there is no slot# assigned top that tool  then call the TOOL #(For a manual change out.

THat way you load all the tools into the tool table then assign the tools you need in the TC a SLOT#

easy peasy  for the operator

Also 2 more tool table inputs     ToolLifeHRS   ,   ToolUsageHRS  Used for tracking usage and tool Life Management To be developed later on or by user

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: simpson36 on May 30, 2014, 08:44:45 AM
I have already unsubscribed from the MACH4 threads, but Terry's last post sneaked thru and I could not resist. I do feel compelled to respond to this post. Hopefully it wont be 'for naught', but in any case this is the last amount of time I will spend on this topic.


Err...  not correct.  Mach4 is Mach4.  There is no difference between Hobby and Industrial, code wise.  The only difference is the license.  The Industrial license "turns on" Industrial features.  But the code base is the same.  That demo version has the capability of running 6 planners.  But since there is no license, it only runs in demo mode with only 1 planner.
Steve, what you just said in essence is 'they are the same except they are different'. I did not say anything about how you have structured MACH4 internally between the hobby and industrial versions, or what the differences are technically so I can't be correct of incorrect on that score. That whole conversation is irrelevant to my point, or more accurately my gripe.

My comment was about support. That your attention, focus, priorities, two hands and keyboard will be consumed by Mach4 industrial which will roll out after Hobby as per the last published plan that I am aware of.  If it shares the same core, then it has the same bugs and holes that we are seeing now in the demo. PLUS, when the license 'turns on those complex new capabilities, are you expecting them to come on-line, hit the field and work perfectly?  If that happens, then maybe we'll see some documentation.

Look, I'm not just trying to bust your stones over this. I WANT to use MACH4. I want to require my buyers to use MACH4.  My intension is to be pro active and make helpful suggestions as to how you might address the lack of staff. I am not 'mad' because you don't act or react to those suggestions.  

You only have a couple of guys to do everything including make lunch and sweep the floor. Fine, I get that. The frustration is that you (not you personally, the entire MACH team) is not doing ANYTHING to effectively address that situation.  The concept of a 'virtual Corporation' had been around now for probably 20 years. You starve to death while walking thru an orchard.  

Beating the 'don't worry we'll get to it when we have time' drum is unrealistic.  You may as well say 'when we can fly' because the odds are about the same.    

Quote

The API documentation will come.  I write good API docs.  I just can't write them at the same time I'm developing.  It turns out that I need two hands on one keyboard at a time.  :)


Exactly.

So, how many hands and keyboard are needed for a yes or no on the USER FIELDS. As you know there is a fellow pounding on your door for high end tool changer features. Is that likely to happen? I'd wager NO. He does not program, but he is able to clearly and concisely describe the process and data he wants and can point to resources where 'industry standard' operation are described. So that part of the puzzle exists. I know that I can incorporate the code into my next ATC controller. I will need accessible data fields in each tool record inside MACH4. Last piece of the puzzle.

I have asked a couple of time now . . . Can I get USER DATA FIELDS . . . no answer.  Therefor can I even discuss this with any potential buyer . . no. Can I collect more data and start to make a plan and schedule, no. Not if I want to use MACH4 Why? Poor support from MACH4. Too busy fixing bugs now to think about MACH4's furture.  There is a saying about alligators and a swamp. If there is a different way to view this, I'd be happy to hear it.

Quote

We don't have the resources to not wear many hats.  I guess we could go out and hire 5 to 10 more people.  But the price of the software would go up.


Yes, I heard that. I get it.  Been there done that. Still doing it. But you folks are an uncreative bunch, I have to say. Did it never occur to you to charge for a programmer's reference?  I purchased the Lua programmers' ref in PDF for about $25. Hard copy I think is just under US $50.  The price point and sales strategy for MACH4 is a major marketing blunder, probably because that's yet another hat on the shelf awaiting enough time to materialize, but that's another conversation.

You can't charge for installation instructions or user guide. You certainly can charge for SDK, developers guide, programmers reference, etc.  That's my opinion. You could take a minute to be pro-active by taking a survey to see how many developers and high end users would be willing to pay for these documents. I'll go on record here and state that I will happily pay US$ 100 for a MACH4 'developer pack' or whatever you want to call it. If it can be bundles with competent and TIMELY support, then US$ 500

It's up to the MACH4 team how the set their priorities and do their marketing. I can only react to it. The ONLY solution presented so far is to wait until there is time to produce documentation. I have to decide if that means two months or never and plan accordingly as does every other developer.

There are people in the community very capable of producing these documents as was already PROVEN by Mr. Livingston on MACH3.  The payment could in all likelihood be tied to volume, release date, commission, or other means so that it is not out of pocket. The documents would not raise the price and in fact could throw off cash.

Free advice . . maybe worth what you paid for it, maybe more. In any case repeating 'When we have time' is not comforting because what I hear is 'not gonna happen' . The narcissistic attitude that ONLY members of the MACH4 team can write good docs is going to be an expensive luxury, I predict.  

Quote
And what's with the ATC?  My machine has an ATC and it works fine.  The m6 macro handles it.  The m6 that is in the demo is just that, a demo.  Or am I missing something?


Yes, you are missing the control for the ATC mechanism. There is a separate processor and several thousand lines of code in my first effort, and not all of the sensors are active yet, and one interlock is disabled because I have not gotten it to work reliably in all conditions. If you can get all of that into an M6 macro, then you are truly a master programmer.

And thanks for not getting all emotional over my sometimes poor delivery. It may not like a typical 'good ol boy - pat on the back - we're all pals here - lets have a beer' forum post, but I AM trying to be helpful. I will be looking at alternatives now, but still I hope you guys can get it together and not just produce another MACH3 with new paint.

So have a nice day and best of luck with the MACH4 rollouts.
Title: Re: Mach 4 Feature Request
Post by: Jeff_Birt on May 30, 2014, 10:14:10 AM
A couple of you guys seem to have lost sight of the fact that this is a BETA release, let me repeat that again "THIS IS A BETA RELEASE!". Your comments are now bordering on the absurd. A BETA release gives the advanced and/or curious user a sneak peak of a piece of software and allows them to ask questions and make suggestions. There have been good suggestions as a result of this, I think adding a slot number to the tool table makes sense for an industrial environment, that is an example of an excellent suggestion. I have also seen where folks found bad LUA bindings and asked questions like, "Hey how would I do this?" which can lead the programmers to say, "Oh! I can make that easier!"

BETA software by its very definition is NOT FINISHED and is NOT READY FOR RELEASE, i.e. it is in a state of flux and can and will change several more times before it is released. Writing user documentation when things are in a state of flux is not very productive as attested to by the very person who tried to do so.

Bitching and whining because a BETA RELEASE of a piece of software does not do 'function x' right now, exactly the way you think it should be done is childish. Remember a BETA release of a piece of software is like a physical prototype of a new device. It gives you a mostly workable platform for testing functionality and promotes new ideas. A prototype is never a completely finished product.
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 10:50:17 AM
SImpson I am a BIT more optomistic about Mach4. FIRST I look at the GCODE side. THAT is the MOST important PART of mach4 you can have. AND it works very very well and with just a few bug fixes it will be great. Mach4 NOW does every thing GCODE wise that one needs to have to do GOOD CNC work AT the HOBBY or industrial  LEVEL and this IS the hobby version we are playing with.

As to suggestions (;-) YOU ASKED FOR THEM SO YOU GET THEM.

Basically because as Steve said it is all one large package of code and the license sets the usage of the features.  In that line of thinking then YES it is going to need features created for industrial that most HOBBY users will never use BUT it still requires those features to be created.  AND also as STEVE said yo have NO IDEA how it will be used by the USERS. When you get people like me I will beat it 12 ways to Sunday JUST to see what it can and cannot do. There are as meany ways to do things as there are hairs on your head out in the real world. THAT is when you find all the ODDs things you never thing about people doing with it.

AND yes I am classed as ODD, no dought. BUT I also WILL get the job done one way or another.

The updates to the tool table WILL benifit BOTH sides as MORE AND MORE users are going to ATC as ATCs are being developed for the DIY side.

NOW My suggestions for the Tool table are to suport BOTH ATC and NON ATC users alike. The actual  ATC function code is normally done in ladder but COULD be done in LUA as there is NO dought that LUA is fast but is it integrated fully yet ????  I see a lot of errors go unchallenged and no error messages and no responce from Mach4 other than just crashing out. So yes there is a LOT of work ahead but I think it has started to go downhill now as things are getting fixed/improved.

Take the Mcode problem if it gets fixed properly(and it WILL get fixed) it will be NICE and very usefull. Most don't realize JUST how usefull that will be .  You will be able to create what amounts to you OWN Gcode canned cycle functions and have them available with a simple M202 call. The acutal MOTION code would be in SUB/macro format so it is EASY to support/change.  That is IF they get the Gcode Editor fixed so we can write gcode SUBS/MACROS easily. (;-)

Just a note a Tool changer program in ladder than runs the physical tool changer is NOT 10,000 lines of ladder code maybe 100-200 lines or more depending on the complexity of the tool changer.

As to the developement TIME frame I came into the MACH group about MIDWAY in. It was Art and friends doing ALL the work. I think we drove Art a bit crazy because he went at it like a mad man. (that is a good thing).  As to Mach4 and the available resources they are going to have to either spend at LOT of MONEY(hiring MORE people, not always a good thing)   OR spend a lot more TIME to get it all done.  AND yes time is money but you cannot preload a small company with TONS of developement dedt and expect it to survive in the long run.

I can also say without doubtt that the MACH group is the NICEST and MOST TALENTED group one could EVER hope to work with PERIOD.   SO far there is LITTLE in the MACH realm that they cannot create an ANSWER for to your problem about Mach3. I don't think Mach4 wiil be much different but there fewer Players now than before.

Bringing out a NEW CNC control today is NOT like when Art brought out MACH1/2/3 . Today there are MANY PC based CNC controllers that can DO the CNC CONTROLLER job as good or better than Mach3 and have more features to boot.

That is NOT saying that MACH4 should not be developed. Just that you have to look at things differently than we did in MACH3..

OnlY TIME will telll the REST of the story.  Just FIX the Gcode side bugs while you wait PLEASE.

(;-) TP



Title: Re: Mach 4 Feature Request
Post by: Brian Barker on May 30, 2014, 11:45:29 AM
Hello Guys,
I wanted you to know that we are nearing the end of the beta period and I am pleased with how it has gone. Thank you all for your input and comments.

I have Tom (the guy that did the Gcode manual) starting on the operation Manual for the default Mach4 screen. We will enhance some of the screen over time but for a first run I think it is a good start. When Tom is done with the manual I will have him look at working on the API / lua doc some... Tom is not a programmer but he is a damn fine engineer that can make a script work. Also we have an OEM working on making some nice Lua examples for everyone to use as a guide and or a platform to work from.

The webpage is getting worked on and when they are done I am going to have them make a place for Lua scripts that people would like to post. So you can have a holding bay for examples that people would like to share.

I know some of you are a little upset on how we are releasing the software and would like to see it finished with all docs and every features. Know this, we are following the plan we had set into motion over 2 years ago on how to release the software. So hang on.. this is a big project and we are doing as good as I could have ever hoped.

Thanks
Brian
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 12:11:12 PM
IN Mach3 we had a group of #vars that were cross linked to DROs. If you updated the #Var it updated the DRO, IF you updated the DRO it updated the #VAR.

IF Mach4 can do this NOW please explain HOW to do it.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Brian Barker on May 30, 2014, 12:14:15 PM
Use the register diagnostics dialog :)
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 02:21:36 PM
Example Please (;-)

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Brian Barker on May 30, 2014, 02:31:16 PM
As you can see you can do it here..

Thanks
Brian
Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 02:48:15 PM
Surely you jest. That is NOTHING as to what I asked.

On the screen there is a DRO(Dro18) I need to link it to update #var #590 with the value in the DRO. It should do the update WHEN I modify the DRO automatically. I see in the screen there are options as to allow that but I have no idea what the script should be like. "on update" I believe

ALSO IF I update #590 through a #590 =987654 then I need it to UPDATE the DRO on the screen(DRO18). AND there looks to be a function in the ScreenDRO to do that with script. "On Modify"
Title: Re: Mach 4 Feature Request
Post by: Brian Barker on May 30, 2014, 03:52:34 PM
That seems like a bad idea, Don't think it would be good to change the #vars as the poor machine is trying to use them. and that tells me you are only doing it to setup. in that case the reg thing would work for testing. I could be missing something..  Do tell what you are trying to do.

Title: Re: Mach 4 Feature Request
Post by: BR549 on May 30, 2014, 05:14:14 PM
So you really are a GSA(Giant Space Ant) that Scott talked of and you have taken over Brian's body and NOW you are stalling because you really don't know the answer to the question and you don't want anyone to know that you are really a GSA. HOW long ago did you escape from Area51 ? AND what did you do with Brian??

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: poppabear on May 30, 2014, 05:56:57 PM
Terry,

Place a "dro" on your screen, the User Dro you want, for this example Name it:  UDRO20 in its properties window.

then in a button, put this code:

   local inst = mc.mcGetInstance();
   local rc = 0;
   local MyVarVal = 0;
   local MyStgVal = "";

   MyVarVal, rc  = mc.mcCntlGetPoundVar(inst, 590);

   if rc ~= 0 then
      mc.mcSetMachError(inst, "get # err");
   else
      MyStgVal = tostring(MyVarVal);
      rc = scr.SetProperty('UDRO20', 'Value',  MyStgVal );--sets your UDRO to your Param value on the push
   end

--the opposite procedure would go the other way, load your User Dro to your param...
--further, if you want these two things to happen as mach runs automatically, drop them in the PLC scripter, but PLEASE make --sure they run without error before you do

--Scott

Simpson36,

     I did publish some down and dirty "User Manual" for McLua stuff............  while true I am not the "OEM" picked to do an official manual, it should serve to get ya started.

Scott
Title: Re: Mach 4 Feature Request
Post by: BR549 on June 01, 2014, 12:30:15 AM
WE NEED (;-)

Labels,  Label Code for Selected Tool Description

DROs ,  Diam Offset for Selected Tool

SAVE button , Save option for tool and Fixture tables (must Have)

Password LOCK to set Subs,macros, Gcodes to read only so they cannot be overwritten/changed by the red headed shop monkey .

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: BR549 on June 01, 2014, 01:34:25 AM
Things to consider for a NEW tool table.


Tool #  ,  Slot#,   Diam,   Height,   Flute#,  Type,  Desc, DiamWear,  HeightWear, ToolLife,  ToolTime,  %T_Life


Tool # = Tool #

Slot#  =  Position in Tool changer

Diam = Tool Diam

Height = Tool Height Offset

Flute# = # of flutes used for tool load calculations

Type = Type of Cutter used to bring up Picture of tool

Desc = General description of tool

ToolLife =   How long the tool will last in UNITS  Minutes, Holes drilled or tapped, etc

ToolTime = How long in UNITS has the tool ran sense installed

%T_Life  = what percent of tool Life is left


(;-) TP
Title: Re: Mach 4 Feature Request
Post by: pstenabaugh on June 13, 2014, 08:34:05 PM
Tool Path:

when scrolling through the tool path, there is no visual indicator of where the tool is located, on the graphic display.  This was available in mach 3, can this be added for Mach 4, it is really helpful when trying to optimize the g-code.
Title: Re: Mach 4 Feature Request
Post by: pstenabaugh on June 13, 2014, 08:38:55 PM
I use mach 3, and will be using Mach 4 to run lathe turning files since Mach turn is such a poor program and apparently is never going to be upgraded.  This works very well, however in the Mach configuration when I select the X-Z as the active plane, the selection reverts back to Y-Z every time, can this be fixed to stay as the X-Z plane.  Also when selecting the active plane, it would be really nice to have the graphic tool path display default to the same plane that is selected.  This eliminates the need to constantly rotate the tool path image to the correct orientation.
Title: Re: Mach 4 Feature Request
Post by: poppabear on July 17, 2014, 01:34:14 PM
Hi Steve,

    In the Modbus Plugin, could you make it where if you decide to use "Bit Packing", you could tick another box, that would make it where it would be "Little Indian" or LSB. Most of the PLC's I use do Little Indian, LSB, instead of the Modicon MSB......  It would sure make it easier not to have to flip everything around in the non-modicon PLC types.....

Smiley

Scott
Title: Re: Mach 4 Feature Request
Post by: cheech on August 08, 2014, 08:44:36 AM
HI,

One thing I'd like to see is extended CV settings.. So we could reallly fine tune the CV. I know there is quite a lot more that can be configured than mach3 lets us..

Also, please make sure that the Acceleration and deceleration during G1 are symmetric and not asymmetric like mach3. Perhaps if need be give the choice. I am all for a more configurable software... I don't care if it gets a bit techy. There are ways to hide the techy stuff.. perhaps gray out options.. warning messages....

keep having fun Brian and Guys..

Don't feel no pressure!

cheech
Title: Re: Mach 4 Feature Request
Post by: Kanadavos on August 10, 2014, 02:52:38 PM
I'd like Mach 4 Linux version to be able to run on the ARM architecture such as a raspberry pi or similar.  Mach4 + Raspberry pi + Ethernet Smoothstepper = low power, low heat (ie no cooling fans and no dust)

If the Raspberry pi is to low power to run mach4 on a single arm core, there are other arm systems such as the "CuBox i2 eX" (dual core) and "CuBox i4Pro" (quad core)avaiable on http://www.solid-run.com/products/cubox-i-mini-computer/ (http://www.solid-run.com/products/cubox-i-mini-computer/), There's also the Banana pi (dual core) http://www.bananapi.org/ (http://www.bananapi.org/)
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on August 18, 2014, 03:52:46 PM
Things to consider for a NEW tool table.


Tool #  ,  Slot#,   Diam,   Height,   Flute#,  Type,  Desc, DiamWear,  HeightWear, ToolLife,  ToolTime,  %T_Life


Tool # = Tool #

Slot#  =  Position in Tool changer

Diam = Tool Diam

Height = Tool Height Offset

Flute# = # of flutes used for tool load calculations

Type = Type of Cutter used to bring up Picture of tool

Desc = General description of tool

ToolLife =   How long the tool will last in UNITS  Minutes, Holes drilled or tapped, etc

ToolTime = How long in UNITS has the tool ran sense installed

%T_Life  = what percent of tool Life is left


(;-) TP


A tool were function would be great . Its the one thing when I worked with a Haas mini it had the mach didnt .
I would also like a Gear Wizard , with fourth axis g code generator. Your hobby users always build other automation equipment with timing pulleys . The cost of one isnt bad but when your allways buying them and changing them out it adds up.
Also chain gears or sprocket gears I know allot of us use them .
Food for though
Mark
Title: Re: Mach 4 Feature Request
Post by: ger21 on August 18, 2014, 03:58:51 PM

I would also like a Gear Wizard , with fourth axis g code generator.

Art, the author of Mach3, already wrote one. http://www.gearotic.com/
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on August 18, 2014, 05:14:27 PM
I seen that I was thinking of something alot more in depth .
 Have you ever used GearTrax from Camnetics?
Like that but in M4
http://www.camnetics.com/geartrax/geartrax2014screenshots.pdf
Title: Re: Mach 4 Feature Request
Post by: ger21 on August 18, 2014, 07:10:14 PM
No, I don't make gears.
So, you want the equivalent of a $1500 gear program included for free with a $150 program?
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on August 18, 2014, 07:38:57 PM
I never said make the add on for free . Camnetics isnt not 1500$ its a 1000$ (like bobcad its really even isnt that much priced high sold low) but also three separate programs come with that one suite that works with my solidworks.  Divide the worth of the three  how you want . That one program out of three does allot more than make gear also its more for cad work. But has no Gcode out put for 3 or 4 axis anything.
I know because I own the program.
On the flip side I never said copy the program camnetics , I was just asking for something with more variables . I think you read way to much into that.
So for the gear function thats 1/10th of camnetics  im looking for I though it was a reasonable request to look into. Just a thought
Title: Re: Mach 4 Feature Request
Post by: ger21 on August 18, 2014, 08:39:31 PM
Sorry.
Did you look at Gearotic? Try the demo, and see if it'll do what you want.

Unfortunately, gear software like that is incredibly complex. Art's been developing Gearotic for several years, and probably has thousands of hours into it. I doubt that you'll find anything more powerful without spending 10x as much.
Title: Re: Mach 4 Feature Request
Post by: Shamanj on August 19, 2014, 08:45:23 AM
Hi Macharoons...

I would really like to see a smooth interpretation algorythm for 4th axis machining.
http://www.machsupport.com/forum/index.php/topic,27856.0.html (http://www.machsupport.com/forum/index.php/topic,27856.0.html)
I posted earlier my code and have tried EVERYTHING. It's just "The way it is." However, on a Mazak/Haas/okky etc it would be a smooth wrap right around.
All i wanted to do was mill/face the outside of a cylinder!

No idea why, no idea why I'm having issues with my code, but what ever you do... make it intuitive.

Also, I love my auto tool changing doohickey with Mach3 2010, incorporate it! I'd be lost without it!
Title: Re: Mach 4 Feature Request
Post by: handsmfg on August 27, 2014, 02:56:43 AM
I would like to see a limits overide button like in Mach 3. When I land on my limits I can't jog off without deactivating them in Mach 4.

Eric

Title: Re: Mach 4 Feature Request
Post by: smurph on August 27, 2014, 07:34:24 PM
Limit override is simple.  Add a toggle button to the screen and tie it to the limit override output signal.  Done.  Or if you prefer a real switch on the panel, map it's I/O to the limit override INPUT signal.
Title: Re: Mach 4 Feature Request
Post by: Analias on August 29, 2014, 03:35:59 PM
Please modify the Lua Panels allowing developers to refer file name paths for the source of the panel.  This would allow developers to easily refer to a single source for embedded wizards. 

Currently Lua Panels need to have their implementation source code embedded in the Lua Panel.  If the source refers to an embedded wizard the developer has to cut-n-paste the wizard code into the Lua Panel.  Having the wizard code in an external .mcs file and inside the Lua Panel makes it difficult to maintain in two places.  A common best practice among developers is to only maintain a single copy of any code to avoid duplication and reduce code maintenance costs.  Extending the Lua Panel to allow it to refer to the external code path would allow developers to meet this ideal.


-Freeman
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on September 21, 2014, 08:09:54 PM
ger21
Is Mach4 closing the loop ? If not Im building a new system. Who has a real closed loop plugin? Meaning the software and hardware will adjust accordingly to get to the spot its supposed to be. Not just halt when there is a problem.
Title: Re: Mach 4 Feature Request
Post by: ger21 on September 21, 2014, 08:30:04 PM
I don't believe that Mach4 can operate like that, but I'm not the one to ask.
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on September 21, 2014, 11:49:46 PM
Im new with servos , so maybe im just wrong all together. I was under the assumption that how servos preformed under industrial applications.
Title: Re: Mach 4 Feature Request
Post by: smurph on September 22, 2014, 01:40:54 PM
Mach 4 has and never will close the servo loop.  It doesn't need to.

The loop can be close in three places:

1) The motion control software. (Mach does not do this.  Windows is not a real time OS).
2) The motion controller hardware.  (Galil, Vital System DSPMC, K-Flop, etc...)
3) The servo drive (Position controlled drives that take step/dir as input).

And we are talking servos here.  Steppers are generally never closed loop.

In the absence of #1 above, software never needs to close the loop.  The software can generate the motion profile without the loop being closed.  This is analogous to you in a car driving from your driveway to the stop sign down the street.  You plan your route (motion profile) before getting in your car (software).  Once in you car (hardware), it is your job to follow the planned route.  If you don't make it to the stop sign, you apply more throttle to get you there.  If you go past the stop sign, you put the car in reverse and apply throttle to get you there.  The end point didn't change and thus the route doesn't need to either. 

So if the loop is closed on the motion controller or servo drive, then there is no need for the software to close the loop. 

So to answer your question, any step/dir plugin that Mach4 supports will work with position controlled servo drives to close the loop.  Any plugin that Mach4 supports that closes the loop on the motion device will work with analog command controlled servo drives.

The Mach4/Galil combination running on my Matsuura MC500 is definitely closed loop.  It is using old school analog drives with PID filter on the Galil that manages the following error.  If you are retrofitting a machine with existing analog servo drives, using a plugin/controller that closes the loop on the controller is the way to go.

The newer and far more simple way is using position controlled drives.  Less tuning required as most of these type servo drive tune themselves.  If you are building a new machine or replacing the drives in an older machine in a retrofit, then this is the way to go.

When we were at IMTS, there were three machines demoing Mach4.  One used a Galil controller with Yaskawa EtherCat servo drives.  (Servo loop closed on the Galil).  Another used an ACS controller with Yaskawa EtherCat servo drives.  (Servo loop closed on the ASC controler).  And then another machine that used a Vital System HiCON controller outputting Step/Dir signals to Yaskawa position controlled servo drives.  (Servo loop closed on the drives).  All of these machines worked flawlessly.

We really had a good show at IMTS.  Mach Motion did a fine job!  The machine using the HiCON was running a SolidCam produced high speed pocketing tool path that was moving the machine @ 600 IPM.  It was simply amazing to watch a 3/16" end mill remove a 5/8" pocket depth of metal in 1018 steel in a matter of 3 minutes.  With precision!  Industrial?  I would emphatically say yes!  The Mach4 machine was capable of keeping up with the Hurco that was also demoing the SolidCam tool paths.  Yeah...  we had something to grin about.  :)

All of the Mach4 machines were running Mach4 Hobby.  How is that for you guys?  Hobby priced software that can keep up with the big boys!  Videos of the show will be forthcoming.  So stay tuned!

Steve
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on September 22, 2014, 02:31:50 PM
I was reading Kflop only halts when there is a fault but doesn't alter what ever it needs to to make sure it gets from point a to point b. Might as well stay with steppers in my opinion. I cant see pay that much more just to know I have a fault. I will look into galil though thanks.
Yes solidcams something else . I use 2014 daily. I cant believe some of the stuff its capable of doing in the time frame.
Title: Re: Mach 4 Feature Request
Post by: smurph on September 22, 2014, 03:49:28 PM
K-Flop can work in servo mode with K-Analog.  It has a PID loop.  The PID loop is what gets it to point B.  If the PID parameters are not correct (needs tuning) the following error will bee too great and then ANY controller will fault.  Even real-time OS based systems like EMC.  But with a proper PID setup, you will get to point B with K-Flop.  There is NOTHING that will guarantee hitting the numbers with an improperly tuned system.  

If you are interested in the K-Flop, talk to Tom.  He's a really nice guy.  He will tell you exactly what it will do and how to accomplish what you want to do.  Mind you, the K-flop is an advance controller with some amazing flexibility, so there is a bit of a learning curve with it.  But if I didn't already have Galil controllers, I would probably be using a K-Flop or a DSPMC.  Tom is working on the Mach4 plugin now.

There is nothing simple about setting up an analog servo system.  You either have experience with it or are faced with a steep learning curve.  That is why the newer drives also have position control modes.  It makes dealing with servos a lot more simple.  And usually cheaper too.  So if you are not faced with the task of re-using the analog controlled drives, use the position mode drives and a cheaper step/dir controller and call it done.

From what I saw at IMTS, SolidCam is the leader.  There are others that attempt to do what they do, but it just isn't in the same league.  It ain't cheap though.  But well worth it if you make your money with it.  It does require one hell of a machine to run it to it's full capabilities though.

Steve
Title: Re: Mach 4 Feature Request
Post by: mrich0908 on September 22, 2014, 04:07:56 PM
Steve ,
Thanks for clearing that up.
At this point Ive purchased nothing for the new system. So its all up in the air . Ive been reading allot about Kflop( obviously not understanding it all) that seems like the control I want .
The best part of solidcam in my eyes is as my machine changes or what ever type of automation I can dream up I , me myself can design a post processor that's capable of running it no matter what craziness I can think of . Sky's the limit. When the Gcode comes out its perfect as if as
Title: Re: Mach 4 Feature Request
Post by: Ya-Nvr-No on September 22, 2014, 05:16:09 PM
Its been over a week and I have been very surprised that this was the first IMTS has been mentioned.

I did not want to be the first, as wasn't sure it was my place. But have to agree with Steve. Machmotion had a strong presence  and some impressive setups and showings. I would advise if anyone is looking at upgrading to Mach4 and also a control upgrade to look seriously at Machmotion as their connection with Artsoft is very strong and you should have a good, to great transition.  Very professional and willing to help in any way.

Their screenset was very impressive (thou, at the time lacked a 4th axis). I'm sure by the first of the next year they will have a sweet system available.

 :D and no I'm not their spokesmen, just an outside observer.
Title: Re: Mach 4 Feature Request
Post by: smurph on September 22, 2014, 06:18:50 PM
We have been waiting a bit for MachMotion to get their show footage available.  When they do, I will link to it.  Want to see what Mach4 can do?  The guys at MachMotion have paved the way.  There were lots of jaw dropped stares in the SolidCam and Yaskawa booths.  Even the big boys came over to have a look.  It WAS impressive.  MachMotion did a first rate job.  But what else are you going to expect from a group of first rate guys?  :)

Steve
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on September 23, 2014, 08:00:07 AM
Is there any chance that 360 deg. rollover could be added for the A axis ?? (please)  :)

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: smurph on September 23, 2014, 02:19:07 PM
Brian is working on that right now.

Steve
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on September 24, 2014, 01:29:01 AM
Thank you Steve & Brian.  ;)

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: FocusPaul on September 26, 2014, 05:00:49 AM
Thank you Steve & Brian.  ;)

Tweakie.

I'd love to see this working on any axis, not only on axis A :)
Title: Re: Mach 4 Feature Request
Post by: poppabear on October 10, 2014, 02:42:52 PM
Hey Steve,

   In the Mach4 Screen designer, could you make it where we have to choice to change the color
of the Lua Panel from that ugly brown background only, to a choice of colors?

     OR!!! Even better have a "Transparent" option or the equivalent of it using what ever the background color is that it is sitting on.

Scott
Title: Re: Mach 4 Feature Request
Post by: smurph on October 10, 2014, 04:55:55 PM
Throw another panel on top and make it any color you want.

Transparent windows are not supported on all platforms.  :(

Steve
Title: Re: Mach 4 Feature Request
Post by: poppabear on October 10, 2014, 06:17:17 PM
ok, thanks that will work

Scott
Title: Re: Mach 4 Feature Request
Post by: poppabear on October 10, 2014, 07:56:43 PM
Hey Steve,

   I found an even easier solution the LuaPanel color problem, I just used the GetParent(), and then set the color of the
parent by setting the background color from the script.  I also tried using the GetBackgroundColour(), and the refreash() and ClearBackground() functions but for what ever reason even though I could see the Getbackground color coming in, it would not set it that way even with the refreash and/or clearBG funcs...

So, the solution was/is to just use the SetBackgroundColour(wxColor of your background), and it works, put this code,
at the top of the main, in the else panel section:

else
   panel = mcLuaPanelParent;
   local window = panel:GetParent();
   window:SetBackgroundColour(wx.wxColour(230, 230, 230));--use the same color bg as the panel sits on in screen designer
   window:ClearBackground();
   local wsize = window:GetSize();
   panel:SetSize(wsize);         
   panel:Connect(
          wx.wxEVT_CLOSE_WINDOW,
          function (event) 
               event:Skip();
          end);
end

Scott
Title: Re: Mach 4 Feature Request
Post by: poppabear on October 11, 2014, 12:55:23 AM
Steve,

window:SetWindowStyleFlag(wx.wxBORDER_NONE);    
window:Refresh();

will also make the sunken 3d boarder disappear so the lua panel become completely "invisible"
on the screen.

Scott
Title: Re: Mach 4 Feature Request
Post by: Analias on October 16, 2014, 01:11:00 AM
Would it be possible to specify having the menu bar hide itself when in full screen mode, and have it show when the user presses 'alt'?  This would allow maximum screen area to be available for use by mach 4 screens.

This is similar to several Windows apps that I know of.


-Freeman
Title: Re: Mach 4 Feature Request
Post by: pbarratt on November 16, 2014, 10:15:26 PM
I'm not sure where this request should go.  I have a USB pendant that works fine with Mach 3.  What do I need to get it to work with Mach 4?  I suspect I will need to write a script but I don't know where to start looking for functions.

Peter
Title: Re: Mach 4 Feature Request
Post by: BR549 on November 19, 2014, 09:54:59 AM
In the tool table AND the fixture offset table it would  be NICE if you could EXIT the tables without a mouse.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: peterc on November 20, 2014, 12:37:45 AM
On Mach3 there is a window that appears when the user tries to close the program that says something like "Are you sure you want to quit Mach3?".  Playing with the Mach4 demo it does not have this feature.
Kind of worried about closing a window by accident in the middle of a run. 
Title: Re: Mach 4 Feature Request
Post by: dude1 on November 20, 2014, 03:27:22 AM
it has it now
Title: Re: Mach 4 Feature Request
Post by: BR549 on November 22, 2014, 05:03:31 PM
Would it be possible to get TABBING to work correctly in Mach4. IF that worked correctly one would not need hotkeys and you could access most anything WITHOUT a mouse.

CTRL_TAB to move between main function groups
TAB / shift_tab to move inside of function groups

Still would be nice to have HotKeys working for button controls

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: dude1 on November 25, 2014, 05:13:54 AM
can more be added to M4 key mapper like what M3 has please

and can work hight probing be added to the next relise
Title: Re: Mach 4 Feature Request
Post by: BR549 on December 04, 2014, 10:27:40 PM
We need a on open /close script to open/close the Tool Table and FIxture Table from a PAGE.

Thanks (;-) TP
Title: Re: Mach 4 Feature Request
Post by: shad71 on December 05, 2014, 06:17:25 AM
It will be great to make the ArcOK signal input, THC ON/OFF button and add the macros for AVC control from Gcode without pause in motion for plasma cutting systems.
Thanks!!!
Title: Re: Mach 4 Feature Request
Post by: smurph on December 05, 2014, 12:34:55 PM
Terry, you can make a page and put the whole tool table on it, if desired.  And the same goes for the Fixtures.  Mach Motion did something similar.  It could be a LUA Wizard type of thing or just something DRO based.  Tabbing...  Probably not going to happen like you want.  The order of control creation has a lot to do with it, so you can kind of control your own destiny a bit there.  But then there is Z level which dictates that some controls be created before others.  It's a Windows thing and it is what it is.

sahd71, you can use any input for ArcOk, put a button on any screen for THC On/Off you desire, and control outputs with M62/M63 with no pause in motion.  M62 and M63 will work in the same manner as Linux CNC (replacing M10 and M11 in Mach 3).

daniellyall, the key mapper can be used to create any number off custom inputs that can be used in the PLC script to perform any action available in the API.  Not as simple as just connecting a key to a stock action, but it isn't THAT much harder to do.  The sky really is the limit.

The tools are there.  You guys can pretty much customize anything to your liking. 

Steve
Title: Re: Mach 4 Feature Request
Post by: shad71 on December 05, 2014, 12:43:38 PM
Thanks Steve!!!
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on December 05, 2014, 01:03:57 PM
Hi Steve,

Many thanks for dedicating the M62 / M63 commands, it is much appreciated.

Could  you please give me a clue as to how I turn ON / OFF an Output using the M62 / M63 commands. Obviously it is pretty simple but so far it alludes me.

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: shad71 on December 05, 2014, 01:34:22 PM
May be for example OUTPUT5:     w.SetSignalState(mc.OSIG_OUTPUT5,true) ?

Steve, I'am can't find the THC ON/OFF function for button. In mach3 I have the "Torch Toggle Button" for enable/disable THC function (no moveon X,Y and wait the ArcOK signal) and "SpindleCW,reset THC height" buttons for Torch ON/OFF.
And I think ArcOK == THCON input signal? It's correct?
Title: Re: Mach 4 Feature Request
Post by: smurph on December 05, 2014, 03:13:45 PM
Hi Steve,

Many thanks for dedicating the M62 / M63 commands, it is much appreciated.

Could  you please give me a clue as to how I turn ON / OFF an Output using the M62 / M63 commands. Obviously it is pretty simple but so far it alludes me.

Tweakie.

Ok...  

M62 P0

will set the output that is mapped to the Output #0 signal at the first movement after the M62.

So... this requires that a plugin output of some sort is mapped to the Output #0 signal.  That that is the first order of business that has to be taken care of.

Here is a simple example of the G code to drive it:

M62 P0 (turn on the output mapped to Output #0 signal at the next move)
M62 P1 (turn on the output mapped to Output #1 signal at the next move)
G01 X1 F30 (outputs 0 and 1 will activate at the beginning of this move)
M63 P0 (turn off the output mapped to Output #0 signal at the next move)
M63 P1 (turn off the output mapped to Output #1 signal at the next move)
G01 X1 (outputs off)

It is important to note that Mach is not turning the output signal on at any time.  It only uses the output signal to find the mapped plugin output.  The motion controller then turns this output on as a function of the movement.  This has implications as now something outside of Mach is really controlling the output.  Thus Mach will not know that the output is set because it is not the process that is actually setting it unless the motion plugin TELLS mach that the output it set.  Some do...  Some don't...

So the best thing to do is write G code that puts the output back into it's original state (as in the example above).

And to shad71's concerns, we plan on implementing something like "M66 Wait on Input" that will allow waiting on things like torch arc signals.

There is no THC on/off function.  You can create buttons do do whatever you desire.  These buttons would typically set outputs.  And do not that eventually we will have a separate interpreter for plasma machine that will be more tailored to their use.  For right now, we are concentrating on Mill and Lathe.  However, the Mill interpreter will support MOST of the things plasma machine need.

Steve
Title: Re: Mach 4 Feature Request
Post by: shad71 on December 05, 2014, 03:27:06 PM
Thanks Steve, now all is clear for me.
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on December 07, 2014, 03:26:31 AM
Thanks Steve - I am off to try it out.  ;D

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on December 07, 2014, 08:28:58 AM
Hi Steve,

This will interest you...

M62P6
G00 X10
M63P6
G00 X0

Turns ON and OFF Output#6 nicely  :)

However;

F300
M62P6
G01 X10
M63P6
G01 X0

Does not work for me  :'(

Basically the M62P6/M63P6 commands do not switch Output#6 ON or OFF when followed with a G01 move but they work just fine when followed with a G00 move  ???

(I am running Mach4-2138 with Darwin-2138 under WinXP).

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: smurph on December 07, 2014, 04:25:18 PM
I'll look at it and see.  It is supposed to be for feed moves only in the EMC definition.  But I also included rapid moves.  I thought it would be more flexible that way.  So it is at least nice to see that part of it working.  :)

Try a feed move/M62 combo first and see if it is a first case wins thing.

Steve
Title: Re: Mach 4 Feature Request
Post by: smurph on December 07, 2014, 07:15:13 PM
Tweakie,

I just looked at it.  The data is getting out to the plugins fine no matter what the movement type (rapid vs. feed).  So maybe it is a plugin issue?

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on December 07, 2014, 09:15:00 PM
It would be very usefull IF we could get the axis dros EMBEDDED into the toolpath.  Building a set of AXIS dros takes up a LOT of screen area.

ALSO it would be very usefull IF we could cut and paste GROUPS as a unit.

Thanks (;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on December 07, 2014, 10:23:55 PM
A group import of IMAGES would be VERY helpful .

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on December 07, 2014, 11:17:59 PM
Could you possible arrange the Button function selection window to be in alphabetical ORDER. AS IS it is random order


(;-) TP

Title: Re: Mach 4 Feature Request
Post by: dude1 on December 07, 2014, 11:23:40 PM
what about the Kitchen (http://en.wikipedia.org/wiki/Vance_Miller) sink as well lol
I thought you where going on holiday
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on December 08, 2014, 04:28:33 AM
Tweakie,

I just looked at it.  The data is getting out to the plugins fine no matter what the movement type (rapid vs. feed).  So maybe it is a plugin issue?

Steve

Hi Steve,

My apologies sir, it is indeed related to the plugin - there are just so many settings to get right and in my error I neglected to un-check the Arduino laser mode within Darwin.
With my error corrected the M62/M63 commands work perfectly with both feed-rate and rapid moves - once again my apologies for wasting your time with this issue (I will be eating humble pie for lunch & supper  :) )

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: BR549 on January 28, 2015, 12:37:08 AM
Could we PLEASE get a Printer option for the Gcode Editor AND the LUA editor.

Thanks (;-) TP
Title: Re: Mach 4 Feature Request
Post by: simpson36 on February 21, 2015, 08:41:25 AM
I guess this is the place to ask for features in the GC editor, so here we go:

1) The editor does not highlight the mating bracket when a bracket is floated over or selected. This is a handy feature for those of use who input long formulii.

I think this is the first editor I have seen short of notepad that doe not have this feature.

2) Replace should accept control codes; for example \n for newline and \t for tab and so on.

Again this is a feature of other editors, so it is hard to be without once you've come to rely on it.

3) Is there a way to select a different editor. I poked around, but did not see one.   
Title: Re: Mach 4 Feature Request
Post by: simpson36 on February 21, 2015, 08:44:04 AM
Could we PLEASE get a Printer option for the Gcode Editor AND the LUA editor.

Thanks (;-) TP

I asked this question in the previous post before I saw this one, but you may know the answer. Is there a way to choose a different default editor as there is in MACH3? If we can choose a different editor, it won't matter how bad the built in ones are.
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 11:39:09 AM
HIYA Steve as far as I know there is no option for a different Gcode editor. You do have an option for the PRO version of GCedit by buying a license.

There is a Youtuber somewhere showing the pro version.

I have even tried fooling Mach4 by renaming Notepad.exe to Gcedit.exe that was a no go as well. It knows the difference.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: patton on February 21, 2015, 11:52:24 AM
I went into the windows files and copied NOTEPAD.EXE then put it in the mach4hobby folder and renamed it to gcedit.exe and it brings up notepad as the editor now.

Dave
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 12:50:55 PM
Just tried it again here and NO GO. Probably a permissions deal with windows as I cannot run a copy of notepad.exe  from the desktop either(;-).

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: patton on February 21, 2015, 01:09:56 PM
It could be  if your on win7 or 8, I'm using winxp.

Dave
Title: Re: Mach 4 Feature Request
Post by: smurph on February 21, 2015, 02:19:42 PM
Yeah, you can buy a license for gcEdit and it turns on tool paths and some other features. 

I'm trying to think of a reason to use notepad instead of gcEdit and I just can't.  LOL  But waaaaaaay down on my list is making the editor changeable. 

Seve
Title: Re: Mach 4 Feature Request
Post by: simpson36 on February 21, 2015, 04:40:42 PM
Yeah, you can buy a license for gcedit and it turns on tool paths and some other features. 

I'm trying to think of a reason to use notepad instead of gcEdit and I just can't.  LOL  But waaaaaaay down on my list is making the editor changeable. 

Seve

Rather vague. Are the feature I specifically referenced 'turned on' in the pro version?whatever the fee is for a 'pro' or equiv version of gcedit, but only if it has the features that I want.

As to comparing gcedit and Notepad . .  nobrainer. On the other hand compare Notepad++ to gcedit . . .  once again  . no brainer . . just in the other direction.

Incidentally, I tried the hack mentioned by PATTON, except with Notepad ++ and it worked. More then just the primary .exe is needed and I don't know exactly what as I just copied the whole Notepad ++ directory and it worked fine after that. 

One last comment that will probably get me in trouble .  as usual . . is that sarcastic responses to users who are providing feedback as to what is needed in MACH is not going to win you any champions. Judging by recent developments at Tormach, you can't afford to loose to many more.

Whether you like the comments or not, people still spent their time to provide them and some respect for that time would be appropriate, methinks.

But that's just me . . . .   >:(



Title: Re: Mach 4 Feature Request
Post by: simpson36 on February 21, 2015, 04:43:27 PM
I went into the windows files and copied NOTEPAD.EXE then put it in the mach4hobby folder and renamed it to gcedit.exe and it brings up notepad as the editor now.

Dave

Brilliant.  :-*   Also works with Notepad ++. Free and far more capable version.
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 21, 2015, 05:35:00 PM
yes note pad why bother notepad++ correct its good.

its still up in the air if the new tormach controller is going to play well with older computers, for some people its going to be a big problem if it was me I would what a year before thinking if changing.

but I think M4 will be just as good or better its very good now for the basic functions it has I have not hit any snags yet that would stop me using M4 plus it has a laser controller whats a plus for M4.

I have had a look at useing the new version of luncnc I would put it in the hard basket there is so many thing you have to do to get it working that it`s probable it will take a day to just get it working so for some people it will be to hard.

M3/ M4 one hour and its working plus a lot of the hardware supplier`s are porting stuff over to work with M4.

and yes it would be good if in the next relise of M4 they would include tool height probing, a homing script that would move of the home switches thats all I would wont for now.
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 07:27:57 PM
It does NOT take much of a powerfull PC to work well with LinuxCNC it is NOT a resource hog. Now that they have a decent GUI front end it may be the next DIY controller.

KADOS to Greg @ Tormach

How well will it work . VERY WELL with the MESA line of cards.  Mach4 would do well to do the same thing adapt to the Mesa line of hardware. Top notch hardware at a reasonable price.

The first thing Mach4 needs is to be polished up for average JOE to use. there are many things missing yet ON SCREEN.

Just my Opinion, your's may differ (;-) TP



Title: Re: Mach 4 Feature Request
Post by: dude1 on February 21, 2015, 08:13:17 PM
yer I know all that but its still a hard program to set up most of it is over my head, I am dyslexic (I have a wearied version numbers and formulas look like nothing to me ) so most of look`s gobly gook to me.

there is no dedicated laser control, if there is I have not seen it.

the mesa card may be a good idea Brian can you please try or someone chime in (does it work with lua) can you give me the board number or model you think will work, I would like to read up on it I need to do something to get my big f`en machine working faster than 1250 mm/min
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 08:54:31 PM
The Pilot can be just as easy as Mach3 if they created a  GUI like Mach3 has. It does NOT " have" to be difficult to set up.

If there was a real NEED for the laser control there will be one. (;-) THE ONLY reason Mach4 darwin has it is because ART has 2 lasers to play with otherwise you would have NEVER seen it.

Title: Re: Mach 4 Feature Request
Post by: simpson36 on February 21, 2015, 10:10:24 PM
I feel compelled to comment that it is as reasonable to compare Tormach's new system to MACH4 as it is to compare stepper motors and servo motors . . and the same useless arguments would abound.

MAch4 is specifically designed to be extensible and allow users and developers access to the data and resources to use MACH as a base for not only routine CNC, but many other specialty applications.

Tormach, following their well documented edict of preventing users form even changing a single parameter, has done little more (from where I am viewing, and I have read all of their published propaganda on this new toy)  than taken one of many thousands of public domain softwares and modified it and if you buy the official spin, 'improved' it greatly. However, unlike most who engage in the intended spirit of public domain software, Tormach's modifications are not shared with the community from whence their 'invention' actually came, but have added self serving features specifically designed and intended to keep (exclusively) their own users out and reduce their support load by restricting what users can do with their own machines.

It took me 5 minutes to get into Tormach's 'locked' MACH3. Now perhaps they will be more successful at dictating what their users may and may not do, especially if they are successful in propagating the new master into the existing field.  Pilot is a means to an end.

With such vastly different objectives, making a direct comparison is akin to comparing a cow to an acorn.


Your mileage may vary . . . .  :'( 
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 21, 2015, 11:08:52 PM
as simpson says the old tormach controller did take 5 mins to break if everyone worked out how to do it I think it would have been better for all, I worked out how to do it to, it was to easy, change start icon that's all it was.
also the computer they used was not the best that`s why I said about changing over old tormach computers.

its a point I can prove if I could afford to (send computer`s to someone to confirm ), its as simple as this two machine same screen set same everything over than size, one machine never had a single problem with M3 the other was a  S___ head to use.

decide for fun to change computers around the machine that was a S___ head to use all problems went away machine that never had a problem became a good anchor.

so that means all problems could not be put down to M3 some if not all could be the computer that the machine was attached to.

I talked to a computer person about it what he said it would have been was the computers clock timing not keeping up for meany different reasons from ram speed, to hard drive being slow or even the graphic card being slow.

BR549
linuxcnc does not to be hard to install but it is there is so many different things you have to do its not funny of course the GUI different ones windows the other ones linux`s.

yes there would be no laser controller if art did not do it but it`s a big plus and it works very well on a program that is not finished.

it is a good reason to stick with M4 I have one router that's to small to be of any use to me its been in the corner for 3 years too now it will be able to do A4 size engravings so its going to be a laser engraver now.

also on the big machine I use I will put a laser engraver on it so pick`s or what ever can put on something if it`s required when doing a job so it`s going to be a 2 in 1 machine for less than $400.

so that's my reason for using M4 on those machines the other one its just going to be for a test to see if there is a improvement in its performances compered to M3 then M4 when it comes out its has a fault somewhere that I can suppress but not find.

BR549 art`s got more than 2 laser`s

it would be interesting to see if tormarches new controller can be unlocked to see if its the same as the new version of linuxcnc as its in beta the same as pathpoilt
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 11:20:02 PM
Steve you have never OWNED a real commercial CNC machine have you (;-) Most newer ones you cannot even MOVE that machine across the shop without having a Service man come back in to reset the alarm BIT so it will run again. They let you do NOTHING internally.

Greg at Tormach did exactly what he should be doing in "HIS" world . Locking the user out from the internals that they have little to no need to be tinkering with in there.  In that WORLD you have to protect the users from themselves AND protect the machine so it can be stable and the OEM can trouble shoot it.

NOW REMEMBER Tormach gave everyone the  option to UNLOCK the Mach3 machine so YOU could have at it. But at point you were on you OWN as to trouble shooting it WHEN you messed it up.  

The NEW Tormach unit is a dedicated CNC machine controller , Same as HAAS,OKUMA,MAZAK, etc,etc.( Just a smaller scale)  NOT a do everything motion thingy to make everyone happy.

IS there a market for both ??  Should be but the users base has shifted from days past. I see more and more DIYers sell the toys and buy small Commercial CNC machines new and used.  They would rather make things rather than TINKER on the machine.

Time will tell who's approach is best for the New CNC user generation(plug-n-CUT). This Generation is VERY different from the last one(;-)

Call Mazak and TELL them you want access to the internals of the Mazatrol and see what answer you get.  Bin there tried that as well (;-)

Just a thought, (;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 11:36:33 PM
Daniell, If Greg did his job, and he has been known to. The pilot will be as or easier to configure than Mach3. All you need is a GOOD User interface to make it easy. Instead of hving to program the Internal configs from a command line.

I HAVE a LinuxCNC  machine here. The Controller other than having a very HOMELY GUI works as it should. No unknow crashes,no broken PROBES, tools fixture, OR surpises in the middle of a job.  SO I know how Linux CNC works (;-)  It is the same MACHINE that I USED to have mach3 on for testing. A  Series1 CNC Bridgeport mill with 1kw ac servos. IT will sling chips all day long.

As to OEMS using the EMC source code to model from without providing THEIR source code. Art did not with Mach1/2/3, Eding did not, planet CNC did not, and all the others that used the EMC base code did not as well.

Just a thought, (;-) TP

Title: Re: Mach 4 Feature Request
Post by: ger21 on February 21, 2015, 11:39:36 PM
As to OEMS using the EMC source code to model from without providing THEIR source code. Art did not with Mach1/2/3, Eding did not, planet CNC did not, and all the others that used the EMC base code did not as well.


None of them released their own version of LinuxCNC.
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 21, 2015, 11:39:51 PM
that`s a bit different tormach is a hobby machine brand new controller not proven yet. (yes M4 the same but it`s a round and round and round yes once more round and round argument) people get what they wont if they wont to play they do if not you get something that help is a phone call away and a big bill. (;-)

the other one`s been around for how long you don't need to tinker with those ones you just upgrade.
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 21, 2015, 11:52:09 PM
Obviously Greg does not have a licensing problem with LinuxCNC. Could be because he PAID to have some of HIS version changed for him by the GROUP. Money talks(;-).

NOW will you see that CORE version show up in the free  LinuxCNC Yes you will soon. Will you be able to get the GUI interface( the part that makes it easy to use), Never happen unless Greg decides to SELL it to you.  Just good business sense from my standpoint. 

(;-) TP

Title: Re: Mach 4 Feature Request
Post by: dude1 on February 21, 2015, 11:56:46 PM
f___  BR549 I am a boy not a girl (:-)), I am not going to drop money on something that is not proven I will try to use the new linixcnc as a experiment between M3 and M4 to see what one can run the dud machine better.

the other one its a dream on M3 it will be changed to M4 when it fully finished because I wont a two in one.

linuxCNC may have come to an agreement with tormach that they will pay for the new version to be done if they cant have there own locked down version of the same thing who know`s.

linux is hard to set up yes the tormach version wont be they all the same machine one can do a fully set up install in one go with everything pre set nowen machine so thats a round and round again argument
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 12:17:56 AM
(;-) WHO said you were a girl??

YOU may be able to get the LinuxCNC core app BUT you cannot get the Pilot version Unless you either Upgrade a tormach machine OR buy a new machine.

They will NOT sell the unit outright, Already tried (;-).

The Pilot has been in beta now for well over a year working out the few bugs it had. Just few knew.

I am patiently waiting on M4 (;-) Still a Mach fan

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 22, 2015, 12:32:00 AM
boy daniel, girl daniell just taking the piss.

good to hear you still a Mach fan other wise I would get the men in white coat to take you away (:-)).
 
yer the difference between pilot and M4 is pilot went from an existing base, M4 nice and shiny so linuxCNC taken how long to get where it is im
Title: Re: Mach 4 Feature Request
Post by: smurph on February 22, 2015, 12:33:56 AM
Yeah, you can buy a license for gcedit and it turns on tool paths and some other features. 

I'm trying to think of a reason to use notepad instead of gcEdit and I just can't.  LOL  But waaaaaaay down on my list is making the editor changeable. 

Seve

Rather vague. Are the feature I specifically referenced 'turned on' in the pro version?whatever the fee is for a 'pro' or equiv version of gcedit, but only if it has the features that I want.

As to comparing gcedit and Notepad . .  nobrainer. On the other hand compare Notepad++ to gcedit . . .  once again  . no brainer . . just in the other direction.

Incidentally, I tried the hack mentioned by PATTON, except with Notepad ++ and it worked. More then just the primary .exe is needed and I don't know exactly what as I just copied the whole Notepad ++ directory and it worked fine after that. 

One last comment that will probably get me in trouble .  as usual . . is that sarcastic responses to users who are providing feedback as to what is needed in MACH is not going to win you any champions. Judging by recent developments at Tormach, you can't afford to loose to many more.

Whether you like the comments or not, people still spent their time to provide them and some respect for that time would be appropriate, methinks.

But that's just me . . . .   >:(

I was not vague.  Some of the other features are not finished yet.  The tool path is done.  But we really haven't promoted it at this point yet because we don't know what all we will add.  So if vague being that "I don't know what else at this point" then I guess so.

No one noticed the "LOL" in the comment?  Or was it just you?  It was not sarcasm for the sake of anything.  It was a joke.  That is how I am.  I like to joke around.  I'm a happy guy.  And I refuse to walk around on eggs shells just to keep from accidentally pissing someone off.  I will be the first to tell you that I'm not politically correct in any shape, form, or fashion.  It is not worth my time.  We have precious few minutes to live on this Earth to be wasting them on that kind of stuff. 

And I was trying to be honest too.  I have that "editor change feature" on my list.  But it is way down the list at the moment.  Nothing else meant at all. 

And now I find myself getting a lecture (on my birthday of all days) from someone that doesn't even bother to look at the editors and see if the other feature that you "specifically referenced" but are being "vague" about (by not mentioning it again) has been implemented.  It seems that you would rather just open up a forum and post Negative Nancy comments.  Thanks, but no thanks.  Just so as not to be vague, I'll throw it out there...  Printing.  It needed to be done.  It took me three weeks to get it in there.  I won't get paid a penny for it either as gcEdit is freely available in the Demo.  You are welcome!

For the rest of you that post constructive things, I want you to know that I spend MY time trying to make this software the best that it can possibly be.  I spend 12 or more hours every day doing that.  We listen to your requests and we try to get every one of them in there somehow within reason.  We are not going to cater to the 1% on anything though.  We are not going to write one person custom software that does EVERYTHING he wants it to do in a niche environment.  But yeah...  if it is something everyone will benefit from, we try to get it in there.  It just takes time.  Lots of it. 

Terry, to the point of the EMC source code ( a brief history ) :

LinuxCNC is nice.  It came from the original EMC code that National Institute of Standards and Technology (NIST) did.  NIST is a government agency that used our tax dollars for the project.  The code is public domain.  Meaning anyone could use/change it without having to give away the changes (Edin, planet CNC, etc...).  Public domain is like that.  That is why none of those OEMs, companies, or whatever do not have to release their source code.

Now, somehow someone decided to slap the GPL license on it at a later date.  How they could "re-license" something that had already been in the public domain is a point to ponder!!!  Personally, I don't think it was legal.  I have the original sources from NIST and it is clearly stated in the code that anyone can use it and that it is public domain.  This has been stripped and replaced with the GPL in the "new" zip file of the code.   The NIST code, not the LinuxCNC code.

Mach3 was derived from that original NIST code.  Many changes had to be made in order for it to work on the Windows platform.  One would be hard pressed to see any resemblance between the two code bases.  The interpreter would be recognizable and that is about it.   And the heart of Mach 3 was the parallel port code that was solely Art's baby.  Oh and let's not forget about the user interface, which was 100% Art.  And let me tell you that is the hardest part.  If it were easy, LinuxCNC would have the same thing already!  We don't use any of the NIST code anymore in Mach 4.

I had a machine running LinuxCNC.  I liked it.  But I'm a computer nerd.  And I also have the skills to change it and make it do my bidding.  Try asking the LinuxCNC group for a feature and see how far that gets you.  There is absolutely NO motivation to do it unless one of the LinuxCNC programmers wants to add it because it is useful for him/her.  That is the way of the open source world.  I know, as I used to program for OpenBSD.  Only we gave the code away completely!  No GPL.  OpenBSD license.  Much like the MIT license.  Free as in free and no strings attached.  Code that I worked on is swimming around in so many commercial products that I can't even begin to fathom how many companies use it.  My reward?  I know that my work has made many people's lives better.  Our motivation for adding needed features in Mach is being able to eat.  Yeah...  we are dirty capitalist that have families that have an affinity for food.  (There I go joking again...)

So for the people that are not C/C++ programmers, we offer Mach.  It is your choice on what to use. 

Steve
Title: Re: Mach 4 Feature Request
Post by: Steve Stallings on February 22, 2015, 12:39:32 AM
Tormach, EMC, LinuxCNC, Mach3, Mach4 etc.

EMC was developed by NIST, an agency of the government of the USA.

Most developments of US agencies, including EMC, are public domain.
They are not and may not be copyrighted. Anyone is free to use them
as they see fit.

The various versions of Mach, and many other CNC control systems are
derived from the public domain version of EMC.

Tormach's version of LinuxCNC is derived from LinuxCNC, which does
claim GPL copyright. Tormach has indicated that they intend to comply
with those GPL requirements. Indeed, some of the work that they sponsored,
updates to the trajectory planner, have already been integrated back
into the LinuxCNC repositories. Some other parts of their product, like
the PathPilot GUI, are possibly only partially covered by GPL. Tormach has
indicated that they want to contribute technology back to LinuxCNC but
wish to do so in a fashion such that other vendors cannot directly
copy their PathPilot GUI.

Tormach's other changes to the LinuxCNC code base may or may not be
integrated back into the main LinuxCNC repositories depending on how
the community feels about them. None the less, they will be available
under the terms of the GPL license.

Tormach is offering their implementation of LinuxCNC as a product that
is supported by them provided that you have purchased their equipment
and do not modify the software. If you utilize it on other hardware or
modify the software, then you must support yourself.

The Tormach implementation runs on a Linux distribution controlled by
Tormach and requires specific Mesa interface hardware to run. If you
want to design screens or write scripts, this is outside the realm of
things that Tormach will support. If you want to run on a different
distribution of Linux, you are on your own. Obviously it will not
run on a Windows based machine.

Mach4 is derived from prior versions of Mach and is a descendant of the
original EMC released by NIST. It runs on modern Windows machines and
can be extensively customized by both vendors and users.

LinuxCNC's motion control is tightly integrated with the real time
operating system and motion control devices must be able to communicate
with the operating system software in real time if you are using their
standard control model. This is possible in Tormach's case because the
Mesa hardware that they chose is plugged directly into the computer's
internal card slots.

The Mach family uses a looser integration of the motion controller, or
parallel port driver, with the operating system software. This allows
the use of external devices that communicate with USB or Ethernet and
which can tolerate communication delays of up to a couple of seconds.
Not that a delay that long is desirable. Vendors supporting Mach4 are
trying to shorten that delay as much a possible, perhaps to as little
as 1/10 of a second. Still, that requires that the motion control
device be intelligent and capable of responding to limits, probing,
threading and similar tasks itself rather than depending on the host
based software.

Windows cannot be relied upon to respond like a real time control
system. The parallel port drivers have effectively been a simple real
time operating systme which runs Windows as a task. This is becoming
nearly impossible with modern versions of Windows. No 64 bit versions of
Windows allow this, and the 32 bit version Windows 7 is the last one on
which a parallel port driver has been implemented successfully.

The Mesa hardware which Tormach is using requires real time management.
Because of this it is unlikely that a plug-in for Mach4 will be attempted.
It may be possible, but it would end up behaving like other motion devices
under Mach, ie. loosely coupled.

The jest of these observations is that Tormach's version of LinuxCNC and
Mach4 are really two different animals, each with their own place.

Regards,
Steve Stallings
www.PMDX.com
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 22, 2015, 12:47:56 AM
good words like don't like the 1% ever even tho I am a 5% person.

also thanks for doing 12 hours a day keep up the good work just make 7 day`s a.

now no more Linux ********* please.

 back on to M4 please can we have tool height probing in next relise please

Steve I think you just schooled everyone
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 01:02:25 AM
Dang Smurph IF I had known you were hungry I could have sent you a Big ol stake . What kind do you like Pine? Oak? Poplar? or some import mahogany. Teak ? ;D

As to the Mesa stuff, they run a processor similar to the ESS and the ESS does not have to have a realtime OS. It depends on WHICH mesa card you plan to run.  I have talked with Mesa about a Mach4 setup and they were not interested for some reason(;-) Same as for Mach3.

IF the USBSS and ESS can do it they should be able to do it as well The boards are programmable for use.

BUT that is why you Big Dawgs get the Big money (;-)

Thats a joke son, I say I say a joke son.  (Foghorn Leghorn)  :o

What ARE yall doing up so late anyway ??


(;-) TP

Title: Re: Mach 4 Feature Request
Post by: smurph on February 22, 2015, 05:03:39 AM
Not hungry.  Just setting the record straight.  We are making a lot of people happy with Mach4.  And that is what it is all about!  Some will never be happy though and that's ok.  I know we can't make everyone happy and I can live with that. 

Here is the scoop on Mesa:

The reason Mesa is not interested in Mach3 or Mach4 is that they don't have the staff to support it.  They build motion controllers, not software.  And his target market doesn't require him to have a software team.  Mesa sells tons of boards to the Silicon Valley area companies.  And they enjoy a good LinuxCNC market as well.  But that market has "free" programmers that made the Mesa work with LinuxCNC and they keep it up and support it.  So Mesa doesn't really have to. 

I like the Mesa boards.  A while back (10 years?), I wrote a C API library for the Mesa SoftDMC firmware that a few of Mesa's customers use.  I gave it to them because I liked their stuff so much.  And Peter Wallace is a good guy.  And I actually wrote a Mesa plugin for Mach3 but never released it because I didn't have the time to support it.  So if there is a Mesa plugin for Mach 4, it will be supported by Mach (or maybe someone else?).  The downside is that it will not be free because someone will have to pay for the development.  This is in stark contrast to the motion boards that are built and supported buy their manufacturers.  ESS, PMDX, HiCON, DSPMC, etc...  They write the plugins for their boards because Mach is their market. 

Anyone want to step up and write the Mesa plugin and support it?  I'm completely serious.  It deserves a good go.  But it would have to be supported where people wouldn't be left out on an island with hardware that won't work after a Mach update.  We don't want that at all! 

Why am I up late?  Man...  I don't know!  I guess it is my quiet time when I can get on forums and stuff.  It seems there is not enough time in the day for me otherwise. 

Steve
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 12:43:02 PM
So what would it COST to do  a Plugin for the Mesa products. A best Guess would be fine.

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 12:47:37 PM
Daniel  Look up at your screen name : Daniellyall , Daniell yall??  THat is where I got the spelling ;D

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 22, 2015, 01:12:24 PM
it does not matter been called worse I could have said look up the bible I have one of the names that is only said one way for most languages.

are you going to do the Mesa plug in. it might be something to suggest to art not like he has nothing else to do (-:)
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 01:22:57 PM
Art is not in control of MAch3/Mach4 has not been for several years. He is up to his ears with Gearotic Motion.  The problem here is going to be OEM relations. IF Someone were to provide a plugin for the Mesa boards the OEM that are doing their OWN will cry FOUL/Unfair. So where would that leave artsoft??. Now if MESANET did their own plugin or at least financed it then it is just fair competetion of the market.

HUM maybe get Mesa to hire Smurph to write and support a plugin ??  It could not hurt to ask. I have been told NOPE before. It really does not hurt much (;-(.

Probably the BIG hurdle for now is the ever changing M4. It can make a plugin obsolete , non working over night.



(;-) TP
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 22, 2015, 03:06:12 PM
yes I do know what art does its a suggestion nothing else since pp is all most done and dusted.

Art is a very clever person if someone could do it it would be him so he can move his cool stuff onto something that's not going to be done in a few years it`s a good idea.

Mesa hire Smurph don't think that would happen.

plugins getting broken they give the plugin developers the new version first sometimes
Title: Re: Mach 4 Feature Request
Post by: smurph on February 22, 2015, 07:59:42 PM
Yeah, if there is something that will break the plugin interface, we give the offending release to the plugin writers first and give them a chance to prepare a bit.

But the API changes that break the interface are few and far between now.  I hope that soon we just won't have that anymore.  But nothing is forever, so I will never be one to say that it just won't happen in the future. 

Cost of a plugin...  well...  it is rather difficult to pinpoint that.  What with the old 80/20 rule.  80% can probably be done real fast but the last 20% is the killer.  Paying a programmer to do it will probably cost in the order of 5 to 10K.  But probably a lot more by the time it gets production ready.  So ROI on it at $25.00 a license (guessing?) is going to take a while.  Even if the plugin takes off like wild fire, it would take a bit to recoup the investment.  The only way out of that is to raise the price.  But it would really be a hard sell to have a plugin reach the cost of Mach to begin with! 

Take Darwin, for instance.  Art will never see any break even line on that.  He did it because he is Art and that was enough for him.  He did it for the love!  :)

Steve 
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 22, 2015, 08:18:03 PM
yer arts the man, god if I only could do what he can it would make life so much easier.

it was just an idea take it or leave it don't worry me there is still the ESS
Title: Re: Mach 4 Feature Request
Post by: BR549 on February 22, 2015, 09:21:44 PM
Gee Steve don't ya LOVE Mach4 and Mesa hardware ? ;D

(;-) TP
Title: Re: Mach 4 Feature Request
Post by: Ya-Nvr-No on February 23, 2015, 09:06:07 AM
f___  BR549 I am a boy not a girl (:-)),

http://www.machsupport.com/forum/index.php/topic,28556.msg200410.html#msg200410

hell, I been confused from way back when you referenced "madam secretary"  ???  ;D
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 23, 2015, 01:15:49 PM
true that I was taking the piss but yes I am a boy
Title: Re: Mach 4 Feature Request
Post by: smurph on February 23, 2015, 06:50:09 PM
gcEdit proposed licensed features:

Tool path back plot, DNC, and advanced editing features, and simple tools for common operations.

Advanced editing features:
Convert to Inch
Convert to Metric
Remove Spaces
Insert Spaces
Remove Zeros
Renumber N sequence numbers

Tool:
Bolt hole pattern
Circular pocket
Spiral Mill Bore

DNC, Circular pocket, and renumber are not finished as yet.

Steve
Title: Re: Mach 4 Feature Request
Post by: dude1 on February 23, 2015, 07:58:04 PM
could you add converting Y to A, back plot is in arts new program so to me not important but good having everything in one place, converting inch to metric that's a good idea what you thinking as a cost.

and its a dam sight better than fusions one hopefully I can link it
Title: Re: Mach 4 Feature Request
Post by: smurph on February 23, 2015, 08:12:42 PM
I have no idea on the cost.  I don't get involved in that.

I can do the axis convert.

Steve
Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 09, 2015, 06:20:17 AM
Greg at Tormach did exactly what he should be doing in "HIS" world . Locking the user out from the internals that they have little to no need to be tinkering with in there.  In that WORLD you have to protect the users from themselves AND protect the machine so it can be stable and the OEM can trouble shoot it.

NOW REMEMBER Tormach gave everyone the  option to UNLOCK the Mach3 machine so YOU could have at it. But at point you were on you OWN as to trouble shooting it WHEN you messed it up.  

The NEW Tormach unit is a dedicated CNC machine controller , Same as HAAS,OKUMA,MAZAK, etc,etc.( Just a smaller scale)  NOT a do everything motion thingy to make everyone happy.

Terri,

I was not arguing whether Tormach has a right to create and follow their own business plan.

My comment was that it in not reasonable . . . .  in my opinion . .  to try to make a direct comparison between Tormach's new pilot and MACH4. An analogy might be comparing a portrait to a bunch of tubes of paint and a paintbrush.

Pilot is a 'purpose built' product and MACH4 is more of a tool. The portrait you look at and enjoy and it SHOULD be a finished and well defined and detailed piece. But you can't change it.

MACH4 is tubes of paint and a brush. The way I view it, you are not buying a product in its final form. Many folks will do a 'paint-by-number' type of picture, some will only use the white tube of paint and other will create great portraits limited only by their skill and creativity.

For example, what can be reasonable compared? Pilot does 'X" and Mach4 does not? As (Smurph, I think it was) has said time and again, whatever you want MACH to do that is doesn't do already, you can probably make it do.

I am not usually one to pick up the pom-poms for MACH, but I have to say given the choice between Pilot and MACH4 . . .  no brainer.
Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 09, 2015, 07:14:01 AM
I was not vague.  Some of the other features are not finished yet.  The tool path is done.  But we really haven't promoted it at this point yet because we don't know what all we will add.  So if vague being that "I don't know what else at this point" then I guess so.

I asked for a specific feature, not the whole to-do list. I selfishly wanted to know if that specific feature had made it onto the list. I further asked if it is in, or will be in the pro version and said I would be happy to pay for a license if that feature is included. I don't think I asked something unreasonable . . like the date it would be available.



No one noticed the "LOL" in the comment?  Or was it just you?  It was not sarcasm for the sake of anything.  It was a joke.  That is how I am.  I like to joke around.  I'm a happy guy.  And I refuse to walk around on eggs shells just to keep from accidentally pissing someone off.  I will be the first to tell you that I'm not politically correct in any shape, form, or fashion.  It is not worth my time.  We have precious few minutes to live on this Earth to be wasting them on that kind of stuff.  

You are preaching to the choir . . . I invented 'I don't care if I piss you off'    :D

And I was trying to be honest too.  I have that "editor change feature" on my list.  But it is way down the list at the moment.  Nothing else meant at all.

The implication was, as I read it, that the requested feature was not important enough. This forum has enough bullies and personally I don't mind at all going toe to toe, but I know for a fact that a lot of people don;t post on THIS forum for fear their ideas will be ridiculed.  

I am guilty too and I'll take the spanking for it when I have it coming. Probably sounds odd coming from me, but I think we could all be a bit more sensitive and it would improve the forum.



And now I find myself getting a lecture (on my birthday of all days) from someone that doesn't even bother to look at the editors and see if the other feature that you "specifically referenced" but are being "vague" about (by not mentioning it again) has been implemented.  It seems that you would rather just open up a forum and post Negative Nancy comments.  Thanks, but no thanks.  Just so as not to be vague, I'll throw it out there...  Printing.  It needed to be done.  It took me three weeks to get it in there.  I won't get paid a penny for it either as gcEdit is freely available in the Demo.  You are welcome!


Jeez, if I knew it was your birthday, I would definitely have waited to piss you off.  I did check the editor. How else would I know to ask for the feature? If there is a demo of the pro version that I could have looked at, then you have me there, and my apology. I did not check. Rather I assumed I would need to buy the license, which incidentally I said I am happy to do if the feature is in there.

For the rest of you that post constructive things, I want you to know that I spend MY time trying to make this software the best that it can possibly be.  I spend 12 or more hours every day doing that.  We listen to your requests and we try to get every one of them in there somehow within reason.  We are not going to cater to the 1% on anything though.  We are not going to write one person custom software that does EVERYTHING he wants it to do in a niche environment.  But yeah...  if it is something everyone will benefit from, we try to get it in there.  It just takes time.  Lots of it.  
Steve

"the rest of you?"   This is the 'ah *********/attaboy' ratio at work. I am defined by one post as Negative Nancy. I have been posting a lot of very positive comments about MACH4 since returning here. I would wager at least 90% positive in fact. I have completed porting over my controller only because you and the rest of the mach team have done a very good job getting mach4 more stable and a lot of the forum members have also contributed greatly to the available documentation and knowledge base. My last visit was when the Demo was first released and there was not a lot of good things to say, except that TCP Modbus was fast as hell . .  and I think I did say that.

So stop living in the past . . .  ;)
Title: Re: Mach 4 Feature Request
Post by: it*guy on March 11, 2015, 02:15:47 PM
I would like a screenset for those of us with vacuum tables like the one in this thread...
http://www.cnczone.com/forums/diy-cnc-router-table-machines/133039-lvl-steel-base-8.html

and if anything else, just a way to convert the mach 3 screen sets and port them to mach 4
Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 11, 2015, 08:14:06 PM

FWIW, I have looked for a demo version of the 'Pro' Gcode editor for MACH4 and cannot find one.

If it is available somewhere, can someone post the link, please.

Title: Re: Mach 4 Feature Request
Post by: smurph on March 11, 2015, 08:38:49 PM
The one that comes with Mach 4 is the demo version.  Demo is not a good word, as it is fully functional as it is and does not time out or anything.  Unlicensed would be a better word.  The licensed version would have more features (not all of which I can remember at this time so please do not state that I'm being vague.)  We don't have a demo version that enables the Pro features for a limited time or some such.  Not yet.  Because we simply haven't finished it yet.

When it is done, I think Todd may be able to do a time limited license or something.

Steve
Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 12, 2015, 05:15:42 AM
The one that comes with Mach 4 is the demo version.  Demo is not a good word, as it is fully functional as it is and does not time out or anything.  Unlicensed would be a better word.  The licensed version would have more features (not all of which I can remember at this time so please do not state that I'm being vague.) 
I hope you are not reading the word vague as 'evasive'. Vague just means 'not specific', or indistinct. There was no negative connotation intended.  But back at you, please don't state that I did not 'bother' to check for the feature. That was Negative Nancy . . ism . .  ness . . .    ;)    I checked the information that was available.

We don't have a demo version that enables the Pro features for a limited time or some such.  Not yet.  Because we simply haven't finished it yet.

Maybe a better way to ask is this: Are we looking at 'we have a short list, but it not finished yet' -or- 'we have not decided what features will be added'.

Also, I recognize that this task may not be on your plate. The question is directed at whoever has the information. You just happen to be person who is accessible . . . which is much appreciated, incidentally.


When it is done, I think Todd may be able to do a time limited license or something.


Just to bury the semantics on this topic, here is the description of the specific feature that I am interested in:

Ability to replace one line with multiple lines.

Existing working examples:

notepad++
   - control characters inserted in the 'replace' field will generate muli line replacement.

ex: find "G0A"
     replace with "M4008\nG0A"
   
result "M4008" is inserted as a separate line above an unaltered 'A' axis move
   
CNC cookbook G-code editor (I requested this feature and it was added).
     - this feature is more sophisticated and can recognize and apply context based rules.

My wish list enhanced feature :
     ability to grab the entire line that contains a 'find' string match
   
ex: find "G0A*"   would pull from the match to the EOL
     find "*G0*"   would pull the entire line (block) that contains the match

Together with the 'newline' feature described previously, this would allow insertion of code after every occurrence of the match.
 There are work-arounds for this, but it would be accessible to all users if it was made a feature.

This is just string manipulation stuff. Should not be that difficult to implement.

OK, that's my Mach4 feature request.


Title: Re: Mach 4 Feature Request
Post by: dude1 on March 12, 2015, 05:29:10 AM
that can all be done with notepad++ new updated version, what is needed is more than notepad++ or they are wasting there time they need notepad++, plus back plotter and re-coder so macro b can be done as well.

they wont charge that much for it if it can do everything notepad++ can do in G code plus macro b and back plotter I would pay as much as M4 for it.

just give them time it can be next year.

Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 12, 2015, 06:33:26 AM

Not a feature, per se, but the ability to turn off the borders around the image toggle buttons is needed.
Title: Re: Mach 4 Feature Request
Post by: poppabear on March 15, 2015, 08:52:27 AM
Hi Steve,

   Would you be willing to add TWO (possibly 4) “Universal Motion” Plugin variables to the OEM distro? These would be for MPG support that came in across OTHER means than the Motion board itself. i.e.: Modbus, USB, Ether, etc.
The Motion board developer could also get to them, so if we have a Hand Held Pendant (shuttle pro, Mod-io etc.), we could pass the pendants MPG counts and notify them that we are using an MPG, so they could implement the MPG motion.
   
Like have (for up to 3 “Other” MPGs that come across the Modbus), have registers that say this:
•   OMPG1, OMPG2, OMPG3,      These would be the MPG counts, ( OtherMPG1-3).
•   UsingOMG,  (Using Other MPG, this bool would tell the motion board plugin that the “Other”
MPGs have read control and to read the counts from OMPG1-3.

Scott
Title: Re: Mach 4 Feature Request
Post by: simpson36 on March 22, 2015, 04:02:22 AM

Access to the MACH4 screen source code.

If we do not have this already, then this is a feature request.

If we do have it already, how do we get to it?
Title: Re: Mach 4 Feature Request
Post by: dude1 on March 22, 2015, 05:17:30 AM
that would more than likely be a big no
Title: Re: Mach 4 Feature Request
Post by: cpinfold on May 28, 2015, 10:48:06 AM
I have 3 suggestions:

1) A lot of motor drives include fault indication.  Have default fault input available for each motor.  While this could be done by the user adding some code, including this feature would make it much easier for a hobbyist to just "plug and play".  (I know that these signals could be added to the EStop input, but then you don't know what Motor/Axis has the issue).  Alternatively multiple EStop inputs with the ability to "label" them so that Mach can report which EStop was triggered.

2) Digitally sign your program (as you are doing with the plugins) so that Windows reports the publisher as ArtSoft or Newfangled.

3) Display some message when the demo stops working so that we know whether it has timed out or there is another issue that needs troubleshooting.

Thanks!
Title: Re: Mach 4 Feature Request
Post by: Screwie Louie on May 29, 2015, 04:18:49 AM
Two thumbs up! Mach 4 = open source. With your current licensing premium as a price for the API, just open it up for us all. Or an option, as a hobbyist and not OEM. The community could evolve  Mach 4 faster than Sherlock Holmes could solve a case. From a trade-off, best-value, cost-benefit analysis and risk analysis what does Mach 4 have to lose? Beta testing has been going on for years. Every day more potential share of industry capture is going to proprietary software at ridiculous costs. An open source community has the exponential potential for you to decrease operating costs, advance development ahead of schedule, increase customizability, and release an industrial product in the short term future. Is the risk worth it? What is the net present value if you did or did not? I don't know, but it is a course of action to consider as an alternative. Microcontroller capabilities...reduction in footprint & cost. Life cycle sustainability and overhead reduction costs. Instead of a few support staff, the potential could be this whole forum becomes your support staff for free. But risk...darn it the risk. Human nature tends to lean towards survival of the fittest. And how do we survive today? By money, cash flow to pay the bills. It would take a community of users that believe in the potential of Mach4's core and API capabilities to contribute their efforts for free. Is that possible or just a pipe dream?
Title: Re: Mach 4 Feature Request
Post by: DazTheGas on May 30, 2015, 06:49:31 PM
Is it just me or has the add page function in the editor broke, added a new page but can no longer add any objects to it in the editor??

Build : 2472

DazTheGas

OOPS WRONG THREAD
Title: Re: Mach 4 Feature Request
Post by: dude1 on May 30, 2015, 06:53:22 PM
just you just tried its fine
Title: Re: Mach 4 Feature Request
Post by: DazTheGas on May 30, 2015, 06:55:10 PM
But did it give you a copy of default page thats identical or blank one?

DazTheGas
Title: Re: Mach 4 Feature Request
Post by: dude1 on May 30, 2015, 07:54:25 PM
a blank page that I added to, the bit at the bottom was there whats on all pages, if that's what you mean there is a problem with the new versions of M4 it don't like winxp
Title: Re: Mach 4 Feature Request
Post by: DazTheGas on May 30, 2015, 08:15:38 PM
ive just developed a whole new diagnostic page, tried it on 2 different machines and it wont load in the editor, after exiting the editor its gone from the screen.ini file??

DazTheGas
Title: Re: Mach 4 Feature Request
Post by: dude1 on May 30, 2015, 08:29:49 PM
puts this in bug reports silly question did you save first before closeing
Title: Re: Mach 4 Feature Request
Post by: poppabear on June 11, 2015, 08:53:12 AM
Hi Steve,

Could you add TWO more "mc" functions for handling Jog Types:

JogType, rc = mc.mcCntrGetJogType(number mInst); --or what ever you wanna call it...

rc = mc.mcCntrSetJogType(number mInst, number JogType);--or what ever you wanna call it...

"JogType" could be:  mc.JOGTYPE_CON, mc.JOGTYPE_INC, mc.JOGTYPE_MPG, mc.JOGTYPE_SHM
These would represent: Jog modes: Continuous, Increment, MPG, or Shuttle Mode

Currently, the only way to get to this kind of information is to add these Buttons/LEDs to the screen set,
then write screen property getters to see what your screen LEDs are saying. You can't find out this
info by mc calls and that ties your scripts to a specified screen set for "Pendant" or other Jog control things.

or maybe a:

StringsOrEnums, boolState, rc = mcCntrGetActiveFuncs(inst);

StringsOrEnums: would be a large list of currently active functions in Mach4 much like the OEM LEDs where in Mach3, and I know you don't like Mach3...  :)
boolState: would show what that state of that OEM func is.

that way we could parse through a master list, for the above JogTypes and/or other standard OEM functions to see if this or that is On/Off from one call type.

It would still be nice to be able to Get/set the JogTypes from a script (or plugin).

Thanks for all you do,

Scott






Title: Re: Mach 4 Feature Request
Post by: MachMotion Development Team on June 12, 2015, 12:28:13 AM
I think there are outputs for all the jog modes.  And all outputs can be mapped to the screen.

Hi Steve,

Could you add TWO more "mc" functions for handling Jog Types:

JogType, rc = mc.mcCntrGetJogType(number mInst); --or what ever you wanna call it...

rc = mc.mcCntrSetJogType(number mInst, number JogType);--or what ever you wanna call it...

"JogType" could be:  mc.JOGTYPE_CON, mc.JOGTYPE_INC, mc.JOGTYPE_MPG, mc.JOGTYPE_SHM
These would represent: Jog modes: Continuous, Increment, MPG, or Shuttle Mode

Currently, the only way to get to this kind of information is to add these Buttons/LEDs to the screen set,
then write screen property getters to see what your screen LEDs are saying. You can't find out this
info by mc calls and that ties your scripts to a specified screen set for "Pendant" or other Jog control things.

or maybe a:

StringsOrEnums, boolState, rc = mcCntrGetActiveFuncs(inst);

StringsOrEnums: would be a large list of currently active functions in Mach4 much like the OEM LEDs where in Mach3, and I know you don't like Mach3...  :)
boolState: would show what that state of that OEM func is.

that way we could parse through a master list, for the above JogTypes and/or other standard OEM functions to see if this or that is On/Off from one call type.

It would still be nice to be able to Get/set the JogTypes from a script (or plugin).

Thanks for all you do,

Scott







Title: Re: Mach 4 Feature Request
Post by: poppabear on June 12, 2015, 09:13:54 AM
I understand what your saying,

But you cannot get to "Shuttle Mode", Nor can you "SET" the JogType that you want from mc.mc****************** Calls.

Scott
Title: Re: Mach 4 Feature Request
Post by: Pedio on July 21, 2015, 04:54:24 PM
Can we get a menu item or something under the load screen set menu item that allows someone to see what screen set they are currently using?

Thanks,
Peter
Title: Re: Mach 4 Feature Request
Post by: CCWood on July 27, 2015, 07:36:27 PM
My top feature request:

1. elapsed time: time it took for the toolpath to be run (cycle start to finish).
2. total project time: total run time for each tool path in the project to be run (elapsed time toolpath 1 + elapsed time toolpath 2 + elapsewd time toolpath 3... ect) operator resets at the begining of each project.
3. ability to add .wav files and speech (like in mach3).
Title: Re: Mach 4 Feature Request
Post by: giannis121 on August 09, 2015, 09:45:13 AM
-REVERSE RUN

Can this feature be implemented?
If so, when do you think it will be ready?

Kind regards.
Title: Re: Mach 4 Feature Request
Post by: CCWood on August 25, 2015, 08:15:08 PM
Sound, Sound, Sound... Mach 3 had the ability to use text to speech and wav files. It also would play a sound when selecting an axis and zeroing an axis.
Mach 4 seems to be mute.  :-X
Title: Re: Mach 4 Feature Request
Post by: tgirard on October 23, 2015, 07:57:58 PM
Ability to programmatically read and adjust the height and width of the MACH4 window so that I can maintain aspect ratio when resizing. If there's already a way to do that, PLEASE let me know
Title: Re: Mach 4 Feature Request
Post by: FocusPaul on October 26, 2015, 02:55:17 AM
3. ability to add .wav files and speech (like in mach3).

Sound, Sound, Sound... Mach 3 had the ability to use text to speech and wav files. It also would play a sound when selecting an axis and zeroing an axis.
Mach 4 seems to be mute.  :-X

See the Lua script "Play files.mcs" in LuaExamples folder about how to play a media file in Mach4.
Title: Re: Mach 4 Feature Request
Post by: Sage on October 27, 2015, 05:02:24 PM
How about a link to the examples. I can't find it.

Title: Re: Mach 4 Feature Request
Post by: dude1 on October 27, 2015, 05:11:09 PM
its in the example folder in M4 or was
Title: Re: Mach 4 Feature Request
Post by: Sage on October 27, 2015, 05:45:11 PM
That's what the original post said. I didn't know there were examples in M4 so It didn't click - Sorry. I'll take a look.
Thanks
Problem is I'd like the sounds back as well (and a few other things). But not sure I want to learn a new language. Too bad it isn't a config setting. Oh well.
I'm sure I'll figure it out. It seems a lot of "nice to have" stuff as per Mach3 will now be up to the user to program. So I guess I'll get on board and learn Lua.

Thanks

Sage
Title: Re: Mach 4 Feature Request
Post by: dude1 on October 27, 2015, 05:54:29 PM
thats cool the answer need to be holding hand answer`s otherwise you won't know where to look
Title: Re: Mach 4 Feature Request
Post by: FocusPaul on October 28, 2015, 02:58:08 AM
How about a link to the examples. I can't find it.



The examples are placed in Mach4 installation folder in folder LuaExamples.
The 2763 version (http://www.machsupport.com/software/downloads-updates/#tabs-2) contains those examples.

Problem is I'd like the sounds back as well (and a few other things). But not sure I want to learn a new language. Too bad it isn't a config setting. Oh well.
I'm sure I'll figure it out. It seems a lot of "nice to have" stuff as per Mach3 will now be up to the user to program. So I guess I'll get on board and learn Lua.

Lua is a very easy to learn "scripting language", that's why it's used programs nowadays. If you need some quickstart, read some of the examples mentioned above (e.g. MessageBox.mcs or ActivateOutput.mcs). There's also a lot of simple Lua code in the wxMach screen set, which can be edited easily with Mach4 screen editor.
After a while you'll find out Lua is a lot more powerful than the Mach3 configuration and its Visual Basic scripts :)
Title: Re: Mach 4 Feature Request
Post by: Sage on October 28, 2015, 07:35:24 AM
Ok. Thanks. I'll try to find some time to look it over.

Sage
Title: Re: Mach 4 Feature Request
Post by: pwestuk on November 06, 2015, 05:26:20 PM
 I believe Mach 3 had the ability to change from CV mode to ES on approaching angles greater than a specified value. Could we have either this feature or some trajectory planning that will allow users like myself with undersized stepper motors / machines that are not as rigid as they should be run our machines a little more effectively. Running my machine in ES is costing me a lot in cutters and time, I would love to get it running more efficiently again.

I think this was already somewhere in the development list, I was mostly hoping for a progress report. Thanks
Title: Re: Mach 4 Feature Request
Post by: dude1 on November 06, 2015, 05:29:35 PM
it's being done now
Title: Re: Mach 4 Feature Request
Post by: pwestuk on November 06, 2015, 05:34:30 PM
Brilliant, thanks
Title: Re: Mach 4 Feature Request
Post by: daduggan on April 22, 2016, 12:34:02 PM
I was wondering if it's possible to add printing. It would be nice to be able to print the tool path to scale or export or PDF. If this is done from the current tool path display, any perspective viewed could be printed. This is a vector graphic so it should be easy to export or send to a printer. This would be helpful when hand coding or making changes and need a new printout showing the changes.
Title: Re: Mach 4 Feature Request
Post by: DazTheGas on April 22, 2016, 01:02:36 PM
why not just do a screen dump using the print screen button.

DazTheGas
Title: Re: Mach 4 Feature Request
Post by: daduggan on April 22, 2016, 11:56:19 PM
Well I was thinking more along the lines of something a bit more usable then just a pic of the drawing. Something that is to scale in the form of PDF or just a vector graphic file that can be imported into Coreldraw or a CAD program.
Title: Re: Mach 4 Feature Request
Post by: royce on April 23, 2016, 01:57:29 AM
Well I was thinking more along the lines of something a bit more usable then just a pic of the drawing. Something that is to scale in the form of PDF or just a vector graphic file that can be imported into Coreldraw or a CAD program.
I think it would be kinda pointless since your generating code cam from a vector anyways, why not just do it in your cad program to begin with??  Unless for some weird reason you really need the tool offset???
Title: Re: Mach 4 Feature Request
Post by: grsfldflyer on May 13, 2016, 01:27:12 PM
Dryrun.
Title: Re: Mach 4 Feature Request
Post by: Wallerawang on July 20, 2016, 04:30:52 PM
Hello Guys
Could we have an addition to the Jogging Panel to include MGP jogging with an axis selector, jogging mode and a step size.
Thanks
Steve
Title: Re: Mach 4 Feature Request
Post by: gsimons on July 26, 2016, 03:54:49 PM
Retrofitted an ID/OD grinder. I need G65 subroutine call to work in Mach 4 Lathe
Title: Re: Mach 4 Feature Request
Post by: smurph on July 26, 2016, 04:33:53 PM
G65/G66/G66.1 and conditional G code work in lathe and mill but requires the Industrial version.  Meaning they are not in Hobby.

Steve
Title: Re: Mach 4 Feature Request
Post by: gsimons on July 26, 2016, 05:02:47 PM
I am running licensed industrial version.
Title: Re: Mach 4 Feature Request
Post by: smurph on July 26, 2016, 07:17:12 PM
What build?  That should all be there.
Title: Re: Mach 4 Feature Request
Post by: TommyG on August 23, 2016, 07:31:21 AM
One thing I'd like to see is an additional screen set for higher resolution monitors i.e. a 1920x1080 one.
The standard screen scales up fine onto a larger screen, even my 3440x1440 monster but editing the screen is a chore.

Or has anyone any tips on how to rescale the entire screenset?
Title: Re: Mach 4 Feature Request
Post by: Durero on September 10, 2016, 11:04:38 PM
It would be fantastic to have Spline and Nurbs G codes like Linuxcnc

http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g5

If this was implemented in Mach4 I would no longer need CAM software for my application: carved top electric guitars.
Title: Re: Mach 4 Feature Request
Post by: MegaMoog on September 25, 2016, 07:45:30 PM
How about a tool change (macro) or whatever it is called (like 2010 screen set ) ? Now don't flame me too bad… please!

MM
Title: Re: Mach 4 Feature Request
Post by: cheech on October 14, 2016, 07:50:56 AM
@smurph please CV control and symmetric accel/decel. Mimic Lcnc TP.. it works brilliant.
Title: Re: Mach 4 Feature Request
Post by: steezebe on October 20, 2016, 07:56:04 AM
I second the 4k screen scaling!

Also, there should be a built-in updater that can be run to check for updates to Mach.
Title: Re: Mach 4 Feature Request
Post by: sour kraut on November 18, 2016, 10:48:02 AM
Better documentation.
Title: Re: Mach 4 Feature Request
Post by: novec on November 24, 2016, 12:51:16 PM
Is there any chance of getting acceleration curves instead of a fixed value? The torque curve on most steppers let them accelerate fast at low speeds, but they won't be able to keep it up at higher speeds. Maybe there's already some magic working in the depths of the programming that takes care of it?
Title: Re: Mach 4 Feature Request
Post by: Zeeflyboy on December 22, 2016, 10:25:59 AM
I would love USB microscope support for zeroing similar to what one can do with LinuxCNC

Basically just embedding a video from a USB microscope using e.g. mplayer and some overlay crosshairs (plus a circle would be really nice), enter the offset from crosshair to spindle centre, click zero.

Quick, easy and cost effective way to get a pretty accurate XY zero position on a variety of setups.

Title: Re: Mach 4 Feature Request
Post by: ger21 on December 22, 2016, 10:46:11 AM
That's like 4 lines of code in a macro.
Title: Re: Mach 4 Feature Request
Post by: Zeeflyboy on December 22, 2016, 11:04:26 AM
Should be easy to include then ;) haha

Is it really that simple including embedding the video and overlaying crosshairs?

If you would be able to help me implement it I would greatly appreciate it, or just a point in the right direction!

Cheers
Title: Re: Mach 4 Feature Request
Post by: ger21 on December 22, 2016, 11:06:22 AM
No, embedding the video is much more complicated.
Title: Re: Mach 4 Feature Request
Post by: Zeeflyboy on February 27, 2017, 05:14:26 AM
Another request...

I see lots of people struggling to get a realistic RPM when using mach to control a spindle through a 0-10v output. I have managed to tweak the output voltage of my controller so that the end points are correct, but the issue I have is that it is not entirely linear.

So while 10v = 400hz (i.e. 100% for my setup), 5v seems to cause the VFD to go to e.g. 220hz rather than 200hz. You can of course compensate this by setting a slightly different rpm to the one that you actually want but that seems unnecessary...

It would be very nice if Mach4 allowed users to calibrate the spindle voltage output so that it follows a curve rather than a straight line - would certainly be easier than using modbus for a low level user that just wants a slightly more accurate spindle rpm.

Perhaps give 4 calibration points (e.g. 30%, 45%, 70%, 85%) and interpolate a curve from those points?



Title: Re: Mach 4 Feature Request
Post by: Cbyrdtopper on March 07, 2017, 04:58:27 PM
I started a thread about this, I think it would be a useful feature.  The Optional Stop Output in the Config.  This output gets the handle of the M01 State, whether it is enabled or disabled, it is not an output while the Pause is in affect like I thought it would be.  If there was another output that came on during a Pause due to the M0 or M01 that we could use to turn on indicators, that would be handy.
Title: Re: Mach 4 Feature Request
Post by: django013 on April 29, 2017, 10:38:35 AM
Hello,

I have a few wishes for gui:
- monospace font for DRO (will avoid flickering). Will it be possible, to use system ttf?
- transparent buttons/togglebuttons
- format for cycle time, or at least force the seconds with %02d
- possibility to move elements in tree-view of the screen-designer. Copy&delete is error-prone and tedious. DND would be nice, like bookmarks in firefox ;)
- format (i.e. spindle-speed) with thousand-separator
- support images for notebook-tabs (the tab itself, not the panel background)
- save position of split-pane-separators
- disable scaling of screen on toggling between screen-designer and application mode
- lock elements (no position change possible in locked state)
Title: Re: Mach 4 Feature Request
Post by: django013 on May 29, 2017, 08:32:05 AM
I have a new wish:

would it be possible to save position and size of application window in the profiles-subdirectory?

I'm working on different screens where each of them has a different aspect ratio.
Stopping work on one screen and starting the work on the other I first have to adjust application window to the new limits. :(
Title: Re: Mach 4 Feature Request
Post by: a3dcreator on June 14, 2017, 03:35:32 PM
machine kinematics please!!! for 5 axis
Title: Re: Mach 4 Feature Request
Post by: keinert on July 04, 2017, 04:56:59 PM
Separate motor acceleration and deceleration settings would be nice. I need a slower accel rate but then I'm also stuck with a longer time to decel and stop when I jog. Would be nice to have a slower accel rate but quickly decel when I let my finger off the jog button.
Title: Re: Mach 4 Feature Request
Post by: Cbyrdtopper on July 17, 2017, 09:36:28 AM
"Which output was that again??"

I'm setting up a machine right now and Can't remember waht some of my outputs are used for (stack light colors, spindle brake, etc....).  It would be really awesome if there was a "Description" column in the mach config for inputs and outputs.  I've got all my outputs documented on in excel on my computer but its annoying to keep walking back and forth to input data and utilize data from the spreadsheet.  So if there was a Description Column, that would be a great quick reference.
Title: Re: Mach 4 Feature Request
Post by: smurph on July 17, 2017, 09:41:58 AM
"Which output was that again??"

I'm setting up a machine right now and Can't remember waht some of my outputs are used for (stack light colors, spindle brake, etc....).  It would be really awesome if there was a "Description" column in the mach config for inputs and outputs.  I've got all my outputs documented on in excel on my computer but its annoying to keep walking back and forth to input data and utilize data from the spreadsheet.  So if there was a Description Column, that would be a great quick reference.

New builds have this.  :)
Title: Re: Mach 4 Feature Request
Post by: smurph on July 17, 2017, 09:47:23 AM
Separate motor acceleration and deceleration settings would be nice. I need a slower accel rate but then I'm also stuck with a longer time to decel and stop when I jog. Would be nice to have a slower accel rate but quickly decel when I let my finger off the jog button.

You can set the jog accell and velocities as a percentage of the maximums for the axis.  See mcJogSetAccel() and mcJogSetVelocity() in the API manual.  It will take a little scripting, but what you want can be done.  You will basically have to write button up and button down scripts using mcJogVelocityStart(), mcJogVelocityStop(), mcJogIncStart(), and mcJogIncStop(), depending on the current jog mode. 

Steve
Title: Re: Mach 4 Feature Request
Post by: Cbyrdtopper on July 17, 2017, 11:30:11 AM

New builds have this.  :)

Awesome!   
Title: Re: Mach 4 Feature Request
Post by: J.Hunter on July 26, 2017, 06:55:25 AM
What is the status for tangential motion in Mach4?
Title: Re: Mach 4 Feature Request
Post by: hyildiz on September 14, 2017, 12:09:38 PM
Hi,

For professional machines, you should implement the cam features of ModuleWorks directly to the Mach4 like the guys in the following link did,

http://www.directmotion.com/vertical-machining-centers.php

So that programming of simple operations or stl cam operations can be done directly on high res. touch screens.

You can sell that version as Industrial or Professional version with a higher price, quick support is not so important when it comes to price this kind of features does..
Title: Re: Mach 4 Feature Request
Post by: EShamaev on October 02, 2017, 12:33:24 PM
Hi,
I would like to know if there are plans to implement P~and Q~ words to G64?
Title: Re: Mach 4 Feature Request
Post by: mikelink83 on October 30, 2017, 12:25:05 AM
I would like to see an existing motion behavior removed or at least be disabled optionally in settings. Whenever an M or S code is encountered in the GCode or MDI the machine decelerates to 0, executes the command, and resumes. There is not necessarily any need for it to stop in the following example.

g00 x0 s1000       motion starts and spindle at 1000
g01 x10 s5500     motion stops, spindle changes to 5500, motion continues
g01 x20 s5500     motion stops, spindle still at 5500, motion continues (no change was made but the fact there was an S code in the line means the motion stops to address it)

If the spindle speed commands weren't in there, the machine would travel from x0 to x20 without interruption but with the extra commands in there (I tested and saw the same behavior with turning coolant on and off during motion) travel slows to 0 and without any delay executes the command and accelerates back to it's previous rate.

I have my Spindle Accel/Decel time at 0 and 'Wait on spindle to stabilize' disabled

The reason I want the travel rate uninterrupted is because I'm using spindle control PWM signals to control the power output of a laser to do raster engraving.

Assume each 'pixel' i want to engrave is 1mm and I'm drawing a 5mm striped pattern I'd code as:

g00 x0y0      starting point
x50           lead in for acceleration
x55 s255   laser power max 5mm
x60 s0      laser off 5mm
x65 s128   laser half power 5mm
x70 s0      laser off
x120        lead out for deceleration
y1           next line

The laser PWM control and positional results of this code work perfectly but that forced motion stop before executing S kills the end result of the piece.
Fixing this would make raster laser engraving incredibly easy in Mach4 with the use Inkscape plugin 'Raster 2 Laser GCode' which produces great results with simpler GCode senders. It would achieve the equivalent of Art's Impact / Laser plugin for Mach3.

Title: Re: Mach 4 posting request
Post by: halfmill on November 02, 2017, 02:11:31 AM
Hi, when I go to Mach 4 General Discussion  there is no "New Post" button on the page.  I cant seem to get to a page that has the "new post" buttons on them, so I used this reply to ask for help.  can someone tell me how to get to the page that has the post options in the Mach4 general discussion.  thanks...
Title: Re: Mach 4 Feature Request
Post by: Tweakie.CNC on November 02, 2017, 02:16:49 AM
Hi, when I go to Mach 4 General Discussion  there is no "New Post" button on the page.  I cant seem to get to a page that has the "new post" buttons on them, so I used this reply to ask for help.  can someone tell me how to get to the page that has the post options in the Mach4 general discussion.  thanks...


Hi Halfmill,

Use the New Topic button (just above the posts themselves)

Tweakie.
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on December 23, 2017, 07:33:01 PM
Would be nice when using the manual tool change ( mcCntlToolchangeManual) to have the tool number requested and Tool Description of the tool displayed in the dialog box. 

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 10:54:31 AM
Wouldn't it be wonderful if the api had a mcCntrlGetScrProperty('BtnName','BtnProperty')

This would eliminate the need to create register values that have to be set from an action and in order for a macro to access the value, string...

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 10:56:03 AM
Fix the lathe threading wizard infeed selection so that either it starts with a 'select in option' or if defaulted like it is now set the value to the defaulted selection.

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 10:57:47 AM
Fix the screen editor so if you go into the screen editor in something other than a maximized window all of the controls shift right and save that way.

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 10:59:19 AM
Default screen set for lathe should include the diagnostics page.

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 11:01:36 AM
Add checkbox control to screen editor.

MTCW

RT
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 18, 2018, 02:42:10 PM
Fix the canned cycle custom G code so that when you save and reload or quit Mach4 and restart any empty/blank lines don't get read back in with this result:

...
g0 x1
g0 z1

m3

g0x5
m5

....

comes back as

g0 x1
g0 z1
(------------------------------------)
((((((((((ERROR READING LINE))))))))))
(------------------------------------)
m3
(------------------------------------)
((((((((((ERROR READING LINE))))))))))
(------------------------------------)
g0x5
m5
(------------------------------------)
((((((((((ERROR READING LINE))))))))))
(------------------------------------)
(------------------------------------)
((((((((((ERROR READING LINE))))))))))
(------------------------------------)
Title: Re: Mach 4 Feature Request
Post by: rhtuttle on January 19, 2018, 02:59:30 PM
Default wxLathe.set, shouldn't the open Docs be enabled at all times.  Mine is now.
Title: Re: Mach 4 Feature Request
Post by: smurph on January 19, 2018, 07:01:23 PM
I would like to see an existing motion behavior removed or at least be disabled optionally in settings. Whenever an M or S code is encountered in the GCode or MDI the machine decelerates to 0, executes the command, and resumes. There is not necessarily any need for it to stop in the following example.

g00 x0 s1000       motion starts and spindle at 1000
g01 x10 s5500     motion stops, spindle changes to 5500, motion continues
g01 x20 s5500     motion stops, spindle still at 5500, motion continues (no change was made but the fact there was an S code in the line means the motion stops to address it)

If the spindle speed commands weren't in there, the machine would travel from x0 to x20 without interruption but with the extra commands in there (I tested and saw the same behavior with turning coolant on and off during motion) travel slows to 0 and without any delay executes the command and accelerates back to it's previous rate.

I have my Spindle Accel/Decel time at 0 and 'Wait on spindle to stabilize' disabled

The reason I want the travel rate uninterrupted is because I'm using spindle control PWM signals to control the power output of a laser to do raster engraving.

Assume each 'pixel' i want to engrave is 1mm and I'm drawing a 5mm striped pattern I'd code as:

g00 x0y0      starting point
x50           lead in for acceleration
x55 s255   laser power max 5mm
x60 s0      laser off 5mm
x65 s128   laser half power 5mm
x70 s0      laser off
x120        lead out for deceleration
y1           next line

The laser PWM control and positional results of this code work perfectly but that forced motion stop before executing S kills the end result of the piece.
Fixing this would make raster laser engraving incredibly easy in Mach4 with the use Inkscape plugin 'Raster 2 Laser GCode' which produces great results with simpler GCode senders. It would achieve the equivalent of Art's Impact / Laser plugin for Mach3.



There is a parameter option that changes the behavior of the look ahead. Normally, you WANT to wait on the motion to complete before the M, S, or T codes are processed by the look ahead. 

Set #3003 = 2.  That will disable MST waits.  But you must consider the look ahead!  If it is set to say 100, then up to 100 lines are read (and processed!) at one time.  In effect, the S command would be the last S command.  The only thing you can do to combat that is set the look ahead to 2 lines.  That way CV will be maintained across the G code moves and not come to a complete stop.  Setting the look ahead to 1 line would be the equivalent of running in exact stop mode, BTW. 

You would be wise to set #3003 back to 0 before any stop M code is issued (M01 M02, M30, etc...)

I really don't recommend the above at all.  Instead, Have a look at M62 and M63 (The motion controller must support these).  They control outputs synchronized to the movement of the G code.  M62 and M63 are special M codes that do not break the CV chain.  So you can leave the look ahead alone.  You could easily implement 0%, 25%, 50%, 75%, and %100 with a few outputs. 

We are still working on a dedicated laser interpreter.  It will have options specifically for lasers that should accommodate this type of thing. 

Steve
Title: Re: Mach 4 Feature Request
Post by: DaveHerron on February 23, 2018, 07:52:54 AM
An enhancement to the Z probing options that allow the four corners of a work piece to be probed and would generate an algorithm that that would continuously correct the Z axis height as the router moves along the Y and X axis.

This would compensate for work pieces that are not of a consistent thickness. I realize using just the four corners isn't ideal as the surface of the work piece isn't a perfectly flat plane that is just not parallel to the bottom surface. Currently I add shims between the work piece and spoil board and can get acceptable results. It is very time consuming to probe the four corners, shim the low corner(s) and recheck.

I have seen acrylic sheet thickness vary 0.010" from one end to the other across 15". When engraving at a 0.005" depth this leaves some areas uncut.

Maybe have an option to probe up to 8 or 10 points anywhere on the surface of the work piece. Known high and low spots could be intentionally selected along with the four corners.  

Best regards,
Dave
Title: Re: Mach 4 Feature Request
Post by: ysymidi on February 23, 2018, 10:28:01 AM
Please make decent Unicode available.

When I try to open a file including Korean alphabet in the path or in the file name itself, Mach4 just says... It can't open...

Even DeskCNC which was developed almost 15 years ago had no problem like this....
Title: Re: Mach 4 Feature Request
Post by: TOTALLYRC on February 23, 2018, 06:06:51 PM
An enhancement to the Z probing options that allow the four corners of a work piece to be probed and would generate an algorithm that that would continuously correct the Z axis height as the router moves along the Y and X axis.

This would compensate for work pieces that are not of a consistent thickness. I realize using just the four corners isn't ideal as the surface of the work piece isn't a perfectly flat plane that is just not parallel to the bottom surface. Currently I add shims between the work piece and spoil board and can get acceptable results. It is very time consuming to probe the four corners, shim the low corner(s) and recheck.

I have seen acrylic sheet thickness vary 0.010" from one end to the other across 15". When engraving at a 0.005" depth this leaves some areas uncut.

Maybe have an option to probe up to 8 or 10 points anywhere on the surface of the work piece. Known high and low spots could be intentionally selected along with the four corners.   

Best regards,
Dave
Search for a program called autolevellor(sp). Used for PCBs but might do what you want.

Mike
Title: Re: Mach 4 Feature Request
Post by: smav on March 22, 2018, 11:21:05 PM
Need scale DRO input boxes like found in mach 3 as well as be able to see the new program extents once you hit regen toolpath after scaling.
Need to add all screen input options like +/- feed rate, +/- Jog rate, +/- spindle speed, Spindle on/off and all other screen functions in the keyboard shortcut configuration so you at least have the option to map all those functions to the keyboard.
Title: Re: Mach 4 Feature Request
Post by: joeaverage on March 22, 2018, 11:28:22 PM
Hi,
as far as I know all of those features are in Mach4 already, or at least can be if you wish to assign the keyboard shortcuts.

DRO arithmetic basic and advanced is available.

Program extents on the second tab (away from my machine can't remember what its called).

Craig
Title: Re: Mach 4 Feature Request
Post by: striplar on May 30, 2018, 05:07:51 AM
Not so much a feature request, but a plea for more documentation on the components, what variables and functions are exposed by Mach4, and a better insight of how Mach4 works.

The more information that's made available, the more users will modify and improve screens and profiles. At the moment you have to be pretty determined if you want to do anything more than trivial changes to the appearance of a screen. As soon as you delve any deeper, you have to resort to asking questions on the Forum , search YouTube or glean some nugget of useful code by examining someone else's code. It shouldn't be that hard to find the necessary information in my opinion.
Title: Re: Mach 4 Feature Request
Post by: mcardoso on February 11, 2019, 01:12:12 PM
I second the comment by striplar. A more complete set of documents, especially on customization capabilities of Mach 4 would be a vital resource and would certainly ease of on the repetitious posts asking for screen editing and LUA functionality.

A very involved and knowledgeable forum community is an amazing way to help share knowledge of a product, but should not replace documentation as the backbone of product support. *my opinion :) Everyone here is great!
Title: Re: Mach 4 Feature Request
Post by: compewter_numerical on August 09, 2019, 07:56:01 PM
Add wxListBox, wxComboBox, wxRadioBox and wxCheckBox items to the screen editor.

If you create these items in a LUA panel on the screen, you cannot dynamically add or remove items from comboboxes or lists, which is ideal if customers want to create custom programs or features and add them to the combobox or listbox on the screen so they can select them later.

For example, we use an on screen listbox that needs to update in real-time. Whenever a job runs it's added to the list and when the job completes it is removed from the list. The wxFrame has to float on top of the entire screen because it's not possible to embed it into a LUA panel and update the list in real-time.

Another example is a customer can create custom programs that they can select from a dropdown combobox. The whole Mach4 software has to be restarted in order to repopulate the combobox if they want to add a new program. 

The LUA panel works great for other things though like a gcode program creator embedded into the screen.

(http://compewternumerical.com/GcodeCreator.PNG)

If there was a way to pass data to the Panels after they are created then it could possibly be a solution to the problem.
Title: Re: Mach 4 Feature Request
Post by: jbuehn on August 15, 2019, 11:48:08 AM
compewter_numerical...your lua panel can have an update UI event. Using that you should have no issues dynamically changing what you asked about.

Mach4's registers are a great way to pass data to your panel as you can monitor those in your update event.
Title: Re: Mach 4 Feature Request
Post by: compewter_numerical on August 19, 2019, 12:19:13 AM
compewter_numerical...your lua panel can have an update UI event. Using that you should have no issues dynamically changing what you asked about.

Mach4's registers are a great way to pass data to your panel as you can monitor those in your update event.

jbuehn, do you think you can help me find a resource for that? I have not been able to get it to work after many hours of trial and error. I even tried creating a fake button and simulating the action of the button to update the list externally.

I can see that when I compile the PMC it regenerates the wxWidgets on the screen...so there must be a way I just haven't found it yet.
Title: Re: Mach 4 Feature Request
Post by: mcardoso on September 22, 2019, 01:45:29 PM
Silly little request, but can there be a setting to auto enable soft limits when Mach 4 opens? It seems like a feature most people would want turned on normally and it is easy to forget.
Title: Re: Mach 4 Feature Request
Post by: dws on September 22, 2019, 09:27:02 PM
Watch this video to on how to turn on soft limits with homing. I believe that most machine setups require it to be homed before soft limits can work.

https://www.youtube.com/watch?v=IXuuGRACU1I