Machsupport Forum

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

Title: Mach 4 Bug Reports
Post by: Chaoticone on May 02, 2014, 02:59:45 PM
Lets use this topic to post any bugs we find in Mach 4. Lets keep this topic clean and to the point. This will be a list for Brain and Steve to work from. If you will list the operating system you are using and the steps or any other relevant information (Gcode, etc.) necessary to replicate the behavior you perceive as a bug that would go a long way in helping them narrow it down.

Thanks,
Brett
Title: Re: Mach 4 Bug Reports
Post by: m.marino on May 02, 2014, 05:22:01 PM
Issue install, opened once and than did not open. Will not install in C Drive but will in D.

Computer is running a Phenom 3 (number of cores) 64 bit with Windows 7 Pro 64bit Os and 4GB of RAM with an additional boast of 2GB.

With instructions will gladly do what is need to have a complete clean install to continue testing. The computer that Mach4 will be running on is a Athlon 64 running the same OS and also 4GB RAM.

Opened it up was looking through it in detail and liked what I saw. Closed it to go to bed and look at it today and will not respond. Unistalled from inside the program folder options and re-installed, no joy. Tried again in C drive and got an error for not being able to open/install Mach4GUI.exe. From what I am reading IF Smoothstepper writes a plugin for the ESS this is going to truly make things interesting for control and increase in signal quality (coupled with a PMDX-126 board and digital drives this could get very interesting indeed).

Thanks for the work and will help as able. Michael
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 02, 2014, 08:25:23 PM
Open task manager and kill the hung Mach4GUI.exe process.
Title: Re: Mach 4 Bug Reports
Post by: Calum on May 02, 2014, 08:31:35 PM
I have my profile configured for metric and notice the feed rate is still in inches, needs a conversion.

Calum
Title: Re: Mach 4 Bug Reports
Post by: m.marino on May 03, 2014, 07:40:55 AM
Open task manager and kill the hung Mach4GUI.exe process.

Yes, did that first thing on the first time it was not responding. Will try again and see if I can get a route trace on it. Thanks for the quick reply. One other area I should state is been using/building computers since before 98SE with industry use starting in '91. This is only to give a bit more back ground. There is still areas of software that i am good at finding issues and following directions but bad on tracking down on my own. -Michael

Edit: I did a file search and cleared all files that I could with Mach4 from the computer including the download. Re-downloaded Mach4 from site and installed in drive D (C still causing issues) and had it load drivers and open without issue this time. Will update once I have shut off computer and rebooted later today or tomorrow. Hopefully the issues will not repeat. - Michael
Title: Re: Mach 4 Bug Reports
Post by: Brian Barker on May 03, 2014, 09:52:59 AM
Post your machine profile folder in a zip file please and we will have something to check out for the mm stuff. Heck I think anyone that wants to post here should do that so we can have something to test and debug..  If have Gcode files please post them as well.

Thanks
Brian
Title: Re: Mach 4 Bug Reports
Post by: m.marino on May 03, 2014, 02:29:56 PM
Smurph and anyone interested,

When I closed Mach4 I made sure to end the MachGUI process in Task manager. Than I was able to re-open without issue.I than tried to see what was need to get Mach NOT to leave a process open after closing. Easy, disable Mach first and all process shut down when you close it. So that makes for a simple set of instructions for proper shut down that I can put down for future use and for teaching anyone how to properly use Mach4 (I consult small business on CNC equipment and unfortunately 3D printing as well). Nice set up so far. On to finding the next issue or non issue. -Michael
Title: Re: Mach 4 Bug Reports
Post by: Calum on May 03, 2014, 07:52:36 PM
As requested attached is my profile and a Gcode file, Blank Outlines V2-2.nc, I have been using for my testing.  This will show the feed rate in inches while the profile is set to metric.

BTW I notice that the "Show Tool Path Limits" on the Tool Path tab of Configuration is not sticky>

Calum
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on May 05, 2014, 04:05:39 AM
Recent File entries not working with long strings

Description:
When loading G code files with filename length > 80 characters, the file will load successfully. Clicking Recent File button later will fail, if full path and filename is longer than 80 characters, because path is stripped after 80th character.
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on May 05, 2014, 04:08:55 AM
Lua wizards opened during Mach4 session will kept open when closing Mach4.

(this may be a bug or a nice-to-have feature)
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 12:13:08 PM
Mach4 does not want to run the older Mach3 complex subs. It stalls and or cannot display the proper toolpath. I have examples of some that RUN fine in mach3 but not mach4 IF needed.

Also Mach4 does not want to run older fanuc macros that LOOK like it should run fine in Mach4 .

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 12:33:31 PM
Yes, please provide an example.  The sub stuff is all new code (as most of Mach 4 is), so there is bound to be something that doesn't work the same as Mach 3.  The example will help me make it more compatible.

Are you talking about macro A?  Because that will not work at this time.

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 12:40:21 PM
Recent File entries not working with long strings

Description:
When loading G code files with filename length > 80 characters, the file will load successfully. Clicking Recent File button later will fail, if full path and filename is longer than 80 characters, because path is stripped after 80th character.

Ok, good one!  Thanks.  It has been taken care of.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 03:36:42 PM
HIYA Steve here is an example of a sub that fails in Mach4 but runs perfect in Mach3.

I had another that would not run yesterday no matter what I did BUT today it ran fine  from the get go.


Looking at THIS program and how Mach4 displays the toolpath it seems Mach4 is having a bit of trouble with G18/19 and IJKs

If you need to see HOW it SHOULD be look at it in Mach3. It is making a hemisphere for a ball in cube routine.

Thanks, (;-) TP

Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 03:51:22 PM
Hmm...  I know that G17/18/19 have all been made to work "correctly" as to conform to Fanuc.  So it may be a case that the older Mach3 G code just may not work anymore.  We will have a look and see!

Steve
Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 05, 2014, 03:58:38 PM
Its a local var problem not a sub or plane issue

Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 04:11:19 PM
I'm glad Graham caught it because I was missing it.

To explain further because this IS a change from how Mach 3 operated.  It is because you are using local vars to pass values to a sub.  Used global vars instead.  Because the local vars are "local" to the main program just as they would be "local" to a sub.  local vars acted like global vars in Mach 3, which was not correct.

Steve
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 04:17:40 PM
SLAP on the head, Of course it is. I have been in Machism too long now.

Sorry for the waste of time, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 04:42:48 PM
OK I moves all vars up into the 100 range AND tried it in the 1000 range same problem.

Also simple testing show that Mach4 is perfectly happy using the G65 local vars in global applications. IS it suppose to or NOT ?

#1 =10
G0 X#1

There is not an error and the code runs fine.

I happy to se that G1 X- #1 is a legal call now instead of having to resolve the NEG direction from inside the variable G1 X[0-#1]. Both are excepted now.


??? , (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 04:53:58 PM
G65 local vars?  You mean the parameters?  Or this:

#1 = 2
#2 = 4
G65 P1000 X#1Y#2

type of thing?

The general rule of thumb is that result accessing local vars without first setting them "locally" is undefined.  They may have a value.  But it may not be what you want.

Try this...  Graham converted and it seems to work fine.

G50 G40 G80 G20 G94 G91.1
#101=1 (size of box)
#102=.125 (cutter radius)
#103=.125 (size of box bars)
#104=1 (degrees of resolution)
#105=#104 (COUNTER)
#106=[[#101/2]+#102] (ACTUAL RADIUS OF CIRCLE - CUTTER RADIUS + RADIUS)
G01X0Y0F100
m3 s3600 m8
M98 P140 L40
G0Z0
X0Y0
M30
%

o140 
   #108 = [[SIN[#105]*#106]*SIN[45]] ( X AND Y POSISION)
   #109 = [0-[[1-COS[#105]]*#106]] (Z HIGHT)
   g4 p0
   G1X[#108]Y[#108]F30
   Z[#109]
   G18 G02 X[0-#108] Z[#109] I[0-#108] K[0-[#109+[#106]]] F5
   G19 G03 Y[0-#108]Z[#109]J[0-#108]K[0-[#109+[#106]]]
   G18 G03 X[#108]Z[#109]I[#108]K[0-[#109+[#106]]]
   G19 G02 Y[#108]Z[#109]J[#108]K[0-[#109+[#106]]]
   #105=[#105+#104]
M99
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 05:46:07 PM
HIYA Steve I found the problem on this end. THAT code did not work here either BUT using an old MAch3 trick(reboot the PC) solved the problem here.

THis is what I saw no matter what code I ran. When it ran through post testing and drawing the toolpath this is what displayed.  Something gets stuck and I have seen this many times in testing now. You can see the IJKs ran amuck somehow like there were in the wrong mode and drawing crop circles.


Thansk Guys, (;-)TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 05, 2014, 06:18:08 PM
This is what I get.  You might have some other setting bonked?  Look in the general tab and make sure.  It has got to be something local to your machine.  :(

Steve
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 05, 2014, 07:05:35 PM
HIYA STEVE YES I FIXED IT . But I had to reboot the PC to do so.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 12:52:35 AM
HIYA Steve,  I noticed that when you cut and paste from the gcode editor it does not always hold the CUT in the buffer and when you leave the Editor to paste it somewhere else the paste is EMPTY. Quirk ?? or made that way ??

Would it be possible in teh Gcode editor to have it ADD a "Newline" when you exit ??? This still gets a lot of newbies.

Just a thought, (;-) TP

Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 12:58:46 AM
As to the quirky toolpath as long as I do not jump around back and forth between Abs and Inc IJs it has NOT acted up again.

The Code processing is VERY fast compared to Mach3 it can load a file in a blink compared to Mach3.       NICE(;-)

I have a cam grinding program somewhere that takes a full 60 sec to load in mach3 and processes over a million lines of code. IF I can find it I will try it in mach4.  It will run proper in Mach3 just takes a very long time to calculate and display the toolpath.

NOW if it could actually MOVE a machine . I am running out of picture shows to watch.

(;-) TP

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 01:06:01 AM
HIYA Steve,  I noticed that when you cut and paste from the gcode editor it does not always hold the CUT in the buffer and when you leave the Editor to paste it somewhere else the paste is EMPTY. Quirk ?? or made that way ??

Would it be possible in teh Gcode editor to have it ADD a "Newline" when you exit ??? This still gets a lot of newbies.

Just a thought, (;-) TP

The clipboard is destroyed when the editor is closed.  It is the same with the LUA editor.  It is a GUI framework thing for which I have not found and answer.  Yet...

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 01:16:59 AM
HIYA Steve,  I noticed that when you cut and paste from the gcode editor it does not always hold the CUT in the buffer and when you leave the Editor to paste it somewhere else the paste is EMPTY. Quirk ?? or made that way ??

Would it be possible in teh Gcode editor to have it ADD a "Newline" when you exit ??? This still gets a lot of newbies.

Just a thought, (;-) TP

Changing the settings in the config does not take effect until "Reset" is pressed.  So look at the modes string to be sure what you think is in effect is actually in effect.  Or, you can code it in your program.

Steve
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on May 06, 2014, 02:07:11 AM
HIYA Steve,  I noticed that when you cut and paste from the gcode editor it does not always hold the CUT in the buffer and when you leave the Editor to paste it somewhere else the paste is EMPTY. Quirk ?? or made that way ??

Changing the settings in the config does not take effect until "Reset" is pressed.  So look at the modes string to be sure what you think is in effect is actually in effect.  Or, you can code it in your program.

Steve


Some defect in wxWidgets implementation, as reported here:
http://trac.wxwidgets.org/ticket/10515
http://trac.wxwidgets.org/ticket/4687

There seems to be a fix for that. I can confirm, that it works ... at least in my Lua scripted Wizard:
http://osdir.com/ml/lib.wxwidgets.wxlua.user/2008-05/msg00008.html


... snip ...
Code: [Select]


function
onCloseEventOccurred(
        event)
    
    --exit frame, if it exists
    if mainframe then
        mainframe:Destroy()
        mainframe = nil
    end

    local clipBoard = wx.wxClipboard.Get()
    if clipBoard and clipBoard:Open() then
      clipBoard:SetData(wx.wxTextDataObject('hello world'))
      clipBoard:Flush()
      clipBoard:Close()
    end
end

function
main()

        mainframe = wx.wxFrame(
wx.NULL,                      -- no parent
                            wx.wxID_ANY,                -- whatever for wxWindow ID
                            "Example", -- frame caption
                            wx.wxDefaultPosition,         -- place the frame in default position
                            wx.wxSize(591, 578),
                            wx.wxDEFAULT_FRAME_STYLE)           -- use default frame styles

      ..

     mainframe:Connect(wx.wxEVT_CLOSE_WINDOW,onCloseEventOccurred)
end


Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 02:21:08 AM
Yes, I did some digging and found the issue.  I really hate GUIs...  :)  It is tested and working.  But thanks for posting that up!  The secret is the Flush().  If you do not call that at the time your app closes, it will destroy the contents of the clipboard.  With a name like Flush() it seems counter intuitive!  So if I ever see an API with flush() in it, I will call it blindly from now on...  

Steve
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 06, 2014, 03:05:03 AM
This one looks like a bug to me. Jogging the cross-hair around the toolpath window is leaving traces. Can you this this please? 

Dan
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 03:11:24 AM
No, that is not a bug.  Brian and I like it!  :)  Actually, it helps us in the development process.  Maybe we can put a switch in to turn it off or something.
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 06, 2014, 03:42:26 AM
If you can, a switch could be nice. Don't like to see my toolpath window full of lines.

Dan
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 08:06:45 AM
M4-1754    Much better Guys !
File Ops. buttons are "hot" while G-code file is running. Should they be disabled and maybe warn "Stop file before ......" like M3  ?

Go to Zero sends all axis' except Z. Is there a Safe Z setting ? Don't understand the "Z Order" entry.

Russ
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 06, 2014, 11:17:19 AM
I am still getting a screen issue with just the top right side of the window
if I minimize Mach4 then open it clears the problem
more of a nuisance and distraction then anything.
 Win7 32bit laptop
Title: Re: Mach 4 Bug Reports
Post by: Jeff_Birt on May 06, 2014, 11:52:07 AM
M4-1754    Much better Guys !
File Ops. buttons are "hot" while G-code file is running. Should they be disabled and maybe warn "Stop file before ......" like M3  ?

Go to Zero sends all axis' except Z. Is there a Safe Z setting ? Don't understand the "Z Order" entry.

Russ


'Z-order' is a GUI setting, not a Z axis setting. If you think of each object on your screen as being drawn on a separate piece of clear plastic then the sheets of plastic are overlaid so you have the items on top covering up the items below them. The Z-order determines the layering of the objects. (I can never remember if zero is on top or bottom though :) )
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 11:56:29 AM
Hiya Steve,  I noticed that the comments do not follow the line order in the gcode window. It will flush all the comments  to the status bar and you never get to see them in order of operation. You can see that they all got displayed from the history window.  Is there any way to lock them to the Gcode line being ran ?

(;-)TP
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 12:06:01 PM
  Don't understand the "Z Order" entry.
Russ


'Z-order' is a GUI setting, not a Z axis setting. If you think of each object on your screen as being drawn on a separate piece of clear plastic then the sheets of plastic are overlaid so you have the items on top covering up the items below them. The Z-order determines the layering of the objects. (I can never remember if zero is on top or bottom though :) )
[/quote]

Hey Jeff, thanks much for that ... and the ENTER and TAB to step through the table you mentioned earlier.
Both new to me. Good to know.  :)
All visible are ordered "0", so on top it must be.

Thanks again,
Russ
 :)
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 12:32:18 PM
HIYA Steve, CANNED cyles

When testing canned cycles I ran into the old A axis moving again. Here is the test code. IF I program G81 when the Z axis moves SO DOES the A. ALSO the Q param does not work in G83/G73 it just just a very small mini peck no matter the Q setting.

Also Is there ANY way to display the ENTIRE active Gcode line ? In the below code when displayed the WIndow cuts off the line just after the Z call on the line with the G81 and you cannot see the rest of the parameters of the call in the window. Maybe a hothey like {F7} to make the entire line visable until you release the HotKey.  OR something else.

G00 Z1.0000
 M3 S500
 G94
 G99 G81 X2.5000 Y0.0000 Z-1.1200 R0.1000 Q0.500 F50.0000 L0
X2.5000 Y0.0000
X0.7725 Y2.3776
X-2.0225 Y1.4695
X-2.0225 Y-1.4695
X0.7725 Y-2.3776
G80
G94
 M30


(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 01:43:57 PM
If you have an offset in place for the A axis, G81 does have an issue.

The line should wrap in the G code window.  Does it not?  It does on mine but maybe there is something different about your machine.  So check it out and let me know.

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 01:47:14 PM
Zorder 0 is the lowest level.  Anything with a higher Z level will be on top of the lower levels.  For example, if you have a bitmap that you wish to place a LED over, the bitmap should be Zorder 0 and the LED should be Zorder 1.

I hope that clears it up because I, like Jeff, keep getting it confused.  But I tend to be a bit lisdexic sometimes...  :)

Steve
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 01:55:04 PM
Zorder 0 is the lowest level.  Anything with a higher Z level will be on top of the lower levels.  For example, if you have a bitmap that you wish to place a LED over, the bitmap should be Zorder 0 and the LED should be Zorder 1.

I hope that clears it up because I, like Jeff, keep getting it confused.  But I tend to be a bit lisdexic sometimes...  :)

Steve

EXCELLENT . Thanks,
Russ

How abot the following ?
M4-1754 
File Ops. buttons are "hot" while G-code file is running. Should they be disabled and maybe warn "Stop file before ......" like Mach3  ?
And,
Go to Zero sends all axis' except Z. Is there a Safe Z setting ?

Russ


Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 02:06:17 PM
If you have an offset in place for the A axis, G81 does have an issue.

The line should wrap in the G code window.  Does it not?  It does on mine but maybe there is something different about your machine.  So check it out and let me know.

Steve

HIYA Steve NO offsets in A here that I can find.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 02:10:59 PM
M4-1754  
File Ops. buttons are "hot" while G-code file is running. Should they be disabled and maybe warn "Stop file before ......" like Mach3  ?
And,
Go to Zero sends all axis' except Z. Is there a Safe Z setting ?

Russ


This is all done in the screen set.  Obviously, the existing screen set has not covered every angle.  And that screen set might not be the "stock" screen either.  We were thinking of having a contest or something for the development of the stock screen set.  The one you are using basically is a clone of the static wxMach.exe GUI interface.  And it has a back story associated with it.  It came from my efforts to produce a G code interpreter front end for the Galil motion controllers over 10 years ago.  Before I even knew of Mach!  It is pretty functional, but it is not frill free at the moment.

Feel free to do up your own screen sets.  I know that is not a simple matter at the moment without documentation.  But that will get there.  As soon as we get out of this stage, I think it will be full on doc time!

I may add a property to all of the controls like "Valid States" where all one needs to do is select the machine states in which the control will be enabled.  But right now, you can handle this type of thing in the PLC script.

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 02:13:06 PM

HIYA Steve NO offsets in A here that I can find.

(;-) TP

There has to be.  Do a G53 G00 A0 in MDI and then zero your A axis.  Then try it.  Works for me. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 02:24:36 PM
M4-1754  
File Ops. buttons are "hot" while G-code file is running. Should they be disabled and maybe warn "Stop file before ......" like Mach3  ?
And,
Go to Zero sends all axis' except Z. Is there a Safe Z setting ?

This is all done in the screen set.  Obviously, the existing screen set has not covered every angle.  And that screen set might not be the "stock" screen either.  We were thinking of having a contest or something for the development of the stock screen set.  The one you are using basically is a clone of the static wxMach.exe GUI interface.  And it has a back story associated with it.  It came from my efforts to produce a G code interpreter front end for the Galil motion controllers over 10 years ago.  Before I even knew of Mach!  It is pretty functional, but it is not frill free at the moment.

Feel free to do up your own screen sets.  I know that is not a simple matter at the moment without documentation.  But that will get there.  As soon as we get out of this stage, I think it will be full on doc time!

I may add a property to all of the controls like "Valid States" where all one needs to do is select the machine states in which the control will be enabled.  But right now, you can handle this type of thing in the PLC script.

Steve

That's all good to know Steve, thanks. I didn't realize it wasn't "The Real thing".  :)
Course I tried to fix it in the screen editor first, but couldn't figure it out.
I'll try not to clutter your inbox with piddly screen issues .... for now , it'll all come together eventually.  :)

Russ :)
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 02:40:42 PM
HIYA Steve , SO there IS and obvious bug in the G81 call.

Thanks (;-0 TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 03:23:13 PM
Yes that is what it is.  G81 is not working right.  We added code in so as to be able to drill on a rotation and it doesn't work in all cases.  If there is no A offset, then all is fine.  Otherwise, A will creep A by the offset amount every cycle.  We will have that fixed in the next update.

Steve
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 06, 2014, 05:02:02 PM
Steve THANK YOU  for fixing the axis DROs entry function. It works well now.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Calum on May 06, 2014, 06:00:37 PM
In build 1754 feed rate now metric, great, but the units for Soft Max and Min on the Homing/SoftLimits tab of Configuration seem to be in inches when machine is set to metric!

The Show Tool Path Limits is still not persistent.

Calum
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 06:50:26 PM

Go to Zero sends all axis' except Z. 

Russ


This is all done in the screen set.  
Steve

Well, I think I found it. (Steve, you're such an instigator  ;D )
 After looking through and trying to make sense of what looks like one of the Dead Sea Scrolls under the the Operator/Lua script, I'd guess there would need to be a Z0 in there as well.  ::)
Can't edit there though, and don't see how to add it.
Is it protected ?
Or ? ? ?.
Thanks,
Russ
 :)
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 06, 2014, 07:26:07 PM
goto safe zero button I created

local inst = mc.mcGetInstance()
mc.mcCntlMdiExecute(inst, 'G00 G90 X0 Y0 Z1 A0')

goto button

local inst = mc.mcGetInstance()
mc.mcCntlMdiExecute(inst, 'G00 G90 X0 Y0 Z0 A0')

look for editing the button script under the "left down script" for the button

though not sure why some scripts show left up and some show left down
not sure when you would use both

think it was whatever the boys felt like that day, but Ya-Nvr-No I might just find a need



Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 07:37:03 PM
THANKS Craig !
So many basics I need to pick up on.
Once you pointed me in the right dir., it looks MUCH more understandable.

Never looked under that little thunder storm before.

Russ
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 06, 2014, 07:37:16 PM
No, it is not protected.  But you sure did sniff out the way to find a lot of thing quickly!  That is the Lua script display that lists all of the scripts that are in the set.

So...  open up Mach 4, and then Operator->Edit Screen

Then click on the Goto Zero button.  You will see it's properties displayed on the left side of the screen.  Over the properties you will see a button with a lightening bolt.  Click on that.  This will change from properties to "events" and choose the "Left Down" script.  click on the ... button and it will open the Lua editor.  

Steve
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 06, 2014, 07:45:49 PM
.... I might join in and be a contender in the upcoming Screen Design event, so don't teach me too much.
Nice work you are doing there, impressive !

Russ

Perfect Steve .... Thanks ! I was just thinking of opening that Lua script after changing the button to see if it changed there too, was assuming/hoping it would.
 I hate to ask dillweed questions, happy you guys are willing to stoop to my level.
I find learning something new very rewarding. I'm easily amazed. (dust in the sunlight is sometimes mesmerizing )
Manual ? ? ? We don't NEED no stinkin' manual.  :) (just kiddin')  ;)

Thanks again Guys,
Russ :)
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on May 07, 2014, 01:48:09 AM
build: 1754 (demo)
system: W7 x64, working on a local drive (no filenames longer than 80 chars)

occurrence 1:
- start fresh instance of Mach4
- click "Open G code file"
- enter non-existant filename into "File name" input box (e.g. testme)
result:
- error box "Load error" containing A general failure occurred while loading testme.tap.
- file testme.tap is actually created in file system
expected result:
- file is created and, if successfully, loaded into system

occurrence 2:
- repeat scenario 1 with different file names so that a few new files are created
result:
- program silently crashes back to desktop after next click on "Open G code file"

occurrence 3:
- start fresh instance of Mach4
- click "Open G code file"
- navigate to directory containing valid G code files (e.g. GcodeFiles subdirectory)
- enter the name of valid G code filename including its extension, e.g. ArcTest.tap
result:
- program reports a "General failure loading" error
expected result:
- file gets loaded if user enters a valid filename including a valid (known) extension
- furthermore, Mach4 could try loading the file by the name entered by the user, then try to attach one of the file extensions
Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 10, 2014, 05:53:49 AM
Just try this and see what results you all get, what I get is very random.

Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 10, 2014, 07:13:30 AM
In the screen designer, you can move controls by using CTRL+Arrow keys.
However, when you move them, their position in the properties window does not update until you click off them. So unless you count key clicks, you don't know where you're actually moving the controls to.
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 10, 2014, 08:43:35 AM
Just try this and see what results you all get, what I get is very random.

Howdy Graham,
I didn't find much info on G9. (new to me and not in the Mach3 list)
Is it a non modal that just invokes an exact stop position for each block that includes it while in CV mode ?
If so, I took the G2's out of your code and ran the file to more closely see the CV vs G9's at the corners and there is no exact stop where where G9 is called.

Nothing random here though ... very consistant.
new 1762 release

Thanks,
Russ
 :)
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 10, 2014, 09:33:21 AM
Build-1762
Run Ops, Single Block selected, Stepping through w/Cycle Start.
After initiating a move, If you happen to hit Cycle Start again before the current move is completed, the Cycle Start button will lock out, requires a Stop or Feedhold before continuing.

Russ
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 10, 2014, 11:02:00 AM
HIYA Craigs , a dual gated button like down/up is used when you need to create a function like an air blast. WHen you push the button down and HOLD(down) it activates the air blast. When you release (up) it shuts it off.

It could also work to jog the spindle (rotation)

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 10, 2014, 11:36:01 AM
HIYA GUYS,G60 doe not seem to work correctly. The #param does not work and the toolpath seems a bit strange for a G60 as I remember it. 

The toolpaths are not consistant with the Gcode intent.  The toolpaths should still follow the Gcode intent from point to point THEN correct for Backlash and proceed.

Just a thought, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 10, 2014, 11:36:58 AM
Terry that makes perfect sense for the up down button script choices.
but, why not just make it a momentary action option button

Thanks
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 10, 2014, 03:08:26 PM
Because then you have to define momentary, 1sec 10sec 100sec ? this way You define momentary by holding down on the button as long as required.

Just a thought, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 10, 2014, 03:19:13 PM
No what I ment was that the button was only active while in the down position.
so button state is always 0 (off) unless pressed and held... that would create a state of 1 (on)
Then Id make all them Blue or Yellow for consistency
and if that function was being called in a program (air on) the button would change color as a visual feed back.
just a PLC script addition

Dont want to have to write scripts for a button down and a button up but if I have too.

your defining a ON or Off delay action depending on how the output is handled from the button press
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 10, 2014, 06:30:11 PM
M48 M49 do NOT appear to work.

(;-0 TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 10, 2014, 11:55:40 PM
There is a problem in this thread milling routine it blows mach4 up and currupts the corrd base.  when it gets to the First G03 call is when it happens. The XYZ values ALL goes from 0,0 to 6937.00000 something in both machine and user coords. Program locks up. AND yes it does it with or without the L5 call @N010

O02301 (THREADMILL 1.5-8 UNC)
(Single Point Thread Milling)
N1 T1 M06 (.5IN DIA THREADMILL )
N2 G00 G90 G40 G80 G54
N3 M01
N4 S5000 M03
N5 X0 Y0
N6 G43 Z0.1 H01 M08
N7 G91 G01 Z-0.5156 F50. (Switches to G91)
N8 G41 X0.25 Y-0.25 F20. D01
N9 G03 X0.25 Y0.25 I0 J0.25 Z0.0156
N10 I-0.5 J0 Z0.125 L5 (Repeats 5 times)
N11 X-0.25 Y0.25 I-0.25 J0 Z0.0156
N12 G40 G01 X-0.25 Y-0.25
N13 G90 G00 Z0.1 M09 (Switches back to G90)
N14 G91 G28 Z0
N15 M05 M09
N16 M30
%

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on May 11, 2014, 01:59:55 PM
hi All
When running Mach 4 mill using G95 (which I often do in Mach 3) it does not display in cuts per rev, is there a simple way round this?
Graham
Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 11, 2014, 04:03:27 PM
Terry,

the line repeat word (Lnn) is only active in subs, macros and canned cycles at the moment, it is on the list of to do's.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 11, 2014, 04:07:39 PM
HI Graham, I figured that and it was not the problem the problem occured at the first G03 on line N9.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 11, 2014, 04:10:43 PM
When running Mach 4 mill using G95 (which I often do in Mach 3) it does not display in cuts per rev, is there a simple way round this?

There is but you need spindle feed back and Simulation in Mach4 has not got this, if you look at the YouTube video Brian and I did over Christmas that show CSS being tested, this was using G95 with G96.

Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 11, 2014, 04:12:39 PM
Here is a screenshot of here it locks up and corrupts the Coord base or something.

Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 11, 2014, 04:13:23 PM
Hi Terry,

just check the M6.mcs M6end.mcs and M3.mcs as the last update had some test code in them that should not have been sent out.  If there is any g-code lines in there delete it.

Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on May 12, 2014, 04:22:30 AM
Thanks Graham
I understand now.
Graham
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 12, 2014, 11:39:15 AM
Th elapsed timer resets every time you press Cycle start. SO on MO M1 or manual tool changes the timer resets to zero when you restart.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 12, 2014, 02:02:10 PM
When writing SUBS you MUST use a Filename format as

o9010            With NO extention.

USING the Gcode editor to write the sub you have NO option to save with NO extention. IF you use the ALL FILE option and do not add an ext it still saves it as *.TAP making the sub unuseable as you cannot call it.

SUBS DO work nice now,  (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 12, 2014, 03:08:45 PM
Elapsed TIME does NOT do elapsed time it does segment time. ANY pause of the program and you cycle start to continue RESETS the timer to ZERO.  There really should be 2 timers here

Elapsed TIme from First cycle start to M30 or M99 end of progam or stop

Segment time should run for the segment of gcode running between cycle starts/pauses (as it does now)  This TIMES the machine when running code

(;-0 TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 13, 2014, 12:17:06 AM
4th axis rotation problem in ABS mode(G90) . A g1 rotates to the nearest point it does NOT follow the gcode

G0 X0 Y0 A0
G90
G1 X10 A359 F50     It moves to X10 and rotates backwards to -1 It should move to X10 and rotate to A359 Via +forward direction not back up to -1.
M30
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 13, 2014, 02:06:43 AM
We are working on a shortest path provision for rotary.  Eventually tied into the Fanuc RINC parameter.  Looks like that code is switched on.  I'll turn it off in the next update.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Calum on May 13, 2014, 05:24:32 PM
In build 1767 there is still a bug with metric conversion.  I have my profile configured as Metric and the motor speed set to 10,000mm/m but G0 or jog show a feed rate of 254,000.

Calum
Title: Re: Mach 4 Bug Reports
Post by: Brian Barker on May 14, 2014, 11:52:13 AM
Update... We now have drill cycled that work with all 6 axis.. Mach3 NEVER had this.. and I am giving it to the Hobby version... Also G60 has been fixed up so it works in drill cycles now.

G73 G83 are fixed as far as my testing can tell.

Thanks
Brian
Title: Re: Mach 4 Bug Reports
Post by: Fastest1 on May 14, 2014, 12:26:27 PM
Give us hobbyists everything we need to become professional! ;-)
Title: Re: Mach 4 Bug Reports
Post by: penkomitev on May 14, 2014, 05:37:55 PM
I've decided to take a look on Mach4 too.

It is just a small visual issue I've encountered.
Mach configuration window.

"Initialization codes" and "Delays" fields are not big enough and part of the values is hidden and we should use the mouse to select it. Also, I doubt anyone here needs such a precise value of the mist and coolant delay. Maybe they should be limited to 1/2 decimals.
Title: Re: Mach 4 Bug Reports
Post by: TDAY on May 15, 2014, 09:50:06 PM
Installed Build 1767
XP Home 32bit
4gb Ram
2.6ghz Dual Core AMD Athlon

When launching Mach 4, window is blank and a pop up window stating "Connecting Toolpaths"  will hang there for at times, 2 minutes. But if i minimize window and then Restore window, pop up window is gone and Mach screen set is loaded.

Another note....Dont know if this is meant to be like this or not, but didnt notice this extra step on the first Build release when configuring the Keyboard plugin.....
Keyboard plugin needs to be enabled and configured, but can not select a key until Mach4 is restarted.
After restart then i can select a key to assign.
Then restart Mach4 again to enable the keys.

Also Mach4 idles at 40% CPU and about 225 MB of Ram

Thanks again,
Troy
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 15, 2014, 10:22:20 PM
Quote
When launching Mach 4, window is blank and a pop up window stating "Connecting Toolpaths"  will hang there for at times, 2 minutes. But if i minimize window and then Restore window, pop up window is gone and Mach screen set is loaded.

I see the exact same thing on 32bit XP

Quote
Also Mach4 idles at 40% CPU and about 225 MB of Ram

The CPU usage is somehow related to what's going on in the screenset. Mine is at 50% with the default screen, but drop to 0-5% with a screen with just a toolpath and a few buttons on it.
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 15, 2014, 10:56:59 PM
You can lower the refresh rates in the screen editor.  Click on the top element in the Screen Tree Manager and it is the "Refresh Interval".  It defaults to 50ms.  100ms would be more of a Mach3 speed.

Steve
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on May 16, 2014, 02:40:24 AM
In build 1767 there is still a bug with metric conversion.  I have my profile configured as Metric and the motor speed set to 10,000mm/m but G0 or jog show a feed rate of 254,000.

Calum

The bug goes deeper than that (experience based on build 1767-2):
Motor configuration does not depend on mm or inch. But whenever I switch to metric system (and restart Mach4), feedrates are magically lowered by factor 25.4 (inch to mm conversion factor) both with Simulator and real device plug-in (ESS).
This is also the case for the output steps on my motor, which doesnt do a full rotation anymore (when in "inch mode"), but only a small fraction of a circle (~ 10 degree).

The only workaround atm is to keep Units mode to "inch". I can live with that :)

Seems to be regression, because metric system worked fine in previous version(s) like in 1529 and 1593. It also seemed to work in 1646, though there the feedrate is multiplied by 4. (Those three versions haev been tested with Sim plugin.)
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 16, 2014, 07:51:47 AM
You can lower the refresh rates in the screen editor.  Click on the top element in the Screen Tree Manager and it is the "Refresh Interval".  It defaults to 50ms.  100ms would be more of a Mach3 speed.

Steve

I tried that, but I went the wrong way.  :o Wasn't thinking clearly last night.
Title: Re: Mach 4 Bug Reports
Post by: TDAY on May 16, 2014, 10:34:40 AM
You can lower the refresh rates in the screen editor.  Click on the top element in the Screen Tree Manager and it is the "Refresh Interval".  It defaults to 50ms.  100ms would be more of a Mach3 speed.

Steve

That worked for me. Launches to a complete screen set within a few seconds and uses about 2-5% CPU with about 10-12MB of RAM. Much better :)

Thanks,
Troy
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 16, 2014, 12:15:43 PM
Just so you guys know...  There is nothing wrong with using CPU.  If it makes the machine more pleasant to operate with faster refresh rates, then there is no reason not to have it.  But there is a limit since we are running on top of an operating system.  I have on machine (pretty new) that I have set to 10ms refresh rates.  My older machines can't take as much.  So we decided to make that a "tunable" setting.  That way, you can get it to run on just about any machine in the XP era. 

It is just not the CPU though.  It has a lot to do with the video card as well.  Some video cards use the CPU to do the video processing!  Those are the ones that will eat CPU like it is going out of style with the faster refresh rates.

Steve
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 18, 2014, 11:00:49 AM
Create a new blank screen.
Add a page.
On the new page, add a bitmap sized to fill the background. Keep the Z order of the bitmap at 0.
Add a DRO on the page, with a Z order of 1.
Save.

When you click the maximize button, the DRO disappears. You can get it to reappear by clicking on it. Occasionally, i've seen a "ghost" duplicate of the DRO next to the actual DRO when clicking on it with Mach4 maximized.

32bit XP Pro.

EDIT:
The "ghost" DRO is the selected DRO text from clicking on it, but it's in the wrong location. The same text (unselected) appears in the correct location.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 19, 2014, 04:23:17 PM
Sometimes running Gcode editor on a OPEN file it will CLOSE back down before you can select the file you want to work with.

(;-) TP
Title: Macro file generation
Post by: FocusPaul on May 20, 2014, 04:13:58 AM
build 1767-2 (Win7 x64)

1. Error message when compiling macro files.
Steps:
Expected behaviour: Mach4 compiles all macros and keeps silent (no error message, because files are generated anyway).

Please see screenshot below. As you can see, path does not contain any special chars or spaces.

2. Unable to use macros in recently created profile.
Steps:
Expected behaviour: Mach4 compiles all macros in test profile.
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 20, 2014, 09:27:45 AM
RRO (rapid rate over ride) does not seem to work with the buttons or keyboard arrow keys. Works well with G0 moves though.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 20, 2014, 11:21:10 AM
IF inside of a G65 macro and you hit STOP it locks up mach4 and you have to use task manager to kill the process to escape.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 20, 2014, 11:28:30 AM
The highlight feature inside the Gcode Editor has stopped working.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 20, 2014, 04:52:53 PM
Mach4 does not like metric it goes mad
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 20, 2014, 07:23:47 PM
Mach4 does not like metric it goes mad

That is because I don't like metric and I go mad!  :)  Seriously though, we are aware of it and we are working on it.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 20, 2014, 07:24:51 PM
1767
KB Jogging "Joystick" style.
Arrows:
UP, then
UP and RIGHT, then (keeping RIGHT key held)
RIGHT, then
Right and DOWN

Locks out the CONTROL Group and the File Ops until shutdown and restarted.

Russ
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 21, 2014, 11:29:46 AM
Hey Steve,

      I think I found a McLua Editor bug see this thread:

http://www.machsupport.com/forum/index.php/topic,27285.msg192716.html#msg192716

Scott

Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 21, 2014, 11:41:10 AM
Gcode editor has a glitch where SOME gcode files load showing the highlights working and SOME load with hightlights NOT working.

I have not been able to find the ryme or reason behind it YET.

The highlights are DARN handy when working in Conditional Gcode.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Graham Waterworth on May 21, 2014, 09:30:59 PM
Highlight only works on .TAP files

Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 21, 2014, 09:39:23 PM
HIYA Graham, NOT the case here. It says it is a *.tap file and loads it as a *.tap file. Just won't show the highlights. I will do some more testing. I will copy the code into a NEW file and save and see what happens.


NOTE: That did it Graham I opened the file, copy and paste into a NEW file and saved. NOW it displays the Highlights


THANKS, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Overloaded on May 21, 2014, 10:02:08 PM
Hey TP,
In the Editor, Edit/Settings, I added .txt and all the selected colors apply to .txt files as well.


Russ
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 21, 2014, 10:08:54 PM
COOL Russ, NOW can you make it NOT add the ext on SAVE so I can program SUBS with it. AS IS I have to use Notepad because IT can save with NO ext.

Thnaks Guys, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 21, 2014, 10:55:45 PM
#vars   #5001-5006 are being output as MACHINE Coords when they should be Work Coords.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Tony Bullard on May 22, 2014, 09:00:55 AM

When I first start Mach4 both the Continuous and Step Mode LEDs are not lit indicating Jog mode is not active but I can still jog. Once I toggle the Jog Mode LEDs until they are both off the Jog is off as it should be.

Tony
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 22, 2014, 08:47:22 PM
Steve here is a MINOR bug, but it does cause some confusion for the "Probers"

The Screen designer, AND the Mach Config for inputs show a "Probe" input (at the very bottom).
The PROBE is not implemented in the Mach4 API, in the API, at the bottom, you would think you would find "ISIG_PROBE" that would follow the CP++ Jog (or maybe it was the CP--), that if it followed the pattern, the PROBE would be next, but the API has the Spindle is running, and spindle is stopped.

Not really sure, if it is worth upsetting the sequential nature of the API for signals, vs. just removing the Probing from the Config & screen designer, since Digitize does the job... and puts the touches in the Reg's.

Scott
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 23, 2014, 05:11:47 PM
Mach4 does NOT show Toolpaths for G65 macros.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 23, 2014, 06:00:07 PM
OK FOUND the reason that the macros do not display. Fanuc macros are not directly useable by MACH4. There are enough differences as to make them not run.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 23, 2014, 06:35:55 PM
Gcode editor does NOT do replace. It says it does and tells you it did nn corrections but does not actually do it. I had to go OUT to notepad to correct the file.

While we are talking about the editor Could it be changed to WHEN you edit a NEW file it does the SAVE and LOADS it back into Mach4. As is it takes a save then you have to go find it and reload it manually.

Thnaks (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 23, 2014, 09:37:48 PM
OK FOUND the reason that the macros do not display. Fanuc macros are not directly useable by MACH4. There are enough differences as to make them not run.

(;-) TP

Care to elaborate?  If you tell us what is different, we will fix it.  If not, we won't know and we can't fix.

Steve
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 23, 2014, 09:51:24 PM
Just a few off hand, Mach4 does not allow "AND" operator(very handy saves a ton on code)

Mach4 does not allow   R I J calls on the same line in arcs . Ifanuc IF the all are present then the R takes precident. Mach4 errors out BUT it will still try to run the code without erroring out(NO Toolpath display).

In some instances how you use the [ ] to define the math is not the same. I will retest that but that is one of the things I usaully have to rework in order to get a Fanuc macro to run correctly.

So far I have NOT been able to get ANY Fanuc macro to run without modifications to suite mach4.

I will start a list here as I test more macros.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: cd_edwards on May 25, 2014, 12:20:33 PM
after running a gcode file with tool changes which seems to stop on occasion when it shouldn't, i closed the Gcode from fileops. The toolpath display cleared all but the last tool change off the display. It should either clear the whole dsplay or none at all. this was with the latest 1767.
Title: Re: Mach 4 Bug Reports
Post by: cd_edwards on May 25, 2014, 12:52:58 PM
Well I re-ran the file again. This time it never stopped until the toolchange. This however showed some odd behaviour. The highlighted line is on the last line of executed movement code. Next line is a M5 and the line after that is the M6 T1.  Tool Change is correctly flashing, but the display is stopped on a line that is not a tool change request.
Title: Re: Mach 4 Bug Reports
Post by: cd_edwards on May 25, 2014, 01:36:25 PM
Something really odd at tool change. It stops, waits for cycle start then proceeds to draw a circle -1.00" in Z still processing the tool change and finally goes off todo the rest of the gcode. admittley I'm not setting my tool length. is that circle there for a reason?
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 25, 2014, 02:17:09 PM
The circle is what's in the toolchange code, so you know it's doing a toolchange. It's just in their for testing purposes.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 26, 2014, 11:08:56 AM
Single block mode needs a little attention. The turning ON works fine as to WHEN and WERE you can turn it on.

 BUT the TURN OFF you should be able to do that ANYTIME. As is it seems to follow the turnON rules.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 26, 2014, 10:25:39 PM
I am posting this here first in case there was a change in the way of "Step through" debugging in the McLua editor in the Hobby version.   Perhaps there was a post some where that noted a change, or there is a bug...

I put this simple function in the McLua and under debug, If I push run, it executes no issues.
But, if I run the debug in the step-through mode, as soon as you hit the F5 key to step through, it crashes the McLua.exe (get the McLue.exe has stopped working).  I have also tried putting just the "Testfunc()" by itself and commenting out the rest of the InEditor func. Again it will run with debug run, but not step through.
 
Steve,

       put this below func in your McLua editor, and see if you can step through it? I have tried breaks at each line as well, but the crash happens after you exit the function...

function Testfunc()
    local inst = mc.mcGetInstance();
    mc.mcCntlSetLastError(inst, '***  Testing  ***');   
end

if (mc.mcInEditor() == 1) then
    Testfunc();
end

--Thank you for looking/testing,
Title: Re: Mach 4 Bug Reports
Post by: smurph on May 27, 2014, 01:09:51 AM
Scott,

It runs fine here.  Load script, hit F5, and I end up at a auto generated break point.  Then I can F10 (step) or F11 (step into) as needed.  I can also hit F5 (continue) and the scripts finishes with a message "Debug session finished."

XP perhaps?  I have not visited the XP VM in a while...

Steve
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 27, 2014, 08:40:00 AM
Windows 8.1, 64 bit here...

the crash happens (McLua editor), when you exit the function, I am using F5 with break points at each line of code.
If you stop right before you exit the function your ok, but if you exit the function the crash happens then.

I have seen a few others post about it, but only a hand full.......  I can work around it, by putting a DummyVar with a debug point right before the end of the func, and then stop debuggin on it...  it was just a little annoying, but not a show stopper.

Scott
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on May 27, 2014, 09:10:22 AM
Win 7 32bit and XP both fail at the end I've just learned to put a dummy line in and stop the debug when i see it.
no luck with scotts DS or DSC programs to step thru.
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 27, 2014, 11:45:26 AM
When you use "Step Through" F11 to run code, it looks for you code in the Macros folder of your profile by default.... so if you have code somewhere else like:  C:\Mach4\MODULES  then to debug your code, you need to use Break Points and F5 through your code, stopping the debugging right before the end of the function so the debugger will not crash...

scott
Title: Re: Mach 4 Bug Reports
Post by: BR549 on May 27, 2014, 12:42:38 PM
SCOTT, all my macros are in the proper folder and it still does that. IF the code is clean and good then no problem.

 BUT if there ARE errors DOWN the rabbit hole it goes.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 27, 2014, 02:03:39 PM
thats why I say, use the Breakpoint/F5 debug mode...... the F11 is just to buggy.

scott
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 27, 2014, 08:36:16 PM
Quote
       put this below func in your McLua editor, and see if you can step through it? I have tried breaks at each line as well, but the crash happens after you exit the function...

function Testfunc()
    local inst = mc.mcGetInstance();
    mc.mcCntlSetLastError(inst, '***  Testing  ***');   
end

if (mc.mcInEditor() == 1) then
    Testfunc();
end


Works fine here. Step thru no problem. Win7Pro 64 bit  Note: (MACH4 run as administrator)
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 27, 2014, 10:21:06 PM
are you using the F11 key?
F5 step through on break points works great..

hmmm, I will check to see if I am running m4 as admin.

Scott
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 27, 2014, 10:34:56 PM
Hey Simpson36, I tried runing m4 as admin, but again, at the VERY end of the F11's (after the last line of the calling function at the bottom). It crashes the McLua interpreter.  The running as Admin, DID help in it did not immediatly crash as you press the first F11.... 
Can you run this slightly, busier code, in your McLua and see if you can F11 to the very end, and even start over again...
I am running W8.1, 64bit (and running M4 as admin).

function Testfunc()
local inst = mc.mcGetInstance();local rc = 0;
local Xaxis = 0;local Yaxis = 1;local Zaxis = 2;
local dirP = 1; local dirN = -1;
    mc.mcCntlSetLastError(inst, '***  Testing  ***');

    rc = mc.mcJogSetRate(inst, Xaxis, 0.10);
    rc = mc.mcJogSetRate(inst, Yaxis, 1.00);
    rc = mc.mcJogSetRate(inst, Zaxis, 100.00);
   
    rc = mc.mcJogVelocityStart(inst, Xaxis, dirP);
    rc = mc.mcJogVelocityStart(inst, Yaxis, dirP);
    rc = mc.mcJogVelocityStart(inst, Zaxis, dirP);
    wx.wxSleep(1);
    rc = mc.mcJogVelocityStop(inst, Xaxis);
    rc = mc.mcJogVelocityStop(inst, Yaxis);
    rc = mc.mcJogVelocityStop(inst, Zaxis);
end

if (mc.mcInEditor() == 1) then
    Testfunc();
end
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 28, 2014, 12:57:58 AM
Hey Simpson36, I tried runing m4 as admin, but again, at the VERY end of the F11's (after the last line of the calling function at the bottom). It crashes the McLua interpreter.  The running as Admin, DID help in it did not immediatly crash as you press the first F11....  
Can you run this slightly, busier code, in your McLua and see if you can F11 to the very end, and even start over again...
I am running W8.1, 64bit (and running M4 as admin).

function Testfunc()
local inst = mc.mcGetInstance();local rc = 0;
local Xaxis = 0;local Yaxis = 1;local Zaxis = 2;
local dirP = 1; local dirN = -1;
    mc.mcCntlSetLastError(inst, '***  Testing  ***');

    rc = mc.mcJogSetRate(inst, Xaxis, 0.10);
    rc = mc.mcJogSetRate(inst, Yaxis, 1.00);
    rc = mc.mcJogSetRate(inst, Zaxis, 100.00);
    
    rc = mc.mcJogVelocityStart(inst, Xaxis, dirP);
    rc = mc.mcJogVelocityStart(inst, Yaxis, dirP);
    rc = mc.mcJogVelocityStart(inst, Zaxis, dirP);
    wx.wxSleep(1);
    rc = mc.mcJogVelocityStop(inst, Xaxis);
    rc = mc.mcJogVelocityStop(inst, Yaxis);
    rc = mc.mcJogVelocityStop(inst, Zaxis);
end

if (mc.mcInEditor() == 1) then
    Testfunc();
end
Steps thru fine using F5 to start and F11 to step

No crashes and can start over again with F5.

Running build 1767  - Modbus TCP is active and running exchanging data with external processor

Exact sequence:

Start MACH4
Operator -> Edit/Debug scripts -> open M6
File -> New
Paste in entire content of your script
Save as  C:/Mach4Hobby/Subroutines/Papa.mcs
F5 (or click either works) to start debug
F11 step thru to end
Can repeat no propblemo.

Result window capture attached. The word 'error' in a little box is showing up later during the screen snip . . not sure where that's coming from, but it is not present during the debug cycle . . shows up while saving the snip . .  weird

Edit: the screen has a couple of buttons added that just read and write a few Modbud regs. Otherwise box-stock as delivered. Doubt the buttons would have much effect, but who knows . . . .
 
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 28, 2014, 07:43:37 AM
well let me ask to beat a dead horse one more time...
can you make sure there are NO debug point breaks in the scripter, start the debugger, then F11 until it loops...

If your's still works, then there must be something in W8, 64bit (w8.1 technically).......  I am running the same M4H version as you are, and I am running the Stock OEM MachMilll profile and Screenset without any modules or anything else active...  Just to make sure nothing else is running...

kinda frustrating..
Not really a show stopper, since with breakpoints, F5 and NOT exiting the funciton, but hitting the stop debug before the end (on the dummyvar), I can still debug...  A mystery I guess.

Scott





Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 28, 2014, 10:09:38 AM
well let me ask to beat a dead horse one more time...
can you make sure there are NO debug point breaks in the scripter, start the debugger, then F11 until it loops...

If your's still works, then there must be something in W8, 64bit (w8.1 technically).......  I am running the same M4H version as you are, and I am running the Stock OEM MachMilll profile and Screenset without any modules or anything else active...  Just to make sure nothing else is running...

kinda frustrating..
Not really a show stopper, since with breakpoints, F5 and NOT exiting the funciton, but hitting the stop debug before the end (on the dummyvar), I can still debug...  A mystery I guess.

Scott

Scott,

You probably know there is a 'auto' breakpoint, but other than that, there were no break points set. F11 steps thru the entire file as you can see by the snip I posted. I don't know a lot about Lua at this point, but from what I read, it can be a stickler about file locations. I have another 'C' ish Programming environment that's like that. Compiles fail because it can't find Includes and the files are right there. Alas, the compiler is looking for them in some obscure place and I have found no way to change that. It *might* be that Lua is similarly arranged, but the errors are not exactly verbose, so you don't get much of a hint as to what its unhappy about. At least with the other one, I get the full path where the thing is looking for the file. Did you follow (exactly) the sequence I posted including the file location and name?

FWIW I had two issues with 64 bit Win7 pro (be sure to mention pro if it is. they are different).  Both were Modbus related as that's what I was working on at the time. Seems unlikely these would be crashing the editor, but its all I have to offer, so here it is:

Win7 was blocking the Modbus traffic. You mentioned frustrating . .  MACH4 reported 'Modbus0 ok' and displayed a loop rate . . . but it was talking to a black hole . . nothing was getting in or out, and each of the  data types (MACH4 calls them 'functions') was error red. I don't know what Modbus uses to check operation, but it's not closed because Modbus thinks it is talking to someone and there's nobody home. In any case, Run as Admin removed the guard dog and things started working.

It occurs to me that if you were running without being admin, the files you made *might* not have enough permissions, so you should check that also. If you follow my sequence exactly that potential would be eliminated. Long shot, but the problem is in your system and you are down to shots in the dark, so it can't hurt.

My other problem was with the network config. Once I had Modbus TCP running, in order to plug both the Processor and the main network into the machine without having to flip back and forth (reconfiguring TCP4 each time) I set up my single NIC with two hard coded IP. Even tough the Modbus IP is hard coded in the config, MACH4 Modbus *apparently* was trying to get data from the Internet side IP and not the connected processor IP (if that makes any sense).

I stuck a second NIC in the machine and configured it hard coded 2dn network to the external processor and restored the main network (rounter,internet) to auto IP, etc. Modbus stays focused on the 2nd hard coded net and all runs well, and simultaneously. I don't know what the actual problem is, but a $40 NIC card solves it, so I'm not inclined to pursue it beyond that. The MACH4 TCP Modbus will literally run for days on end while I do all of my regular work on the same computer. Impressive.

Again, it seems hard to imagine these issues would be effecting the Lua editor, but the network setup confused the Modbus comms, and as I mentioned earlier, the editors seem to be picky about file locations, so its a long shot, but maybe Lua is checking the network for libraries or something like that. Perhaps it was set to look for libraries on a network by the developers and inadvertently left that way?

That's about all I can think of. Sorry all guesses.

Meet the new Boss . . Same as the Old Boss.
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 28, 2014, 01:42:12 PM
I will move stuff to the default "macros" folder under the profile to see if the default file locaton makes a difference....
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 28, 2014, 09:10:30 PM
well, no matter what, I have tried, at least for me, F11 no-worky... 
so, F5 with breakpoints it is........ I have even done a bone stock OEM M4 with freash install, and still crashes the McLua interpreter..... It may be it just no-worky with W8.1 (64bit), or maybe it is just the Ecno-Rays reflecting off my Tin-Foil Hat, from the Giant Grey Space Ants that it causing it to crash...

oh, well...

Scott
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 29, 2014, 04:46:36 AM
   . . . .. . .  from the Giant Grey Space Ants that it causing it to crash...


You know, it would have been nice if you mentioned the GSA (Grey Space Ants) right at the outset. GGSA interference is right there in the Lua docs. You can shield against GSA, but after they move thru the power lines outside town, and quadruple in size becoming GGSA . . . no good . . they gotta go. Call the ARMY. Tell them to send at least two jeeps, one bazooka and a Walkie Talkie. Couple extra grunts for Ant Fodder is helpful. Oh yeah and they should all be in Black and White.  

Moving on to Win8. I tried that guy when the trial version was released. Took it back off pretty quick and purchased another Win7pro. I'd be inclined to blame Win8 for everything and anything including global warming . . . .  except that others are having similar problems with Win7 and earlier.  Actually, Win8 did have one redeeming characteristic; the remote log-in is Uber fast and smooth. WAY better than Win7. You can run AutoCAD on a remote computer with Win8 and the response is equivalent to it being local. Very choppy with Win7.

Anyway, WIn8, couple of things come to mind that you might try;

I don't recall if Win8 has the 'compatibility mode' like Win7 pro. If it does, you might try setting the MACH4 compatibility to Win7 or earlier.  

With Win7 pro, Aero causes trouble with some apps, but it can be turned off. I do not recall of the WIN8 GUI can be turned off also, but if it can, you might try that. I do seem to remember Win8 having some sort of 'classic' look that can be turned on. Lua might like that better.


Of course, you'll need to address that Ant problem first.  
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 29, 2014, 06:20:11 AM
I use "Classic Shell" it is a 5 dollar app that turns W8 into W7 as far a look and feel to, you have to spend about 3-4 hours going into mmc (another hack install), to turn off all the "Other stuff", and MS trying to force you to use the MS online log in sh!t. At any rate, at this point, I will just live with it, I have wasted far to much time on it at this point, for really no gain. I sure that Steve will figure out where the "Bad Binding" is like he finds other Bugs.... I mean GSA's....  Just call him the Orkin Man!

Scott
Title: Re: Mach 4 Bug Reports
Post by: cd_edwards on May 29, 2014, 12:49:45 PM
Just tried your first script on a Win 7 ultimate install over a Microsoft Remote Desktop connection from my mac.  I couldn't use F11/F10 because they are not passed through to the remote. I used F5 to set q breakpoint on line 7 I believe it was The call to the TestFunc(). Then I used the menu system to single step through the function. Real pain but it stepped all the way through and done.

Compilation successful!
Output: "C:\Mach4Hobby\papa.mcc"
Waiting for client connection...
Client connected ok.
At Breakpoint line: 4 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 1 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 6 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 7 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 2 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 3 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 4 file: C:\Mach4Hobby\papa.mcs
At Breakpoint line: 8 file: C:\Mach4Hobby\papa.mcs
Killed debuggee process 7984.
Debug session finished.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on May 29, 2014, 01:46:27 PM
Hi All
Just fiddling about with a program for no particular part.
Should this program end at x2.875 y0 for a .25 cutter for a 3inch dia circle.
Graham
Title: Problem with storing WIZARDS in mach4
Post by: BR549 on June 01, 2014, 05:03:16 PM
OK I see a problem with HOW mach4 wizards are stored. It seems that you dump everything into the wizards folder and then Mach4 sorts it out. This can leave all sorts of BMP images laying around with no real idea of what belongs to what.

Can we go BACK to the format that Mach3 uses where ALL the data for a wizard is stoerd in its OWN SUBfolder off the Wizard folder.


Mach4hobby\\Wizards\\  Wizard1
                              \\  Wizard2
                              \\   Wizard3
 ETC,ETC
                                   
Title: Re: Problem with storing WIZARDS in mach4
Post by: BR549 on June 01, 2014, 05:51:36 PM
I also noticed that IF you compile the wizard MACh4 does NOT see it in the folder.

Just a thought, (;-) TP
Title: Re: Problem with storing WIZARDS in mach4
Post by: poppabear on June 02, 2014, 08:24:38 AM
Terry put folder that are named for your wizard, and put your resources like Pics and stuff in them, then in your wizard script,
change the path that it goes to to get the pic or what ever......

scott
Title: Re: Problem with storing WIZARDS in mach4
Post by: BR549 on June 02, 2014, 10:43:58 AM
Scot that does not do anything for IF I share that wizard(;-). The whole idea behind the wizards are to share correct??? WHy make it so hard to do so?

(;-)TP
Title: Re: Problem with storing WIZARDS in mach4
Post by: poppabear on June 02, 2014, 11:23:52 AM
no hard, copy wiz, and folder to client... done
Title: 4th AXIS toolpathing
Post by: BR549 on June 02, 2014, 08:13:36 PM
HIYA GUYS IS 4th axis tool pathing coming along soon? I have some testing in that area to do.

Thanks (;-) TP
Title: Re: 4th AXIS toolpathing
Post by: Brian Barker on June 03, 2014, 03:06:04 PM
I have been working on tool tip comp for Turn.. Now that it is done I was thinking about going back to the toolpath code to get the 4 Axis path to work.

So much to do so little time!
Brian
Title: Screen /screen Editor problem
Post by: BR549 on June 04, 2014, 11:10:44 AM
There is a problem when using Bitmap images in mach4. I have a screen that I created a Tool Life Management page. On the far right of teh page ,about where the toopath section is on the first page I placed the image of the tool that is use . Looks fine BUT when I SAVE THE SCREEN AND IT REOPENS the BMP image bleeds out into the 1st page(program run). I can click on the TLM page and then back to program run and it dissapears and looks to be ok.

The problem IS I can no longer access the toolpath functions. I can zoom,pan etc AND the buttons below the toolpath do NOT work.

SO  I went back and removed the IMAGE on the TLM page and everything works fine. THEN put the image back and it blocks the toolpath functions again and the image on loading of mach4 bleeds over into the Program RUn page.

I have tried every order of Zorder that I can think of with NO CHANGE.

(;-) TP
Title: system errors displayed
Post by: BR549 on June 04, 2014, 11:26:08 AM
Normally the Status line displays the GCODE messages AND in the case you have an error the error "Number" OR just an alert meassage letting you know there IS one

System ERROR  6503
System ALERT LUA Error
System ALERT WxLUA Error
etc,etc,

THEN you hop over to the error page to view the errors.

As is the system errors WERE to long to even READ and NOW they are too small to read. COULD we seperate the two functions Gcode messages /System Errors

I did add a page to the Screen to test the idea and it works well.

Just a thought, (;-) TP

Title: Single Block
Post by: BR549 on June 04, 2014, 12:03:30 PM
Glad to see it does NOT crash anymore. I do have one suggestion in how it works. When you have single block SET and you are stepping though code you SHOULD be able to release it by just pressing the Single block button again and then CYCLE Start one last time(safety) and off it goes slinging chips.

As is you press Feedhold then STOP and THEN you can press single block to release it.

Just a thought, (;-) TP
Title: Re: system errors displayed
Post by: BR549 on June 04, 2014, 12:06:22 PM
Does anyone know if there is a Lua call to access the Status History window. I see there is a BUTTON call but that is not what I need.

OR can you call the BUTTON from a script like the old DOButton() Mach3 call ?

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on June 04, 2014, 12:20:58 PM
OK so nobody seems to know. Is it the program or Mach 4?
Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on June 04, 2014, 12:28:20 PM
When using cutter comp, you need a proper lead in and lead out move. What you have there is some bad code, and there's no way to tell where it should end.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on June 04, 2014, 12:31:13 PM
Thanks Gerry
At least now I know.
Graham
Title: Re: Screen /screen Editor problem
Post by: Ya-Nvr-No on June 04, 2014, 07:01:44 PM
Might try pages and use the BMP as the default page and then the other dro's and files on separate pages then try the Zorder.
Title: Error on startup build 1817
Post by: Bodini on June 04, 2014, 07:45:08 PM
Just installed 1817, uninstalled 17XX first (even deleted the folder that the uninstall did not delete).

I am getting an error on start up: "File 'C:\[OEM PATH HERE]\macros\mcLua.mcc' couldn't be removed (error 0: the operation completed successfully.)"

I dont see mcLua.mcc in the macros folder. Sounds like thats what the error is about.  Known problem or did I do something? ???

addendum:  now i am getting this error too if i edit a script and then run it in the editor.  the editor crashes too.

addendum 2: now i see that it gets this error if i do not save the script before i run it in the editor.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on June 04, 2014, 07:55:54 PM
OH I fought with that one last night for about about 2 hours. It will ERROR everytime you push a button or try to do a function.

EVEN if you put THAT file back where it says it should be you will STILL get that error.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on June 04, 2014, 07:57:37 PM
1817 used LUA 5.2  So we shipped it without the *.mcc files to ensure that they get rebuilt.  Once you press Start Cycle, they will build and the mcLua.mcc will be created.

The mcc files are not compat between LUA 5.1 and 5.2.  So if you have any scripts that you wrote, delete all of the mcc files and let them rebuild.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Bodini on June 04, 2014, 08:25:12 PM
 Once you press Start Cycle, they will build and the mcLua.mcc will be created.

Hi Steve,

I dunno... mcLua.mcc is not being created here.  Start Mach4, load roadrunner, press cycle start, let it run, stop it...  Still no mcLua.mcc in C:\Mach4Hobby\Profiles\Mach4Mill\Macros folder.  Close Mach, restart it... the error persists.

-Nick
Title: Re: Mach 4 Bug Reports
Post by: smurph on June 04, 2014, 08:32:37 PM
It is because some mcc file is still in there somewhere when it tried to roll all of them up into the one big mcLua.mcc file.  Incompatible mcc files prevent this from happening. 

The rule of thumb is if there is no mcLua.mcc file, then there is an error in at least one script or the mcc files are incompatible.  Those are the only two instances we have found that prevent the mcLua.mcc file from being built.   

Be sure that if your scripts reference any scripts external to the profile (like in Mach4/Modules dir), that those scripts also have their mcc files deleted.  You may have to compile external scripts in the mcLuaEditor as the auto compile will not work for scrips outside of the macros dir.

Steve
Title: Loading SUBS or G65 macro
Post by: BR549 on June 04, 2014, 10:11:01 PM
OK I found the problem in the M98 calls it seems Mach4 Fails on the starting of 2nd nest of the Sub. It does NOT even start the 2nd level.

It SHOULD be able to do 4 levels of sub nesting. Most modern controller do MUCH more levels of nesting.

(;-) TP
Title: Serious problem with G65 #vars
Post by: BR549 on June 05, 2014, 12:01:53 AM
When you call G65 for a MACRO you are allowed to set #vars through Letter calls   A-Z  == #1-#26.  During the G65 call is the ONLY time you should be able to make the Letter calls update #vars.

In Mach4 ANYTIME you use a Gcode word X Y Z A B C U V W G F H M N Q P R S L etc ,  you are updating the #1-#26 VARS. This SERIOUSLY messes up the parametric Gcode in the G65 macro.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Bodini on June 05, 2014, 12:03:29 AM
It is because some mcc file is still in there somewhere when it tried to roll all of them up into the one big mcLua.mcc file.  Incompatible mcc files prevent this from happening. 

The rule of thumb is if there is no mcLua.mcc file, then there is an error in at least one script or the mcc files are incompatible.  Those are the only two instances we have found that prevent the mcLua.mcc file from being built.   

Be sure that if your scripts reference any scripts external to the profile (like in Mach4/Modules dir), that those scripts also have their mcc files deleted.  You may have to compile external scripts in the mcLuaEditor as the auto compile will not work for scrips outside of the macros dir.

Steve

Hi Steve,

Reading what you wrote there and kind of understanding some of it I did exactly this and nothing more...

Uninstalled Mach4 1817, deleted folder.
Reinstalled M4 1817.
Started M4. No error.  looked in the macros folder and I see m3, m6 and m6end: mcs and mcc files.
Loaded arctest and ran it.
Closed gcode. Closed M4.
Reopen M4.  The error shows on load up.
Close M4.
Delete the m3, m6, m6end mcc files.
Open M4.  M3,m6, m6end mcc files are created.  mclua.mcc is created.  This error comes up: 
23:55:25: Failed to open 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m3.mcc' for reading (error 0: the operation completed successfully.)
23:55:25: Failed to retrieve file times for 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m3.mcc' (error 0: the operation completed successfully.)
Ok that error box.  Then this error comes up:
23:55:25: Failed to open 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m6.mcc' for reading (error 2: the system cannot find the file specified.)
23:55:25: Failed to retrieve file times for 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m6.mcc' (error 2: the system cannot find the file specified.)
23:55:25: Failed to open 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m6end.mcc' for reading (error 2: the system cannot find the file specified.)
23:55:25: Failed to retrieve file times for 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\m6end.mcc' (error 2: the system cannot find the file specified.)
23:55:25: File 'C:\Mach4Hobby\Profiles\Mach4Mill\Macros\mcLua.mcc' couldn't be removed (error 2: the system cannot find the file specified.)
Close M4.
Reopen M4.  No errors.

I'd bet none of that is a surprise to you but it sure is a lot of hoops to jump through for your average user. ;-)

-Nick

Title: Re: Mach 4 Bug Reports
Post by: BR549 on June 05, 2014, 12:28:25 AM
THIS is about the 3rd time today I got this error. HOW should I respond ???

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: smurph on June 05, 2014, 02:20:35 AM
Choose no.  For some reason, I linked with the debug code in that last build. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on June 05, 2014, 02:41:40 AM
Nick,

Normally, the macros will not have the issues you are seeing.  The reason why you are seeing them now is that we changed LUA versions between build 1767 and 1817 and there are incompatibilities with the compiled scripts between the versions.  Normally, the installer will install the macros with mcc files that work and there will be no issues.

For the macros, Mach uses the mcc files.  The mcs files are just a way of getting to the mcc files that us humans can read and modify.  Mach can run without ANY mcs files if the mcc files are compiled and correct. 

Changing LUA versions is not something we will do once we release.  We just made a push to get to the latest code base for everything we use so that we don't feel the need to do it at a later date after release.  In the future, a normal user should never see this.

Build 1817 has a whole host of changes including a move to wxWidgets 3.0, LUA 5.2, and we went from using the static CRT to the dynamic CRT.  Hence the massive difference in build numbers.  I also did a wholesale change on the API (I'm so glad I haven't re-written the API docs again!).

We have one more big change to do before release which is the installation location (feature request and docs not withstanding).  We are planning to conform to MS program installation locations so that Mach will be installed in the "Program Files" for system wide operation (requiring Admin privs) or it can also be installed in a user folder without admin privs.

Steve
Title: Re: Serious problem with G65 #vars
Post by: ger21 on June 05, 2014, 07:10:46 AM
Would it not be better to use the Bug Report thread rather than starting all these new threads?
Title: Re: Serious problem with G65 #vars
Post by: BR549 on June 05, 2014, 09:15:15 AM
I guess you are right it does look bad for all these problems showing up. I'll move back over to the Bug thread .

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on June 05, 2014, 09:26:35 AM
I vote for a user folder and NO admin KEEP it all together like Mach3 was. Very easy to deal with.

Just my 2cents worth, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Bodini on June 05, 2014, 09:36:17 AM
Changing LUA versions is not something we will do once we release.  We just made a push to get to the latest code base for everything we use so that we don't feel the need to do it at a later date after release.  In the future, a normal user should never see this.
Great!  As long as you know about the problem and plan on doing something about it, then case closed. Thx for the reply.
Title: Re: Mach 4 Bug Reports
Post by: poppabear on June 05, 2014, 06:19:29 PM
Steve the mc call below errors out:

local inst = mc.mcGetInstance();

buff, rc = mc.mcCntlGetStateName(inst, 4);
--4 is the Machine state of Jogging, this func should give the String Name of what the #4 means.

Scott
Title: Re: Mach 4 Bug Reports
Post by: ger21 on June 05, 2014, 07:57:50 PM
V1817
XP Pro

I uninstalled the previous version, and installed the latest. The first time I run it, it seems fine, after closing and restarting, I get this error every time.
Clicking OK doesn't appear to do anything, but if you wait about two minutes, Mach4 will eventually start.

EDIT:
Sorry, I didn't realize this was already posted.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on June 06, 2014, 04:34:00 AM
Goodmorning.

Why does the tool path not display in the "TOOL PATH DISPLAY" window, it does in the "PROGRAM START" window.

If you run in single block with blank lines in a program you have to press cycle start to pass them, if you have more than one blank line following another you have to press cycle start equal to the nombert of blank lines.

I too get strange errors on starting as stated earlier, but do not understand them not being a professional expert.

Graham
Title: Re: Loading SUBS or G65 macro
Post by: dude1 on June 06, 2014, 05:36:14 PM
i have been playing with the macros i have found that there is a lot of changes to to get fanuc macro to work.
I then had a look at the haas macro and they work really well just one or two simple changes to do to get them to work.
Title: IsStill is still wonky
Post by: Bodini on June 07, 2014, 09:09:30 PM
There was talk of IsStill being fixed for the "next release" (1817) here --> http://www.machsupport.com/forum/index.php/topic,27254.msg192453.html#msg192453 (http://www.machsupport.com/forum/index.php/topic,27254.msg192453.html#msg192453)

But IsStill is still having issues.  :P

This works
Code: [Select]
inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "g91 g1 x1") --execute gcode
while (mc.mcCntlIsStill(inst)==1) do  --loops through this while an axis is moving
    mc.mcCntlSetLastError(inst, "axis in motion") --do this while axis is moving
end  --ends the loop
mc.mcCntlSetLastError(inst, "axis is stopped")  --continues here after axis is done moving
mc.mcCntlGcodeExecute(inst, "g90") --execute gcode

This does not.  Only difference is the last line.
Code: [Select]
inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "g91 g1 x1") --execute gcode
while (mc.mcCntlIsStill(inst)==1) do  --loops through this while an axis is moving
    mc.mcCntlSetLastError(inst, "axis in motion") --do this while axis is moving
end  --ends the loop
mc.mcCntlSetLastError(inst, "axis is stopped")  --continues here after axis is done moving
mc.mcCntlGcodeExecute(inst, "g91 g1 y1") --execute gcode

It doesn't crash, but it becomes unresponsive as if it was moving the axis (although I dont think it gave the error message during the function), but nothings happening on the DROs.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on June 13, 2014, 05:13:27 AM
Hi All
Re my problems reported on the 6th.
Are there any answers????
Graham
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on June 30, 2014, 04:49:45 PM
Just tried version 1872, still got the same problem.
What am I doing wrong??????????????

Graham
Title: Re: Mach 4 Bug Reports
Post by: smurph on June 30, 2014, 05:28:36 PM
Graham,

As far as the tool path not showing in the other window, it may be a video card or driver issue.  We only use 1 vertex buffer to display ALL tool paths.  If it not displaying in all tool paths, it is probably something to to with your video card's OpenGL implementation.

Let me know your machine specs.  video card manufacturer, memory, OS, etc...

Blanks lines and single block:  Right now, each line is a line regardless of if it contains G code or otherwise.  I will try and see if I can make it loop through the blank lines.

Also, when asking about a previous post, if you would quote it that would be awesome.  It will help make sure I'm actually answering the right question.

Steve
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 01, 2014, 04:41:44 AM
Morning Steve
Is this what you want?
Mach4 only displays toolpath in the  program run window, none of the others.
Graham
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 01, 2014, 09:32:28 PM
Graham,

It looks like you are suffering from shared memory video card syndrome.  :(  Do this for me...  open task manager and see what your computer uses, memory wise, while idling.  No programs loaded.  And let me know what it is.  

Here is what I think is happening:  You have a 64 bit OS that is attempting to run on 3 Gig of memory.  If it idles at 2 Gig (not uncommon) that leaves only less than a Gig of memory to run a program AND process video.  It may simply not have enough memory to do the job.  So something gets culled.  

It could also be a driver issue as well.  Check and see if there is an updated video driver from Intel.

Shared memory video cards are always a compromise.  But that is what they seem to be putting in computers these days.  I bet if you look at your Windows Experience Index that the video is what is keeping you at a 3.3 WEI.

Steve
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 01, 2014, 10:05:04 PM
Quote
Shared memory video cards are always a compromise.  But that is what they seem to be putting in computers these days

Most modern consumer PC's use the Intel graphics in the CPU. There is no video card.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 02, 2014, 12:21:57 AM
I should say graphic device.  The stuff I'm talking about is the "on-board" integrated GPU that has to use the CPU to move video data and use system RAM as video memory.  In stark contrast to a GPU with dedicated DRAM2/3/4 memory for video, on-board or otherwise.  A lot of the newer PCs are built to a price point.  Also, some integrated Ethernet devices are all bunk too.  They will stream data down to the PC fine but they have very little, if any, ability to stream data from the PC.  What you get is a PC that will surf the web really well but suffers doing other tasks.  Which is fine for most people's computer needs these days. 

I was working with a guy today on a similar issue.  Same Intel GMA4500 integrated GPU with a really nice I3 processor.  A "modern" computer as compared to my old clunker.  He could load a fairly large Gcode file and run well with it.  But then he loaded a Solid Cam high speed tool path that consisted of 38,000 lines and the CPU went from 2-3% to 25% and the user interface got clunky.  Why?  Because the CPU was having to shuffle data in the system RAM to the video card because the tool path got larger than it's 128 MB dedicated memory buffer.  Now, contrast that to my 7 year old PC with ATI video cards with real dedicated memory where I loaded a 138,211 line G code file and ran like butter with 1-2% CPU load.  His computer's got 5 time the CPU power I do but it performed much worse!

So be wary of the computers you purchase if you intend to do anything other than web surfing, word processing, and email.  Computers are a lot like cars.  And these new ones have fire breathing CPUs (engines) in them for sure.  But if the rest of the components don't match up (bad exhaust or intake), then there will be a bottle neck.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 02, 2014, 01:59:50 AM
Hi Steve,

I’m not whining or decrying anything but surely most of us home users will have the average ‘modern’ computer.

If Mach4 has been designed (intentionally or otherwise) only to run ‘properly’ on a defined specification computer this gives me great cause for concern.

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 02, 2014, 05:38:35 AM
Hi All
I agree with Tweakie totally.
If I get Mach4 will I then have to get a new computer/graphics card.
I run my machine on a very old XP computer but it has got an added graphics card.
I have checked and have the latest drivers on the computor running Mach4.
Attached is my task manager at idle.

Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 02, 2014, 07:11:34 AM
You can't have your cake and eat it to. In Mach3, you have to turn off the toolpath to run large g-code files. With Mach4, you should be able to use very large files, but you're going to need to use a $100 video card.
I'd much rather need to buy a video card than have Mach4's toolpath display capabilities reduced to accomodate cheap pc's.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 02, 2014, 11:56:02 AM
We are not programming any differently than we have in the past.  The computers that you guys are buying are changing.  We cannot help that the manufacturers are putting this stuff in them. 

It quickly becomes something that is out of our control.  If a user loads a file that creates a tool path that is larger than what the dedicated memory his video subsystem has, then there is GOING to be a performance issue.  I think it is absolutely horrid that my 7 year old clunker of a computer can run a large file better than the bran new hot off the shelf computer.  It's ridiculous!  What WAS normal for a computer is now not so normal. 

Mach 4 is not programmed for a defined specification other than OS >= XP and we we would like something that has at least OpenGL 1.5 capabilities to run the tool path.  If it doesn't, we simply switch to the older, yet slower, method of rendering the tool path.  The problem comes in where the video device says that it can do OpenGL > 1.5 but does it poorly.  We have no way of knowing this.  Mach 4 does take more memory though and that is a product of being different that Mach 3 (new GUI with more controls, etc...).

We have done a lot of things inside the software to allow it to run on older systems.  For example, you can change the screen refresh rates to better match the capabilities of older hardware.  But the one thing we cannot do is account for the fact that Mach 4 does require more memory.

So let me assure you guys that we are not intentionally doing anything to hold a spec other than what I described.  We are just programming the way we always have.  And we are finding some of this stuff out for the first time.  And not just with Mach 4.  I installed Mach 3 on a new computer that runs an Ethernet Galil.  Imagine my surprise when it would not run a smooth part that the old computer that it replaced had no problem with!!!  The crappy little RealTek on-board Ethernet would not stream data to the Galil reliably!  It had huge receive capabilities but chump for send.  A whopping 64K TX buffers vs. the 2048 that the old computer with the on-board Intel Pro-100 Ethernet had.  Was I pissed?  Yes.  But not at Mach 3.  I was pissed that the new computer was not nearly as capable as the old one.  Lesson learned.  New means new.  New does not mean good.

So "Modern" doesn't mean squat, IMHO.  I bought a "modern" plastic float and valve assembly for one of my toilets they other day that is simply awful as compared to the brass one that was in it.

Like I said, most of these new consumer grade computers are designed for the average person that wants to get on-line, surf the internet, do the face book thing, maybe a few forums here and there, and do some email.  And they do that well.  Because it is their target market.  We simply cannot help that they don't do Mach 3 and 4 well.  We are not the ones putting the hardware in those computers.  So please don't shoot the messenger.

Can you still buy a computer that works well?  Yes.  But you have to look for them.  So now you have to look at the specs other than the processor.  I bought a new notebook about a year ago.  (It's not so new any more).  I knew I was going to be doing some CAD work on it so I looked at the video chip sets that the various models came with.  The base model T420 came with the Intel GMA4500 (popular because it is cheap).  But for only $20.00 more, I could get that same model T420 with the ATI dedicated graphics chip set.  I went with the the ATI and have been pleased. 

What I find truly shameful is that it is just about impossible for a normal end user to buy something good without becoming an absolute computer nerd!  I knew what to look for because I knew what to look for based on past experience.  I used to be a corporate IT manager in a past life.  It was my business to look at these things and make sure that I didn't end up purchasing 300 plus computers that would not get the job done.  But even I was caught with the crappy Ethernet on my machine with the Galil.  It won't happen a second time though.

Meanwhile, we will be working on ways to deal with the issues in software as well.  If the computer says that it will do OpenGL 3.0 but does it poorly, we might have to put in a switch in the config somewhere that toggles the use of the newer OpenGL features off manually.  We will do what we can. 

Graham, try running on your old XP machine.  And let me know what the results are.  As for your current Mach 4 computer, I'm suspecting that the only way to resolve your issue is with that "manual" switch I was talking about.  :(  Unless we can figure a way to get the video card manufacturer and switch it automatically.  But the problem is more severe than that.  Because SOME computers with GMA4500 chip sets work ok.  I think it has to do with how they are implemented on the hardware. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: Steve Stallings on July 02, 2014, 01:25:22 PM
On some computers that use the Intel GMA graphics chip set, there will be a BIOS configuration setting that allows adjusting the amount of memory dedicated to the graphics chip set. This is up to the computer manufacturer and not all make this provision in the BIOS.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 02, 2014, 02:03:24 PM
Steve
It may take a couple of days to do your request ref  "running Mach 4 on my old computor" as its pretty busy at the moment running Mach 3.
Will report back soon.
Incidently I do not remember having that problem with the first and maybe second versions of Mach4 on my "new" computor.
Graham
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 03, 2014, 02:58:14 AM
Hi Steve,

Thanks for the detailed explanation.

I understand what you say and I appreciate the dilemma regarding the specification of the average modern computer but unfortunately that is probably exactly the type of computer the potential customers for the Hobby version will have and will expect to be able to use.

I wonder if the software teams writing the combat games, which can be quite OpenGL intensive, are facing the same issues ?

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 03, 2014, 05:58:19 AM
Steve
Heres Mach4 on my old computor
Installed - no problem
But will not run see atachments.

Graham
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 03, 2014, 06:06:03 AM
Steve
Just a thought from a non expert
On my new computor it displays the tool path on the program run screen,so its capable of doing it on that screen in all its colours.
so whats different on the mdi and tool path screens where all it shows is a white blank toolpath rectangle.

Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 03, 2014, 07:53:49 AM
Quote
I wonder if the software teams writing the combat games, which can be quite OpenGL intensive, are facing the same issues ?

While the average consumer PC's these days tyically cost between $500-$1000, the average game player probably spends $1500-$3000 on their PC's.
Gamer's are the ones who buy all the very expensive cutting edge PC hardware.

And fwiw, about two years ago, Brian posted the first test version of Mach4 (I think to test comp?) and it was apparent to me then that Mach4 would require more horsepower than Mach3.
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 03, 2014, 08:13:31 AM
Hope your not suggesting that the Hobby user of Mach4 then has to shell out $1500 - $3000 on a PC.  ;D

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 03, 2014, 08:36:53 AM
Like I said, a $100 video card should be all you need. My current desktop is a 7 year old dual core Athlon with a video card I paid $100 for about 4 years ago. It runs Mach4 OK, but a modern CPU with a cheap video card should run circles around it.
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 04, 2014, 08:34:56 AM
Windows XP

Build 1872

The second time and all times after, I still get the error  File " \Mach4Hobby\Profiles\Mach4Mill\Macros\mcLua.mcc" couldn't be removed (error 2: the system cannot find the file specified.)

Clicking OK or the red X will not close the error dialog. The only way I've been able to get to Mach4 is to go to Operator > Edit Screen. That will load Mach4 in screen edit mode, and I can then close the error dialog.

Seems to be the same issue as the last build.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 04, 2014, 01:34:23 PM
Delete all *.mcc files from your profile's macro directory.  Then restart Mach.  It will pop the error up again.  Then run some G code file or MDI (pressing cycle start will recompile all of the scripts).  At this point, you should have a mcLua.mcc file in you profile's macro directory.  and you should not get the error again.

Steve
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 04, 2014, 04:33:54 PM
OK, that fixed that issue.
Still seems to hang with "Connecting toolpaths" for several minutes. But I can access the file menu, so if I load a g-code file while "connecting toolpaths" is displayed, the screen will load right away. Otherwise it will just sit there for several minutes.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 10, 2014, 01:12:45 AM
Build 1888 will be out on the MachSupport download site soon.  All of you guys with video issues should check it out and see if that got any better. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: cheech on July 12, 2014, 07:29:58 AM
-Code hangs.. have to hit CS again.
-Simulation doesn't seem to obey set accel/decel and feedrates. (have quadruplechecked the params)
Title: Re: Mach 4 Bug Reports
Post by: Analias on July 13, 2014, 02:32:51 AM
Darwin2014-1.1.zip
Mach4 build 1889

Mach4 uses forward slashes to delimit port/signal information in the profile .ini file.  Darwin allows setting the signal description to include forward slashes.

When setting a mach4 configuration item, the drop down will show the signal name with a slash and appears to accept it when you save and exit.  When you go back and confirm that the setting was set it will be gone.  In some cases the selected port will be also missing.

-Freeman
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 13, 2014, 04:16:53 AM
Goodmorning
I have downloaded 1889 and still have the same problems as before.
On my "old" xp computor hangs up on connecting toolpath.
On my "new" laptop will not display toolpath other than in the program window.
I know you think I should have a separate/better graphics card but surely the program should work "out of the box" like M ach 3 did.

Graham
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 13, 2014, 05:13:06 AM
Hi Graham,

I agree -  Mach4 'Hobby' should run 'straight out of the box' on the average computer and I am sure it will get there.  ;)

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 13, 2014, 09:04:01 AM
Sorry, but I disagree here a little. I don't want Mach4 to be compromised to run on the cheapest computers available. At one time, a separate video card was required to run Mach3. If it's needed for Mach4, then get a video card. As I said before, you shouldn't need to spend more than $100 on one.

As for the connecting toolpaths issue. It doesn't seem like a video card issue, or at least not a limitation of the video card, but rather how it's used when Mach4 loads. When it appears to hang, just open a g-code file from the file menu, and it will load right away. Also, on previous versions, you could lower the refresh rate, and get rid of the issue.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 13, 2014, 12:21:50 PM
The next step is to put a switch in the Mach 4 config to disable the advanced tool path.  Then you guys can have a Mach 3 like tool path.

Yes, try bumping the screen refresh rate up to like 75ms.  Or 100ms (which was what Mach 3 was).

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 13, 2014, 12:38:24 PM
Steve,

I notice that M3 / M5 doesn't work, is this deliberately disabled at this time ?

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 13, 2014, 12:58:25 PM
No.  If there are macro scripts for those M codes, then they are run instead of the stock actions.  So if you have the "example" scripts, all it will do is print "Spindle Clockwise", etc... in the message area.

The stock action is to use the spindle delays in the config and turn the signals on/off.  If you want more control, write a M3/M5 script.  For instance, my VFD can tell me if it is at speed or at zero.  I can then make the M3/M4/M5 scripts wait on the speed or make sure the spindle is stopped before moving on.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 13, 2014, 01:24:06 PM
Thanks Steve, I understand what has been done now  ;)

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 13, 2014, 02:17:55 PM
Steve
 (1) The next step is to put a switch in the Mach 4 config to disable the advanced tool path.  Then you guys can have a Mach 3 like tool path.

 (2) Yes, try bumping the screen refresh rate up to like 75ms.  Or 100ms (which was what Mach 3 was).

When will the first one be done?
How do you do the 2nd?

Graham
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 14, 2014, 02:00:22 AM
1) In the next build.  Maybe by Tues.  But don't hold me to it!  :)
2) Edit the screen.  Then click on the top element in the tree.  You will see the refresh interval at 50ms.  There are two intervals there.  Refresh and PLC.  Leave PLC alone unless you are on a really super slow machine.  
Steve
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 14, 2014, 03:10:23 PM
Steve
Changing the refresh rate did mot to change anything in the tool paths on my "new" computor or the loading on my "old" computor.

Ger21
Loading an NC program on my "new" computor does not make the toolpath appear in the MDI or Toolpath window.
As I can't load the program on my "old" computor past connecting toolpaths I cant't load a program.

Roll on Tuesday

Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 14, 2014, 03:32:56 PM
When it says "connecting toolpaths" try clicking on the file menu, and load g-code. I can do it on mine, with the "connecting toolpaths" message displayed. This is on my old XP machine as well.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 14, 2014, 03:36:24 PM
Ger21
Thanks for your tip.
Will try that tomorrow before I start a long program in Mach3.
Graham
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 15, 2014, 12:53:12 AM
Build 1900 will have the tool path switch.  I released it to the web gods for distribution.  Look for it mid morning.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 15, 2014, 03:42:09 AM
Goodmorning Ger21
On my old XP computor
Click on Mach 4 mill
Load screen elements
Connecting toolpath
Click on file (which is greyed out)
Still loading toolpaths but now wihout file button
Mach 4 not responding at top of screen
Close program by clicking on Mach4 button tp l/h
End

No luck but thanks very much

next to try is version 1900 just released

Graham
Title: Endless running script / barely visible G code editor window
Post by: FocusPaul on July 16, 2014, 02:33:15 AM
version: build 1900
output plugin: Sim

Endless running script

- Create new script with single line "G1 X1" and empty 2nd line[/li][/list]
- Run the script
- expected behaviour: Script stops running after X hits 1.
- resulting behaviour: In some cases, script stops, but Cycle Start button is not re-enabled. In other cases, the line counter keeps increasing. In both cases Mach4 crashes after some time.
- possible reason: M30 (or some other stop code like M2) is omitted in script. The script will run fine, if M30 is put at the end of the script.

Minimum-sized G code editor

- Open an existing G code script.
- Hit "Edit G code"
- expected behaviour: Editor opens with default window size (or with last size).
- resulting behaviour: Minimized, barely visible editor window in center of Mach4 screen. Please see the attached image below.
- possible reason: Saving window position to C:\users\USERNAME\AppData\Roaming\gcedit.ini fails, because width and height are set to minimal values after closing GCEdit (w=112 and h=27, see attached .ini file). Editing those values manually helps. While parameters x, y and s get updated on closing the editor, width and height never do.

(http://s14.directupload.net/images/140716/lwydyc3t.jpg)
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 16, 2014, 04:08:51 AM
Smurph
Build 1900 no differance on my new computor, still not displaying toolpath in mdi or toolpath window, run nc file and it on displays on program run page only.
Do I have to alter anything i.e. the "switch"

""Build 1900 will have the tool path switch.  I released it to the web gods for distribution.  Look for it mid morning.""

Will try it on my old computor this afternoon.

Graham
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 16, 2014, 09:50:02 AM
The switch is in the mach config dialog.  First tab.

Steve
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 16, 2014, 03:44:52 PM
Smurph
I have looked hard but cannot find " mach config dialog. first tab"
Can you give me a hint?

Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 16, 2014, 04:53:16 PM
Build 1900 fixes the "Connecting Toolpaths" issue on my 7 year old XP PC.
Mach4 only displays "Connecting Toolpaths" for about 1 second now.
Title: Re: Mach 4 Bug Reports
Post by: Hipshot on July 16, 2014, 06:23:40 PM
Mach 4 Demo Build 1889
Bolt Hole circle Wizard
Repeats the first point in the circle on the G83 line and the following X Y line. On a drill this is not much of a problem but on a tap it would be ugly.
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 16, 2014, 06:35:50 PM
Smurph
I have looked hard but cannot find " mach config dialog. first tab"
Can you give me a hint?

Graham

In the the menubar, do;  Configure -> Mach...  That will display the mach configuration dialog.  It has multiple tabs.  General, Motors, Axis Mapping, etc...  The first tab (General).  Look for "Disable VBO Tool Path"

Steve
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 17, 2014, 04:10:58 AM
Smurph
Thanks
VBO disabled with a tick on my "new" computor.
Still not displaying in MDI or Toolpath
And closed and reopened Mach4
What next??
Will try later on my "old" computor in my workshop and report back.

Graham

Title: Actually, there's no error
Post by: FocusPaul on July 17, 2014, 04:50:27 AM
version: build 1900
output plugin: Sim

Wrong handling of file operation result code

- Create a new M code script with valid code in your Macros subfolder. Open Mach4.
- expected behaviour: The macro gets compiled to some .mcc file without any errors.
- resulting behaviour: Though the macro gets compiled, an error message is displayed on screen. The message translates to something like this "Failed to open MACROFILENAME for reading (error 0: the operation returned successful)." Also, because of this error message, Mach4 won't generate mcLua.mcc.
- possible reason: Maybe type in error code checking routine?

(http://s7.directupload.net/images/140717/x9ww3wu3.jpg)
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 17, 2014, 04:57:45 AM
Smurph
On my "old" computor in the work shop
Cannot even get to the the point where I can open the config screen.
Tried everything i can think of.
Graham
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on July 17, 2014, 05:10:19 AM
Additional information on previous posting "Wrong handling of file operation result code":

The reason for not generating mcLua.mcc had been a wrong mcc file, which had been generated with an earlier (now outdated) Lua version. My bad!
Still, the error messages are there, although everything works now as intended.
Title: Re: Mach 4 Bug Reports
Post by: poppabear on July 17, 2014, 01:32:58 PM
Hi Again Steve,

I forgot to mention, that when you run the Modbus Diagnostic dialog, you can NOT close it UNLESS you push the "Stop Plugin" button... which forces you to close and reboot mach to get it running again........  The Exit, Red X etc. will NOT close the monitor window.  Further once you hit the Stop Plugin button, and you close the window, can you put in the Modbus-Config window a "Start" (or Restart), or a mc.mcStartMBPlugin or some such....

Scott
Title: Re: Mach 4 Bug Reports
Post by: poppabear on July 17, 2014, 03:53:06 PM
Ok, Update on the MB dialog not closing, Steve remoted in to see what I was seeing. He dropped a pearl, that the Serial MB was set to polling at 25ms, but the actual time to complete the poll was 460ms or so. He noted that the ques on the windows event where stacking up since the poll was not completed. So he set my Poll to 600ms, and since that was greater than the serial completion time, it now CLOSES like it should. I.e. via the Red X or Exit.

Further I had my Serial Speed set to 19, and I bumped it up to 38 so it now completes faster, and I set the poll to 500ms to give me some wiggle room.
It now closes as it should every time.......

Thanks Steve!!
Title: Re: Mach 4 Bug Reports
Post by: Analias on July 18, 2014, 05:35:40 PM
Mach 4 build 1900

Steve I don't know if this has been reported yet,

When I change a property for a UI widget and click out by clicking on the screen being edited, the property value is assigned to the next UI component in the Screen Tree Manager.  If I click on another property field, it gets assigned correctly.


-Freeman
Title: Re: Mach 4 Bug Reports
Post by: Analias on July 19, 2014, 10:11:33 PM
Mach 4 build 1900

When trying to save a screen set I inadvertently select "Save As".  When I cancel the "Save As" and then select the proper "Save Screen" option, Mach 4 crashes to the desktop - very rude.


-Freeman
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 21, 2014, 03:03:39 PM
Rude, crude, and socially unacceptable.  We strive for it!  :)

Thanks, I will take a look.  Not much I can do about the property issue yet.  I knew about it, but I have not figured a way around it.  The save issue I can probably do something about. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 21, 2014, 05:30:09 PM
Smurph
Can you let us know the minimum spec. for computors to run Mach 4.

Ger21
What is the spec. of your XP computor running Mach 4.

Still not going on either of mine properly.

Graham
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 21, 2014, 05:55:12 PM
Athlon X2 4400 - Dual Core 2.2Ghz
Geforce 9800GT video card
2Gb RAM
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 21, 2014, 07:22:06 PM
I have Mach 4 running on my old Pentium 4 2.8 Ghz with the last gen ATI AGP video card.  4 Gigs of mem.  Mach 4 will run on that without issue.

I also have Mach 4 running on my Atom based D2700MUD board.  This board has the Intel GMA-3650 video chip set and it is not a great performer.  I thought I would buy this board and put Linux on it and that it would be sufficient.  But there are no video drivers for Linux and the GMA-3650 and there never will be.  The ONLY operating system that is supported on this board is Windows 7 32.  Although I'm not real happy about the D2700MUD board, it will run Mach 4.  The video is just not as snappy as I would like it to be.

The only minimum spec we just have to have is a video chip set that is capable of at least OpenGL 1.5 to use the Vertex Buffer Objects (VBO) tool path.  However, I put an old PCI video card in that old Pentium 4 box (above) that only supported OpenGL 1.1 and I got it to work with the config switch to turn off VBO tool path.  

And I actually got Mach 4 running in a virtual machine too.  VMWare Workstation version 7.  It mimics OpenGL 1.1 too.  Although OpenGL is supported in that VM, it is not good.  The tool path is clunky and would not be good for a real machine's controller.  So that brings me to my next point: Just because the specs say it will do OpenGL x.x doesn't mean it will do it well.  

Any machine that runs CAD well will run Mach 4 well.  

Things to stay away from:

1.  Integrated video chip sets.  Some are good.  But it depends on how the MB manufacture implements them.  I have seen the GMA-4500 work well on one board and not on another.  They are a gamble.  Are you lucky?
2.  RealTek integrated Ethernet controllers.  Pure junk.  No transmit capabilities.  For people with external Ethernet based controllers like ESS, HiCON, and Galil, etc...  this combo is just not going to work well.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 24, 2014, 03:44:06 AM
Hi Steve,

I know you are very busy and I am sorry to bother you with another question;

Will Mach4 incorporate a command set (similar to the Mach3 M11P1 / M10P1 or E1P1 / E1P0) which is capable of switching an Output on / off at the exact time of an axis movement for us laser users ?

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 24, 2014, 02:04:36 PM
Steve & Ger21
If I replace my radeon 9250 grahics card with this

http://www.amazon.co.uk/GeForce-Graphics-Express-Profile-Cooling/dp/B008A1C2AM/ref=sr_1_1?s=electronics&ie=UTF8&qid=1406224597&sr=1-1&keywords=2gb+video+card

Do you think it will make a differance with my problems on Win xp and tool path display.
I do not know what Open GL1.5 is except its some kind of standard?

Or is it a try it and see situation??

Graham
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on July 25, 2014, 04:39:59 AM
Your (rather old) Rad 9250 should implement OpenGl 1.5. Maybe it only does partially, cannot say.
The card on the link you posted supports version 4.2. Please check that your computer supports PCI-Express 2.0 interface as described in the product listing. The 9250 seems to require AGP interface.

OpenGL is a graphics standard to implement hardware-independent drawing operations (like the drawing of your toolpath). The version number describes the OpenGL capabilites which have been implemented by the graphics card. The higher, (usually) the better.
I cannot say whether it helps with your problems, but 31 bucks is nothing I'd think twice about.
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 25, 2014, 08:55:01 AM
Well, I had to try v.1914 with the Vista Laptop and an IEEE 1284 ‘plug-in’ parallel port. I can’t say I fully trust it with an engraving bit just yet but it seems OK just cutting air.

35 seconds of the test  http://www.graytel.talktalk.net/M4b.wmv

There appears to be a slight issue with v.1914 – the A axis responds OK to the MDI command but not from GCode – strange ?.

Tweakie.                                 
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on July 25, 2014, 09:23:42 AM
For some reason I never have great luck viewing your videos as always seems to go black over half the time.

but I did get a chance to see your laptop and this did get to my screen. IEEE 1284 ‘plug-in’ is that a PCMCIA Card for adding the parallel port?
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on July 25, 2014, 10:48:48 AM
Hi Craig,

Correct sir - PCMCIA card - not sure if it would work or not but it arrived in the post this morning so I had to give it a try.  :)

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on July 25, 2014, 03:09:44 PM
FocusPaul
 "Please check that your computer supports PCI-Express 2.0"
Have checked to the best of my ability and it is so old its just PCI.
Looking increasingly like a later computor will be needed with a good grahics card.
Just my luck. I wanted a smooth transfer over.
Graham
Title: Re: Mach 4 Bug Reports
Post by: alcwell on July 25, 2014, 04:20:32 PM
Just in case no one from the Mach4 team is following the Darwin thread.
http://www.machsupport.com/forum/index.php/topic,27194.msg195065.html#msg195065 (http://www.machsupport.com/forum/index.php/topic,27194.msg195065.html#msg195065)

Is anyone else seeing a big jump in CPU usage with build 1914. I was testing Darwin with build 1900 and CPU usage when running G-Code was 5-10% and it was working fine. With 1914 the motors are rough and irratic with CPU usage at 100%.

Alastair



Title: Re: Mach 4 Bug Reports
Post by: ger21 on August 03, 2014, 03:17:01 PM
1) Go into Edit Screen Mode.
Change the color of something. (Or make any change I think)
Toggle the screen editor off. When prompted if you want to save the changes, choose no.
The change is not saved, but remains in effect until you close and restart Mach4

2) Some items (like labels) have no background color. If you change the color of an item with no background color, there's no way to reset it to the default no color.

XP SP3
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on August 05, 2014, 09:06:25 AM
Not a bug ...

When loading a licence file, Mach4 asks for .dat, while the licence file delivered is a .txt file. Would be nice to have same file extension.
Title: Re: Mach 4 Bug Reports
Post by: gadman58 on August 05, 2014, 09:33:22 PM
I am using a Hicon Integra and have a slaved motor Motor3 to Motor0 which is my X axis.
With the Motor3 slaved the Xhome or Ahome LED wasn't lighting when activated.
If I ran Motor3 as an A axis not slaved to motor0 the X and A home switch LEDs work.

My fix was to go change the LED to use the inputs for motor0 home and motor3 home.
I did leave Xhome and Ahome selected in the output for those LEDs.

Glenn

Title: Re: Mach 4 Bug Reports
Post by: handsmfg on August 08, 2014, 02:53:43 AM
I'm seeing the same CPU load issue being 100% jogging  axis motors with Mach 4 build 1914. Using the latest Darwin PP plugin as motion

device. Computer is Dell Optiplex GX270. ATI Radeon 9550 with 256Mb video RAM. 3GB system RAM. Windows XP SP3.

Computer runs Mach 3 on 2 PP very well never any issues.

Eric
Title: Re: Mach 4 Bug Reports
Post by: handsmfg on August 08, 2014, 07:23:45 AM
I have verified that there is a CPU overload problem with Mach 4 1914 that causes jerky motor movement when jogging. I downloaded and installed Mach 4 1900 over 1914 and that fixed the problem. I ran a simple gcode program and the CPU usage was low and the motors ran very smoothly just like Mach 3. Using Darwin 1.11 for motion controller. See the video for the results.

Eric
 

https://www.youtube.com/watch?v=9zLMM0NiwlY
Title: Re: Mach 4 Bug Reports
Post by: cheech on August 08, 2014, 08:39:48 AM
Not really a bug I guess...

But could someone tell me why mach4 won't respect the Accell/Decell set on the motor tuning graphs? I guess that the planner is not fully configured yet...

Also I see lots of jagged lines on the ran path...

I'm guessing these details haven't been polished yet.


regards,
cheech
Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on August 13, 2014, 03:54:55 AM
Hi All
Is it possible to tick the VBO setting before starting Mach 4 as I cannot get past connecting toolpaths.
No matter what I click before then.
Hopefully Graham
Title: Re: Mach 4 Bug Reports
Post by: Dazed+Confused on August 13, 2014, 09:20:10 AM
@GRAYHILL

anywhere under [Preferences] section in your Machine.ini try adding this.

DisableVboToolPath=1

Title: Re: Mach 4 Bug Reports
Post by: GRAYHIL on August 14, 2014, 03:42:28 PM
Dazed+Confused
On my laptop doing what you say starts Mach 4 with VBO pre ticked from a previously non ticked state but still with no MDI or toolpath display except for program run screen.

Makes no difference on my old Dell 2400 still stalls on connecting tool paths.

Thanks very much it was a shot in the dark to avoid buying a new computer for my workshop.

Graham
Title: Re: Mach 4 Bug Reports
Post by: Analias on August 17, 2014, 01:05:58 AM
Mach 4 Build 1936

When using a Lua Panel, the initial size is set by the screen editor.  When panel resized, when the Mach 4 is loaded or resized, the Lua Panel (as pointed to by mcLuaPanelParent) does not resize appropriately.

To test, drop a Lua Panel into a screen set.  Insert the code below as the script property of the Lua Panel. Use your own image, set the size of the Lua Panel smaller than your image to force it to crop.  My image was 380x380 pixels, my panel is 350x350 px. Exit the screen editor to cause Mach 4 to resize the contents of the screen set. 

Note that image is cropped to the initial size of the Lua Panel, and is surrounded on the left and bottom by blank space.  Clicking on the image causes the onLeftUP() event handler to fire and show the X/Y coordinates of the click.  Clicking outside of the image, in the solid blank area, returns no feed back.


Code: [Select]

local panel = mcLuaPanelParent

function onPaint (event)
    local dc = wx.wxPaintDC(panel);

    local image = wx.wxImage();
    if (not image:LoadFile('./screens/MyStdMill/images/MSM_Probe_1.png', wx.wxBITMAP_TYPE_PNG)) then
        wx.wxLogError("Could not load image from '%s'!", imagePath);
        dc:delete();
        return;
    end

    --image:Resize(panel.getSize());
   
    local bitmap = wx.wxBitmap(image);

    dc:DrawBitmap (bitmap, 0,0, true);

    dc:delete ();
end

function onLeftUp (event)
    local mouseX = event:GetX();
    local mouseY = event:GetY();

    wx.wxMessageBox("LEFT CLICK - X: "..tostring(mouseX)..", Y: "..tostring(mouseY));
end

function onSize (event)
    local size = panel.getSize();

    wx.wxMessageBox('Width: %d, Height: %d', size.getWidth(), size.getHeight());

    event:skip();
end

-- connect the paint event handler function with the paint event
panel:Connect(wx.wxEVT_PAINT, onPaint)
panel:Connect(wx.wxEVT_LEFT_UP, onLeftUp);
panel:Connect(wx.wxEVT_SIZE, onSize);

-Freeman
Title: Re: Mach 4 Bug Reports
Post by: Hipshot on September 04, 2014, 05:46:29 PM
Mach 4 Build 1953

Will not run G code file or MDI motion. 1942 runs the same code no problem.
The Zero X, Y, Z and A boxes are greyed out also.

Scott
Title: Re: Mach 4 Bug Reports
Post by: smurph on September 04, 2014, 07:46:03 PM
Make sure the axes are enabled.  1953 runs fine so far from other reports.  So there is a problem with the config or something.

To further explain...  The Zero buttons are greyed out based on the availability of the axis.  Same with the jog buttons.  Since yours are greyed out, it makes me think that the axes are not enabled.  So check that out and see.

Steve
Title: Re: Mach 4 Bug Reports
Post by: cheech on September 07, 2014, 08:26:57 AM
M4 doesn't like the name of this file...  I get some nag screen and plus a nasty bug aferward... Filechooser looking all crippled... and some other esoteric manure

.dnc file wont upload...

the name of the file is: ff031 510 Gabriel Pedro Gonçalves_top.dnc

I think that the "ç" creates the issue...

regards,
Francisco
Title: Re: Mach 4 Bug Reports
Post by: Hipshot on September 10, 2014, 11:25:23 PM
Mach 4 Build 1953

It will not run any older G code file with “A” axis moves. It randomly fails and will not recover without a complete restart. It was running a four hole cycle and it randomly failed on the third hole and never moved again. I setup logging and captured this during multiple runs.

Scott
Title: Re: Mach 4 Bug Reports
Post by: poppabear on October 06, 2014, 11:43:46 AM
Hey Brett,

just downloaded and installed version 2030, and it crashes right at start up, with an App Crash message, I am running W8.1 64 bit.. I tried downloading and reinstalling, same thing, I have a license as well.

So I had to uninstall and reinstall 1942, which is now working correctly as it should.  Is there something new with 2030, like if we have 1942 era plugins or the like, we have to move them out of the plugins directory? Or some other "Pet Trick" to get 2030 to work?

Scott
Title: Re: Mach 4 Bug Reports
Post by: smurph on October 06, 2014, 01:37:54 PM
Do not use plugins older than build 2012 with builds 2012 and newer.  All plugins now require a digital signature file (<pluginname>.sig).

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on October 07, 2014, 12:52:38 PM
I Had a chance to run some Gcode and it appears there is an issue with v.2030 - I runs OK for a while then locks up (after no particular time or number of lines etc.) and the only way out is a PC restart. Tried it several times with the same end result.

The history tab brings up this error message, if it's any help.

Tweakie.

Title: Re: Mach 4 Bug Reports
Post by: smurph on October 07, 2014, 01:13:31 PM
Tweakie,

Check the license status in Help->About.  I bet you are just in demo mode.  It is a random time.  The error message means that nothing was in the status history, nothing more.  I do need to fix that so that there is no message.

Steve
Title: Re: Mach 4 Bug Reports
Post by: smurph on October 07, 2014, 01:16:33 PM
A bit more on the demo mode...  We changed the way the computer ID is generated.  Because it was previously looking at USB devices that, if unplugged/plugged, would change the computer ID!!!  Now it is ONLY looking at items that are stable on the PC.  But it requires a license update with the new computer ID.  Also, licenses are now kept in a separate Licenses folder and are no longer kept in the Mach installation root.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on October 08, 2014, 01:36:12 AM
Tweakie,

Check the license status in Help->About.  I bet you are just in demo mode.  It is a random time.  The error message means that nothing was in the status history, nothing more.  I do need to fix that so that there is no message.

Steve

Hi Steve,

Sorry to say this but it shows Licensed in the help menu.

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: smurph on October 08, 2014, 01:47:05 AM
There was a bug where it showed Licensed even if it was actually in Demo mode.  The real tell all is what type of license it says.  If it says Demo and Licensed, then you are in demo mode.  If it says Hobby and Licensed, then that is a real problem. 

A PC restart or Mach restart?  Because we really don't do anything that might need a PC restart.  Maybe Darwin? 

We shall see.  But in the meantime, build 2038 will be posted up in the morning.  Get that one and try it. 

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on October 08, 2014, 02:12:26 AM
Thanks Steve - I will try v. 2038 after it's posted.

This is a screenshot of my about panel...

Sometimes it allowed a Mach4 restart after stopping other times a PC restart was necessary.

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on October 09, 2014, 02:14:34 AM
Hi Steve,

Just by way of an update, build 2038 says it's licensed but behaves as though it is not (stops at some random point in time).  :'(

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: smurph on October 09, 2014, 01:12:39 PM
I ran my 2038 build for 12 hours straight to test.  It never stopped.  I'm running a Galil.  So it may be in your motion plugin.  What are you using?

Steve
Title: Re: Mach 4 Bug Reports
Post by: Tweakie.CNC on October 10, 2014, 01:55:34 AM
Hi Steve,

I am using Darwin and you are right build 2030 runs forever in simulation mode, only when running Darwin does it stop. Looks like the problem is over to Art  :)

Tweakie.
Title: Re: Mach 4 Bug Reports
Post by: handsmfg on October 28, 2014, 02:13:28 PM
Mach 4 2059 still won't allow Darwin to be licensed. I even went as far as downloading a new license file from the license manager. It downloaded as a .txt file and I had to change it to a .dat file to get Mach 4 to see it. I can jog 3 axises but that's it. Homing wont't work. I can't turn on my forward and reverse spindle relays
with M3 and M4 in MDI. Spindle won't turn on.

I looked in the history file and saw.

Failed to license feature M4_DARWIN
(mcDarwin)Darwin License has failed.
Do MDI

Then I looked in Mach 4 Help/System Information and saw Feature M4_mcDARWIN Unlicensed

So the Darwin plugin bug still isn't fixed.

Eric
Title: Re: Mach 4 Bug Reports
Post by: ger21 on November 01, 2014, 08:49:27 AM
Mach4 Build 2067 - XP

Load g-code.
Go into Screen Edit mode.
Change the number of lines in the g-code display.
Save Screen
Leave edit mode.

You can no longer rotate the toolpath display until you close and restart Mach4. This applies to all toolpaths on the different tabs.
Title: Re: Mach 4 Bug Reports
Post by: kobi-s on November 05, 2014, 05:14:51 AM
Hi,
downloaded the first time M4 (version 2067). I love what I see.
Unfortunately when I start m4 the outermost blue frame of the window is not showing up. (M4 is occupying the entire screen without the blue frame around.)
Therefore I can't resize the window. Any ideas how I can rectify it?
Thank Jakob
Title: Re: Mach 4 Bug Reports
Post by: smurph on November 05, 2014, 03:29:44 PM
It may be in either full screen mode or the window (1024x768) is bigger than your monitor resolution.

In the view menu, there is a full screen toggle item.  If you screen res is too small, you will have to use the keyboard to resize it.

Steve
Title: Re: Mach 4 Bug Reports
Post by: kobi-s on November 06, 2014, 03:38:09 AM

[/quote]
It may be in either full screen mode or the window (1024x768) is bigger than your monitor resolution.

In the view menu, there is a full screen toggle item.  If you screen res is too small, you will have to use the keyboard to resize it.

Steve

Thank you Steve,
it was my fault. Did not recognize Alt+Enter was the shortcut to solve this isue.

Jakob
Title: Re: Mach 4 Bug Reports
Post by: Syilx2 on November 07, 2014, 08:17:15 PM
Hi guys, for what it's worth..

mach4 build 2075 unstable locks up
Darwin 1.2075

szAppName : Mach4GUI.exe     szAppVer : 1.0.0.1     szModName : hungapp     
szModVer : 0.0.0.0     offset : 00000000

rgds
Charles
Title: Re: Mach 4 Bug Reports
Post by: smurph on November 07, 2014, 09:49:47 PM
Is that the latest Darwin?  Art told me it was running fine.

Steve
Title: Re: Mach 4 Bug Reports
Post by: Syilx2 on November 08, 2014, 12:17:29 AM
Steve,
Darwin install file named "DarwinSetup2075.exe"

charles
Title: Re: Mach 4 Bug Reports
Post by: kobi-s on November 09, 2014, 10:57:28 AM
Hi, did some testing with Radius correction milling small holes. (1.5mm) and small tool diameters. From experience with other CAM programs, this can be a challenge.

with M4 I loaded the attached nc file. v5_typ1.nc

- with a tool diameter of "0" the tool path is drawn exactly in the contour line of the drawing. (wich is correct)
- If I enter a tool diameter of 0.6mm the milling contour is drawn outside the drawing lines. See pic v5_mach4.png

BTW: with both M3 and cncgraf I can use tool diameter up to 1.2mm I know this a challenge for a CAM program.
I the attached file v5_mach3 you see the radius correction as it should be correctly. See pic v5_mach3.png
I have attached another screenshot drawn by another CAM Program which gives a better view how the mill part should look like. See pic_ v5_cncgraf.png

Q: is there a setting issue in M4 or a bug?
Jakob


Title: Re: Mach 4 Bug Reports
Post by: pbarratt on November 20, 2014, 08:06:53 PM
Installed Mach 4, V1.2114 and did some playing around with jogging.  I don't know if what I found is unique to this version or has been the case in previous versions.

Configured Mach 4 with metric machine setup units and metric units mode.  Set up x and y axes motors with 400 steps per unit.  Exit configuration and select program run and jogging.  Enable. Ref all.  Zero X and Y DROs.  Select step mode for jogging, leave jog increment at default 1.0000.  Click X+.  X axis DRO goes to 25.4000.  Click machine coordinates, X axis DRO now reads 1.0000.  Clear machine coordinate, DRO goes back to 25.4000.  Y axis behaves the same.

Also, when configuring the axes motors, if I put in 300 for an acceleration, the calculated G force shows 0.77705712.  That would be true if the 300 were inches per second per second but I've specified metric.  The actual value should be around .0306

I seems to me that metric and imperial units are getting crossed.

Am I missing something here?

Peter
Title: Re: Mach 4 Bug Reports
Post by: Steve Stallings on November 20, 2014, 08:22:25 PM
I asked a similar question and was told that Machine Coordinates always display
in the units that the machine was configured in during setup, regardless of
what units are active at the current time. My suggestion was that the DROs
should have an indicator to show what units they are displaying, much like a
traditional DRO on a manual machine.
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on November 20, 2014, 08:33:29 PM
Fair enough but I configured the machine setup in metric and have selected metric for the units mode so I think I should be in metric mode at all times.

I agree with having a units indicator to help keep things straight.  In actual use (with Mach 3), I use both imperial and metric at times.

Peter
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on November 20, 2014, 09:25:43 PM
Interesting, I knew there was some issues with metric, but other than running a metric program in inch setup units. Had not pushed it. Peter reading your results I tried creating a new profile all in metric and use my screen set. For the most part it just does not work. All kinds of issues moving an axis and getting poor results. Can't understand how a screen set could cause issues with movement. But there is something amiss with the metric mode. Went back to the default screen worked better but could not use MDI or run a program but jogging worked. This was version 2114

When i worked everyday I programmed 99% of the time in metric but now that I'm retired and putzing around I use inch 99% of the time.
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on November 20, 2014, 10:09:36 PM
I actually found a few other problems such as strange results when you change the jog increment down to .01 or smaller (try going up a few steps then down) and homing speeds run at around 62% instead of 20% but I figure these might be symptomatic of the same problem and I don't want to flood the issue with too much 'stuff'.

Peter
Title: Re: Mach 4 Bug Reports
Post by: dude1 on November 20, 2014, 10:16:30 PM
I found that problem to it has been there for every update I have tried.

the problem goes away when using Darwin
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on November 20, 2014, 10:22:06 PM
Might just be a Sim Plugin issue then, I'll check tomorrow on a couple of machines.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on November 20, 2014, 10:48:13 PM
everything I have tried with Darwin works fine when just doing sims lots of things go wonky
Title: Re: Mach 4 Bug Reports
Post by: BR549 on November 21, 2014, 03:22:56 AM
When you open the Gcode Editor it is a very small square in the center of the screen you have to hit expand full screen to make it readable. Any way to fix that so that it opens correctly.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on November 21, 2014, 06:48:35 AM
Terry if you grab a corner of the box, resize & reposition, on closing all gets stored in the hidden files.

and do replace my user name with yours,  ;)
Title: Re: Mach 4 Bug Reports
Post by: BR549 on November 21, 2014, 10:24:36 AM
BUT Craig,  IF I use your name it will do all kinds of magic things CORRECT??????

OK that solved the sizing but NOT the color scheme

Thanks (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on November 21, 2014, 11:35:18 AM
Solved the Color thingy

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on November 21, 2014, 11:48:58 AM
daniellyall,

After seeing your post, I went back to my machine system (Darwin) where I had first seen the problems.  It seems that restarting Mach 4 solves some of the problems.  True, I was checking things out on my development system (Sim plug-in) so things are worse there.

I got use to changes taking effect immediately with Mach 4.  Having to do a restart will create some difficulties.  In Mach 3, your don't have to.  This has been convenient for some setup operations.

Thanks for your input.

Peter
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on November 21, 2014, 01:08:55 PM
Ok I just tested metric on both Darwin and the ESS and all seems fine, screen.set had no issues either so it has to be the Sim plugin
did have to make sure that the initialization codes did not have an inch gcode in there as that did look a little odd on first moving.
I just made a copy of a known good inch profile then edited the Machine setup units, units mode and motor steps per, in the new metric profiles.

And as a bonus I got probing to work today using the ESS, so its getting closer to being done.  :)
Now I can get that probing screen written finally.
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on November 29, 2014, 08:39:48 AM
Just noticed while testing Build 2128
that in the Diagnostic / Simulator option, if I "open it", "close it" and "open again" Mach4 crashes.
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on December 01, 2014, 09:19:29 AM
using gcEdit
the Find and Replace does not seem to work.

Finds them, just does NOT replace
Title: Re: Mach 4 Bug Reports
Post by: patton on December 11, 2014, 01:49:54 PM
When the timing signal is triggered the 0 motor which I have set to the x-axis
will start and move in a +direction until it hits the limit or you hit e-stop.
Title: Re: Mach 4 Bug Reports
Post by: smurph on December 11, 2014, 02:23:30 PM
When the timing signal is triggered the 0 motor which I have set to the x-axis
will start and move in a +direction until it hits the limit or you hit e-stop.

You have an old signal mapping setup in your profile.  Edit the machine.ini file for the profile and delete all of the [Signal#] mappings.  You will then have to re-map your signals.  :(

Steve
Title: Re: Mach 4 Bug Reports
Post by: BR549 on December 12, 2014, 04:57:39 PM
I noticed that the toolpath display does NOT show the path centerline when doing tool radius offsets. Makes it hard to follow the offsetting with no visual aid.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Ya-Nvr-No on January 06, 2015, 08:38:22 AM
I can confirm, that it works ... at least in my Lua scripted Wizard:
found on page 3 message #27

As I learn more about Lua coding, I like to go back every so often and reread old threads to see what others know and share.

Did not follow just what was going on here at the time, as it did not seem to make sense how to get his code to work or just what he was trying to show. now with time and more understanding I did get this to work. Had to add the call to main() and mainframe:Show(true)
But when you close the popup window it places the text in the windows clipboard. So if you use paste too, in a text editor you will see the message.

Thanks Paul --these are the guys that are in the background doing things the rest of us struggle with.  ;)

Code: [Select]
function onCloseEventOccurred(event)
--exit frame, if it exists
if mainframe then
mainframe:Destroy()
mainframe = nil
end

local clipBoard = wx.wxClipboard.Get()
if clipBoard and clipBoard:Open() then
clipBoard:SetData(wx.wxTextDataObject('hello world\nI was copied to the clip board\n'))
clipBoard:Flush()
clipBoard:Close()
end
end

function main()
mainframe = wx.wxFrame(wx.NULL, -- no parent
wx.wxID_ANY, -- whatever for wxWindow ID
"Example",-- frame caption
wx.wxDefaultPosition,-- place the frame in default position
wx.wxSize(400, 200),  -- Window popup screen size
wx.wxDEFAULT_FRAME_STYLE) -- use default frame styles
mainframe:Connect(wx.wxEVT_CLOSE_WINDOW,onCloseEventOccurred)
end

main() -- you have to call the function
mainframe:Show(true) -- then you have to show it

You would paste this in the mcLuaEditor save it to your wizard folder run it and then when you close it your message is available.
Title: Re: Mach 4 Bug Reports
Post by: Phoneguywv on January 12, 2015, 09:43:42 AM
Having problem with the use of M00/M01 can not get the next block of code to work after hitting the cycle start again in Mdi tab
Title: Re: Mach 4 Bug Reports
Post by: Syilx2 on January 19, 2015, 02:43:08 AM
Hi Guys,

Win7 Pro 64 Administrator => Just installed "Mach4Hobby Installer-2178"  and Mach4 crashes when starting up ..
Mach4gui "*** Caught unhandled unknown exception; terminating" error.
It displays blank screen with top menus but will  not load any screenset - then terminates
BUT
Mach4Hobby Installer-2157 works ok !!

your thoughts??
keep up the good work.
Title: Re: Mach 4 Bug Reports
Post by: cd_edwards on January 19, 2015, 08:19:30 AM
Had the same problem with the unexpected sig. updated my license file and away it went.
Title: Re: Mach 4 Bug Reports
Post by: Syilx2 on January 20, 2015, 07:10:11 AM
That worked !
Thank you
Title: Re: Mach 4 Bug Reports
Post by: BR549 on January 22, 2015, 10:38:47 PM
I started testing again and ran into this quirk. I loaded the Gcode and got a strange error message (;-) There is no G74 code in the program and I cannot get past it.


Gcode:

(strange tapering of parallel movement with G41/sub)
#1=4      
#2=400    
#3=0.05  
#4=1      
#6=[#1*#3]
G90 G54 G21 G40
G41 G0 X0. Y0. P#4
M1
M98 P1 L[#1-1]
G40
M30

O1
G91 G0 X#3 Y[#3-[#3*2]]
G0 Y-18.
X5.
G1 Y12. F#2
G2 X1. Y1. I1. J0.
G1 X5.
X5. Y5.
G0 X-16.
M99

Load Error:

"C:\Mach4Hobby\GcodeFiles\12345.tap", Line 8: Spindle not turning counterclockwise in g74
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on February 08, 2015, 09:09:09 PM
Sorry for dragging up an old problem but I'm still seeing wrong acceleration values in the motor setup page when setting up M4 for metric.  I'm using the latest M4 V2214 and Darwin 2209.  Selected metric for both machine setup units and units mode.

Peter
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on February 12, 2015, 09:57:38 AM
Sorry for dragging up an old problem but I'm still seeing wrong acceleration values in the motor setup page when setting up M4 for metric.  I'm using the latest M4 V2214 and Darwin 2209.  Selected metric for both machine setup units and units mode.

Peter

I remember seeing some feed rate problems using metric system in older versions (started around v1900), but with v2214 I am able to configure the axis in metric mode with correct speed / acceleration.
Tried max. velocity of 6000 units/min, and acc. of 25 units/sec² and got the correct movement when using a defined feed rate of 50 units / sec.

Can you please give an example of your problem?
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on February 12, 2015, 10:49:11 AM
Certainly.

Firstly, I suspect the actual movement is okay.  It's the displayed acceleration value in G units that appears to be wrong.

I set both the setup units and units mode to metric.  Then in the motor setup setup tab, enter an acceleration value of 300.  The displayed acceleration value shows .77 G.  It should be 300/9800 = .0306.

If I assume the 300 is inches / s /s, I get 300 / (12 x 32.2) = .77.  Therefore, I think the acceleration calculation in G units is not switching to metric.

Restarting M4 or the computer does not change this.

Peter
Title: Re: Mach 4 Bug Reports
Post by: dude1 on February 12, 2015, 01:12:18 PM
adjust your pulse rate
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on February 12, 2015, 02:45:06 PM
daniellyal,

It's not a motion problem, it's an error in the displayed value of the acceleration expressed in G units.  When you enter a value for acceleration on the motor tuning page, the box to the right of that should display the acceleration in units of G.  If you enter 300 units/s/s and you are working in metric units (mm), the displayed value should be 300/9800=.0306.  Nothing to do with pulses, steps per unit, maximum velocity, just a translation from units/s/s to G.

In M3, you can enter either G units or units/s/s but, obviously not both as they are not independent values.

G values are nice in that they give one a quick feel for the forces acting on the table and any vices, work, jigs mounted on it.  An actual acceleration of .77 would require very high forces be applied by the motors.

Peter
Title: Re: Mach 4 Bug Reports
Post by: dude1 on February 12, 2015, 04:08:21 PM
how did you get the value of 9800
Title: Re: Mach 4 Bug Reports
Post by: ger21 on February 12, 2015, 04:18:08 PM
Gravity.
9.8m/s
1G
Title: Re: Mach 4 Bug Reports
Post by: dude1 on February 12, 2015, 04:34:38 PM
thanks I will have another look
Title: Re: Mach 4 Bug Reports
Post by: FocusPaul on February 13, 2015, 01:39:43 AM
daniellyal,

It's not a motion problem, it's an error in the displayed value of the acceleration expressed in G units.  When you enter a value for acceleration on the motor tuning page, the box to the right of that should display the acceleration in units of G.  If you enter 300 units/s/s and you are working in metric units (mm), the displayed value should be 300/9800=.0306.  Nothing to do with pulses, steps per unit, maximum velocity, just a translation from units/s/s to G.

In M3, you can enter either G units or units/s/s but, obviously not both as they are not independent values.

G values are nice in that they give one a quick feel for the forces acting on the table and any vices, work, jigs mounted on it.  An actual acceleration of .77 would require very high forces be applied by the motors.

Peter

Confirmed. Broken in (at least) the most recent version.

With an acceleration of 4000 mm/s the G force should be (4000 mm/s² / 1000) / (9.81 m / s²) = ~ 0,40 G.
It displays ~ 10 G.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on February 13, 2015, 01:51:24 AM
looks like the math is a bit out
Title: Re: Mach 4 Bug Reports
Post by: BR549 on February 28, 2015, 02:46:39 PM
Does Mach4 NOT show the original toolpath along with the COMPED toolpath when using tool comp code? 

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: NeilD321 on March 02, 2015, 05:35:45 PM
Open Mach 4.
Open diagnoses tab: Z Limit Switch is active (but it shouldn't be). Unable to jog Z axis. Pressing limit switch does nothing.
Open Config/Mach. Go to Inputs tab, Press OK.
Z Limit Switch goes inactive (as it should be). Able to jog Z axis. Pressing limit switch now works as expected.

on the Inputs screen, Motor 2-- and Motor 2++ are set to "Mapping enabled, SmartBobUSB, Pin 13, Active Low ticked"
Other limit switches are fine. They are Active Low unticked.

It does this every time I restart MACH4.

Running on Windows 7 Professional, 64 bit.
Title: Re: Mach 4 Bug Reports
Post by: bob_at_pmdx on March 04, 2015, 09:32:21 AM
Hi Neil,

There is an issue between our plug-in and the Mach4 core displaying the correct current values of the input signals on startup, though I haven't seen a case where togging the switch hasn't fixed that.  Something seems fishy since only your Z limit switch input refuses to toggle (and only until to enter and exit the config screen).

Since this involves the PMDX SmartBOB plug-in and/or device, please re-post this on our support forums so we can help figure out what is going on.  If this does turn out to be a Mach4 issue we can report that back here.  Please go to:

http://www.pmdx.com/PMDX-Forums

Some of the information we will need:

- Mach4 build number
- PMDX plug-in version
- PMDX SmartBOB firmware version

All of these are available from our plug-in configuration dialog.  Go to the Mach4 "Configure" menu, then select "plugins...", then click on the "Configure" button on the line for the PMDX-SmartBOB-USB plug-in.

Bob
PMDX
Title: Re: Mach 4 Bug Reports
Post by: NeilD321 on March 04, 2015, 04:31:54 PM
Hi Bob,

Actually, I'm going to ignore it. I decided to rewire my Z limit switch to Active High ( as it's safer ) only to find the switch was a bit dodgy.
I've replaced the switch and wired it Active High and now all is good.
Title: Re: Mach 4 Bug Reports
Post by: patton on March 13, 2015, 12:31:58 PM
Not sure if this is a bug or if it's just something in my script..... if I have my machine disabled and hit a keyboard jog key and then I enable the machine it will start moving the axis even though the jog key is not being pressed anymore.

Dave
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on March 14, 2015, 03:34:35 PM

LED on Mach screen hide when 'hidden' is set to 1, but do not display when 'hidden' is set back to zero
Title: Re: Mach 4 Bug Reports
Post by: KingKerf on March 17, 2015, 02:35:52 PM
When in the screen edit mode, if I try to type an incorrect format type into the format property of a DRO such as "1f%" and hit enter, it causes the program to crash and close and I lose all of my work. very frustrating when I am a little lisdexic sometimes.
Title: Re: Mach 4 Bug Reports
Post by: KingKerf on March 17, 2015, 05:09:59 PM
When you cut and paste a static text field from one page to another in the screen edit mode, the text field looses its BOLD style setting.
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on March 18, 2015, 09:15:16 AM

LED on Mach screen hide when 'hidden' is set to 1, but do not display when 'hidden' is set back to zero

Update: This problem seems to occur only when the controls are in a panel.
Title: Re: Mach 4 Bug Reports -- Homing issues
Post by: Bronk on April 05, 2015, 07:53:31 PM
I am using mach4 with ESS
The machine will home but:
1. Homing speed is extremely slow. It does not matter what speed percentage I set in the config homing config screen, it alwasy is just a crawl. I have not measured theactual speed but it is << 0.1 inches / sec and rapids are currently set for 300 IPS.
What would be desirable would be a routing to go rather quickly to home (if not already at home), back off then crawl in for accurate stop
2. The home offset does not seem to work.  My Z axis trips the home switch when it is all the way up (roughly +6.5" compared to the table top). I cant get the home offset to set a value, it is always 0 when homed.
I have saved these values and restarted multiple times but no luck.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on April 05, 2015, 08:51:12 PM
you will need a script to do it in M4
Title: Re: Mach 4 Bug Reports
Post by: Chaoticone on April 05, 2015, 09:07:54 PM
In the ESS config you can set the to and return speeds for homing.

Later plugins are rumored to respect the home off distance.
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on April 06, 2015, 06:01:27 AM
Is there a fully functional plugin yet? The website still has the initial Beta plugin, several months old, which doesn't include many features.

Dan
Title: Re: Mach 4 Bug Reports
Post by: Chaoticone on April 06, 2015, 08:05:17 AM
I got a test plugin from Greg a few weeks ago that was a breeze to setup and seems rock solid with the very limited testing I did. But, it was a test plugin. I know Greg is planning to post a new plugin soon. What features will be or not be implemented is something Greg would have to answer.

Brett
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on April 06, 2015, 06:54:13 PM



The 'gauge' screen item does not seem to work at all. 
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on April 06, 2015, 06:57:44 PM

Mach4 screen editor crashes when a few items are deleted.

Upon restart, sometimes the last couple edits are there and sometimes not.

It is completely random, so no clues to provide.

Win7 Pro 64bit
Title: Re: Mach 4 Bug Reports
Post by: Bronk on April 06, 2015, 09:18:53 PM
setting the home speeds in ESS did work. However if I try homing 3x in a row then Mach logs up with sometimes a warning about a bad MDI state.
May seem like an odd thing to do but I was looking for a quick way to test home switch repeatability.
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on April 07, 2015, 11:59:30 AM

Modbus diagnostic window will not close while Modbus is running.
Title: Re: Mach 4 Bug Reports
Post by: bar553 on April 20, 2015, 12:56:05 PM
This may be a bug
I have a 3020 engraver, working with Darwin and M4 on an XP machine.  The engraver has no home switches. 
I have all three axis jogging in the correct direction..  From the home position i have established.   When I enable soft limits on the program screen , X and Y behave correctly. and stop at the designated place.  Z is not behaving.   The jog buttons reverse with the switch on, I jog negative(down) and the motor goes up...... Turn the switch off and normalcy returns...
Title: Re: Mach 4 Bug Reports
Post by: pbarratt on May 03, 2015, 11:02:45 AM
Having a problem when switching display units.  Once I enable Mach 4 after start up, I cannot then disable, configure Mach 4 for the other (metric to inch or inch to metric) then re enable Mach and have the displayed units correct.  In other words, when Mach 4 is once enabled, you cannot change the displayed units without restarting Mach.  This is NOT the setup, just the display units.

As a side note, I notice that about 5 seconds after opening the mach configuration screen, the Mach screen behind it repaints.  No changes to the content that I can see.  Maybe a clue?

Peter
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 04, 2015, 12:10:49 AM
I was looking for a way to change jog mode in the "Mach4CoreAPI" document set for

mcJogGetFollowMode

and received "This page can't be displayed"  ...see attached.
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on May 11, 2015, 04:19:45 PM
I discovered an interesting issue with Mach4 and the latest plugin for the Ethernet SmoothStepper.  In some cases when starting MACH4, it does not find the ESS.  You can verify this by clicking on the diagnostic tab for the Plugin and you will see nothing gets filled in, which is identical to what happens when your firewall is not open to the MACH4 GUI.  Keep in mind many times when you start this works, just not 100% consistent.  The interesting issue is if you unplug the parallel cable which goes to a breakout board which feeds Panasonic amplifiers for the Panasonic servos, suddenly the motors on the CNC table start moving the table around and I have to kill the power.  Seems like many steps are being held in a buffer somewhere and unplugging the parallel cable from the ESS suddenly allows the drives to start moving the motors, very strange.  When things come up normally, MACH4 moves all the motors  perfectly, all homing works, and Gcode executes.  Next is to work on the pendant using POKEYs and Spindle control of the Huanyang VFD.  I have not seen anyone post getting a modified version of modbus working with Huanyang products.  Thanks

Russ Larson
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 07:58:24 AM
Using an input to control a button does work.

I used input #0 to control the <Enable/Disable> button.  It appeared to work on the surface and Mach 4 appeared to change states.  I tested the jogging function after and it did not work.  Using the screen <Enable/Disable> button and the jogging function now works.

What was the purpose of allowing an external input to change the state of a button if it does not change the state of the function the button controls?
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 08:05:47 AM
WARNING!!!!!

If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!


Type of controller: ESS
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 08:10:40 AM
Problem with Mach 4 Jogging display:

Configuration:
ESS, Motors #0-#3 (X, Y, Z, A)

Problem Description:
Set Jogging display for Mode = "Step", Increment = 1.000.  Only the Z (Motor #3) increments by 1.000 for each click of the <Z+> or <Z-> jog button.  All other jog buttons are Mode = "Continuous"
Title: Re: Mach 4 Bug Reports
Post by: DazTheGas on May 15, 2015, 08:30:56 AM
Must be something in your setup, just downloaded latest build, my setup is same as yours and works fine.

DazTheGas
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 08:33:01 AM
I started with a new machine configuration last night.  Is there a setting I might have missed??

Maybe I should delete the directory and start over.
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on May 15, 2015, 08:47:56 AM
TimGS,

Your issues seems to be related to the issue I reported with the ESS.  In my case Mach4 did not see the ESS on startup and would ask if I wanted to try and connect again.  You try that repeatedly and nothing happens.  Then I check the diagnostics for ESS and nothing is populated.  Next I unplug the parallel cable from the ESS and sudden the motors start moving across the table and I have to kill the power switch.  I never even touched the jog buttons on the screen. About 85% of the time when I start MACH4 it finds the ESS fine and I have no issues.  Now if I can figure out why MACH4 does not like the POKEYS plugin I could start working on my pendant.  LOL

Russ
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 09:12:50 AM
I noticed that when configuring Mach 4 and Plugins like the ESS the Mach 4 software seems to be unstable.  I find myself configuring then restarting to make sure nothing is goofy {A technical term :)) }

As far as being similar, they could be.  I will start the machine up from a power off state and try to recreate and isolate the problem.  

The question is where is the problem; in the ESS or Mach 4?  Once the jogging switches are mapped to the jogging functions does the ESS service the interrupt directly and process the jogging inputs or does the input signal get serviced by the Mach 4 core and sent back to the ESS as a step and direction.
Title: Re: Mach 4 Bug Reports
Post by: patton on May 15, 2015, 09:58:36 AM
"If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!

Type of controller: ESS"

I reported this a while back, I'm using Darwin and have the keyboard set up for jogging.  little panic when the machine starts moving when ya don't expect it to. wasn't sure if it was just my setup or something with Mach4.

Dave
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 15, 2015, 12:05:25 PM
"If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!


What are 'jogging inputs' ?
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 15, 2015, 12:07:25 PM
Not sure if this is a bug or not, and I have asked that question in the Modbus thread, but thought I would enter it here also in case it is a bug and these are being collected.


Creating coils in Modbus does not create corresponding registers.

Is this a bug or is there a different procedure to access coils?
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 12:15:02 PM
"What are jogging inputs?"

Jog Axis +/-
e.g. Jog X+, Jog X-,Jog Y+... Physical switches or screen <buttons> that are mapped to Command axis to jog in the +/- direction 
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 15, 2015, 02:00:07 PM
Not sure if this is a bug or not, and I have asked that question in the Modbus thread, but thought I would enter it here also in case it is a bug and these are being collected.


Creating coils in Modbus does not create corresponding registers.

Is this a bug or is there a different procedure to access coils?

Never mind, figured it out . . . .
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 15, 2015, 02:02:01 PM
"What are jogging inputs?"

Jog Axis +/-
e.g. Jog X+, Jog X-,Jog Y+... Physical switches or screen <buttons> that are mapped to Command axis to jog in the +/- direction 

Your post was about physical switches (and you also mentioned ESS.)

Where/how do you have them connected to MACH4?
Title: Re: Mach 4 Bug Reports
Post by: TimGS on May 15, 2015, 05:19:11 PM
Update:

WARNING!!!!!

If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!

Type of controller: ESS

I started with a clean (delete all) load...
After configuring ESS, Switches and Motors I brought Mach4 up from a cold start. 
I pressed the <Jog A +> switch and the motor started to move though the machine wasn't enabled. 
To stop the motor enabled then disabled Mach4.  All stopped. 
Enabled Mach4 then put the Jog Mode to Step with an Increment of 1.0
Disabled Mach4 then pressed the <Jog A +> switch and the motor moved 1.0
Looks like the "Enable/Disable" state isn't being checked in the Jog Function
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 16, 2015, 02:57:15 PM
It is my impression that the Mach Team wants only bug reports in this thread, and not discussions.

There is a thread going specifically about interfacing Jogging hardware to MACH4 and you may find some useful information there. I am headed there now to add a few comments on this topic.
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 17, 2015, 07:14:36 AM

If you have physical switches tied to your jogging inputs and you touch a switch prior to enabling Mach 4 the motors will start moving and not stop!!!!!!

Type of controller: ESS

Looks like the "Enable/Disable" state isn't being checked in the Jog Function

My jogging device is interfaced more or less directly with MACH4 thru Modbus and the PLC script and I am not having the same issue. There are several people building and using jogging interfaces thru the keyboard plug-in and that seems to be working fine.

Since you are interfaced thru the ESS, it might be possible that the problem lies with the ESS and not with MACH4.

It sounds like an Uber-Nasty bug so you might consider posting it in the Smoothstepper area (if you have not done so already).
Title: Re: Mach 4 Bug Reports
Post by: patton on May 17, 2015, 10:13:21 AM
simpson36

"My jogging device is interfaced more or less directly with MACH4 thru Modbus and the PLC script and I am not having the same issue. There are several people building and using jogging interfaces thru the keyboard plug-in and that seems to be working fine.

Since you are interfaced thru the ESS, it might be possible that the problem lies with the ESS and not with MACH4.

It sounds like an Uber-Nasty bug so you might consider posting it in the Smoothstepper area (if you have not done so already)."


I posted a while back about this and I'm using Darwin so It's a Mach4 bug... here's what happens.... I have the keyboard setup for jogging I didn't do any scripting to use the jogging just set up the keys in the mach4 keyboard setup.

When the machine is disabled and I press any of the jog keys on the keyboard nothing happens because I have a charge pump connected.... but as soon as I hit the enable button the axis will start jogging without any jog buttons being pressed.... if you know not to do that no problem but If people don't know it could happen someone could get hurt or stuff could get wrecked..... it's a safety issue.

 It could be the keyboard plugin if ya consider that being seperate but I still consider that part of the Mach4 software.

Dave
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 17, 2015, 10:44:46 AM
It could be the keyboard plugin if ya consider that being seperate but I still consider that part of the Mach4 software.

I agree on both counts. A plug-in provided by Newfangled Solutions is definitely a part of the software.

This bug got my attention because I am finishing up a jogging device at this time. I started MACH4 with a continuous stream of jogging moves flowing into MACH4 from the TCP Modbus to the PLC script (ahead of all the enabling code) and there was no movement and nothing was queued up or buffered from the input stream.

Keyboards and/or their associated drivers  (be it MACH4, Windows, various key grabbers, key snoopers and so on) have buffers, so I would speculate that the problem is in the plug-in. I'm guessing that the user does not have access to flush the buffer on startup and it would *appear* that MACH4 and/or the Plug-in is not doing that either. That would explain keystrokes being stored and released to MACH4 as soon as it accesses the plug-in.

I'm not a keyboard expert by any means, but I would not be surprised to find that the physical keyboard itself has a small internal buffer, in which case, flushing the Plug-in may not be adequate. The plug-in would need to collect all available characters in the keyboard buffer and flush everything before passing the first post-initialization key code.

The above is purely speculation on my part, and even if it is correct, I don't think the user has access to the area where a solution can be made.  Very nasty bug. Hopefully this one gets escalated.

 

Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 23, 2015, 01:35:26 AM
keyboard plug is still dead
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on May 23, 2015, 04:18:05 PM
Simpson36,
Interesting, I have been playing with the POKEY plugin for MACH4 and it has buttons for jogging X,Y,Z,A etc both + and negative.  When the plugin is installed as soon as I touch the Jog X+ button it starts going and keeps going even when you let your finger off the button.  I had to get to the jog screen and press the Jog X- button on the screen to get this to stop.  If you reset the DROs to zero and jog using the buttons on the MACH4 screen and then touch the buttons on the pendant they work correctly, but the first time it will always run away.  This appears to be a bug in MACH4.

Russ
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 23, 2015, 05:41:58 PM
there needs to be a code added to the plc and other to stop jogging working when the machine is not enabled
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 24, 2015, 03:37:53 AM
Simpson36,
Interesting, I have been playing with the POKEY plugin for MACH4 . . . . .
Russ


USB or Ethernet?
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on May 24, 2015, 07:41:44 AM
Simpson36,

I have both but have been working with the USB Pokey for my pendant.

Russ
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 24, 2015, 08:54:48 PM
Simpson36,

I have both but have been working with the USB Pokey for my pendant.

Russ


Russ, thank you for the response.

I have the USB version of the PoKeys, but have never used it.  I planned to purchase the Ethernet version, but the functionality that it provides is already available to my application thru the Ethernet interfaced Arduino DUE processor that I use.

The Arduino DUE continues to be able to handle the ever increasing loads I am putting on it, but in the event it stalls, I have the new Rasberry processor in a box waiting to be pressed into service if needed.

The USB version of anything has two ways of interfacing with a PC. One is as a native USB device and the other far more common (unfortunately) method is via a single chip 'converter', the most popular of which is made by FTDI, to emulate an old serial COM port.

ALL COM emulators require drivers and It is reasonable to assume that the driver would have FIFO buffers to emulate any modern UART chip.

Note that I do not know  if this is the case or not with any particular device, but I do think it is a reasonable assumption, which if true, would result in the same behavior that I described in an earlier post. Characters are trapped in the buffer and released when MACH4  starts and accesses the buffer without first flushing the buffer.   Again, that is pure speculation, but with a basis.

I can add that MACH4 is derelict in initializing a number of processes, not just serial plug-ins.  The screen does not initialize properly in that any custom buttons are in a completely random condition on start-up regardless of the initial state of the control.

It has been suggested by another post that code would need to be added to the PLC to properly initialize MACH4, but I strongly disagree with that premise.  I have had the last 9 or 10 questions go unanswered on this forum and developer participation seems to have pretty much ended. This seems to me to be heading for a repeat of the MACH3 norm of never ending unfixed and unacknowledged issues.

If that turns out to be the case, and extensive programming is needed to make MACH4 do what it should do out-of-the-box, I would be more inclined to follow the lead of others and abandon MACH4 in favor of the Kflop or Unix solutions.
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 24, 2015, 09:07:43 PM
I agree that developer participation is sorely needed here.
It often appears that the developers have no idea of what gets posted here.
Brian does answer questions on the Yahoo group, but almost all Mach4 activity is here.

The developers aren't doing anything to inspire confidence in those hoping for the Mach4 that we've been waiting years for.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 24, 2015, 09:34:16 PM
if you look at the plc and other bits they have a on off for screen buttons, axis`s but not jog it probley needs a on/off for jogging to not work when the machine is not enabled if its not the screen jog being used that is disabled a different way
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 24, 2015, 09:35:30 PM
I agree that developer participation is sorely needed here.
It often appears that the developers have no idea of what gets posted here.
Brian does answer questions on the Yahoo group, but almost all Mach4 activity is here.

The developers aren't doing anything to inspire confidence in those hoping for the Mach4 that we've been waiting years for.

your a mod ger have a word with them, poppabear cant do it all
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 24, 2015, 10:22:37 PM
if you look at the plc and other bits they have a on off for screen buttons, axis`s but not jog it probley needs a on/off for jogging to not work when the machine is not enabled if its not the screen jog being used that is disabled a different way

No,this should not be in user accessible code. When it's disabled, it should be disabled, an it should be done where it canct be changed.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 24, 2015, 11:40:10 PM
its this bit here from screen load whats x,y,z,a
function AxisEnable()
    local inst = mc.mcGetInstance();
    local ena
    ena = IsAxisEnabled(0);
    scr.SetProperty('xPos', 'Enabled', ena);
    scr.SetProperty('xNeg', 'Enabled', ena);
    scr.SetProperty('btnZeroX', 'Enabled', tostring(ena));
    scr.SetProperty('btnZeroX2', 'Enabled', tostring(ena));
    scr.SetProperty('btnRefX', 'Enabled', tostring(ena));

and there a chunk in the PLC that stop screen buttons working under certain states yes that should be locked away but you would have to get someone to put them in if you had more than x, y, z, a and different screen buttons other wise there would have to be a lot of basic screens to cover all requirements.

I may be wrong.

changing the scripts whats there now makes them work when you don't wont them to or not work when needed I played with them and had to reinstall so they should have a note with them don't touch

it all works as it is with no run away axis`s when you have not got any external control over screen buttons add in external control as people have found and bad things happen, that's why I think there needs to be stuff added to stop it happening
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 25, 2015, 07:43:43 AM

The PLC has aces to the jogging functions, but it cannot effect anything until it is started. From the description of the behavior of the 'runaway jog' issue, it happens very early in the startup sequence.

If the solution was as simple as adding a few lines to the PLC, one would think they would have done that by now, given the exposure this bug brings with it.

   
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 25, 2015, 03:35:28 PM
have you had a look what happens to screen button`s when not enabled to enabled there is a differences non screen buttons have a different behavior. how can it be pre put in everyone will set up external buttons a different way

jogging with the same keys as M3 does not have this problem I am using M4 every day at the moment useing different keys bad things happen
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 26, 2015, 01:40:03 AM
Looks like a bug:

Trying to execute Gcode from LUA. This script works fine:

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\n")

However, with the below function, the numbers in the DROs do not continuously update, but only when the final destination is reached.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G0 X10 Y10\n")

When trying to execute two line of Gcode, like below, the DROs again don't update continously, but only when the final point is reached.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G0 X5 Y5\n")

Dan
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 02:35:30 AM
have a read of this http://www.machsupport.com/forum/index.php/topic,28556.40.html
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 26, 2015, 03:18:02 AM
Not really explains the issue I mentioned...

Dan
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 03:34:01 AM
what are you running it as button, G code or macro
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 26, 2015, 03:40:19 AM
I have this code in a button.

Dan
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 03:58:39 AM
try this

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G0 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G0 X5 Y5\n")
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 26, 2015, 04:10:49 AM
Already have. Makes no difference.

Dan
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 05:28:12 AM
this works
 local inst = mc.mcGetInstance()
        mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\nG0 X5 Y5\n")
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 26, 2015, 06:07:10 AM

When trying to execute two line of Gcode, like below, the DROs again don't update continously, but only when the final point is reached.

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G0 X5 Y5\n")

Confirmed behavior in DRO. Not running motors yet so don't know if physical movement is also effected, but judging by how fast the line of code goes by, it is hard to imagine the motors are moving correctly.

Here is a Work Around:

mc.mcCntlGcodeExecute(inst, "G0 X10 Y10 F5\nG0 X-10 Y-10 F5")

Above line counts correctly in DRO
Title: Re: Mach 4 Bug Reports
Post by: Dan13 on May 26, 2015, 08:20:53 AM
OK. The workaround works.

Dan
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 26, 2015, 04:44:16 PM

Slightly better work around:


mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

This will perform the rapids as expected.


Caveat: Running above code from the LUA editor,  if the motion is stopped with the on-screen stop button, no amount of coaxing would make it run again short of closing and reopening MACH4. Might work better saved as a proper macro. I stopped messing with it at the above work around.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 05:40:13 PM
that don't work well in a button if you read back it has been tried if you read the link it says what happens with each type of gcode execute or what ever 
also the only difference is you put in a F word to what I had all ready posted if you don't have a F word it uses the default speed
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 26, 2015, 08:06:11 PM
that don't work well in a button if you read back it has been tried if you read the link it says what happens with each type of gcode execute or what ever 
also the only difference is you put in a F word to what I had all ready posted if you don't have a F word it uses the default speed

I really don't understand what you are saying here, but if you read carefully, you might notice that F is not the only thing different. The reason for the F is that the codes are now G1 instead of G0.

As far as making a proper macro to put in a button or anywhere else. I also already covered that.

I think you are accustomed to having finished code plopped in your lap, but I do not have time for that. I just point people in the right direction and for all but the complete newbee, that is usually enough. I think the fellow having the problem is plenty clever enough to take it from here.

Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 08:16:53 PM
mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

this does not work properly in a button its the wrong code for button
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 26, 2015, 09:55:03 PM
so we are clear and anyone that comes a cross this, this does not work properly in a button script it will work some what as a single line of G code

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G0 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G0 X-10 Y-10 F450")

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G0 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G0 X5 Y5\n")

local inst = mc.mcGetInstance()
mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10\n")
mc.mcCntlGcodeExecute(inst, "G1 X5 Y5\n")


this does for more than one G code move in a button

local inst = mc.mcGetInstance()
        mc.mcCntlGcodeExecute(inst, "G0 X10 Y10\nG0 X5 Y5\n")

local inst = mc.mcGetInstance()
        mc.mcCntlGcodeExecute(inst, "G1 X10 Y10\nG1 X5 Y5\n")

having it like this wont work ever having G1 does not help it to work or a F

mc.mcCntlGcodeExecute(inst, "G0 X10 Y10")

mc.mcCntlGcodeExecute(inst, "G0 X0 Y0")

or
mc.mcCntlGcodeExecute(inst, "G0 X0 Y0 X10 Y10 ")

the reason is here http://www.machsupport.com/forum/index.php/topic,28556.40.html

as I have been informed above is not quite correct

this is

local inst = mc.mcGetInstance()
local code = "G0 X10 Y10\n"
code = code .. string.format("G4 p2\n")
code = code .. string.format("G1 X-10 Y-10\n")
code = code .. string.format("G4 p2\n")
code = code .. string.format("G1 X0 Y0 F150\n")
mc.mcCntlGcodeExecute(inst, tostring(code))
Title: Re: Mach 4 Bug Reports
Post by: poppabear on May 26, 2015, 10:23:52 PM
looks like Craigs code from over a year ago, or so.....
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 27, 2015, 12:47:54 AM
someone set it to me so I thought I better put down what does and does not work in a button or what works as one line of code instead of people seeing the argument over how to do it when it was not quite correct from the start can that silly bit get removed please
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on May 27, 2015, 05:32:13 AM
mc.mcCntlGcodeExecuteWait(inst, "G1 X10 Y10 F450")
mc.mcCntlGcodeExecute(inst, "G1 X-10 Y-10 F450")

this does not work properly in a button its the wrong code for button

I don't understand your fixation with a button. I did not say the code would work in a button and the OP was reporting a bug, not asking for button code.

To execute a couple of lines of G-code from a button, a simple solution is this:

local inst = mc.mcGetInstance();
local rc;
rc = mc.mcCntlMdiExecute(inst, "G1 X10 Y10 F450\nG1 X-5 Y-5 F450")



"Lets use this topic to post any bugs we find in Mach 4. Lets keep this topic clean and to the point."


This thread is for bug reports and perhaps confirmation of reported bugs and perhaps even work around for reported bugs, but  I think this conversation has gone far off topic for this thread, so I'm done with it.

Have a nice day.

Unsubscribing . . .
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 27, 2015, 05:44:13 AM
Reply #363
Title: Re: Mach 4 Bug Reports
Post by: DazTheGas on May 30, 2015, 06:52:50 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
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on May 31, 2015, 08:36:52 AM
Does anyone know if there is a change log located anywhere for Mach4?  Searched everywhere and can't find the change log to see what is being fixed in each load.  Thanks
Russ
Title: Re: Mach 4 Bug Reports
Post by: ger21 on May 31, 2015, 09:03:21 AM
Not publicly available.
From the Yahoo Group:
Quote
is there a change log anywhere?....................


The SVN server has all that data.. I don't think we put that out for public consumption. some of the comments are a little colorful LOL.

Thanks
Brian
Title: Re: Mach 4 Bug Reports
Post by: dude1 on May 31, 2015, 05:05:16 PM
there no change log of use to see
Title: Re: Mach 4 Bug Reports
Post by: cpinfold on May 31, 2015, 11:19:07 PM
I'm running build 2472 and am unable to get limit sensors in Mach4 to work with an ESS and C25 BOB.  The issue is that Mach4 and the ESS conflict in their reading of the switches state and if I get them to agree, I still have no motion.  

I have 2 active low limit switches that I am connecting to my X axis as X-- and X++ limits.  I have added them to Port 2, pins 2 and 3 and selected Active Low in the ESS.  Port 2, Pins 2-9 are set as inputs in the ESS (and that is the only supported config of the C25 on port 2).  I have confirmed by measuring the voltage at the BOB that the inputs are 5V until tripped and then they are ~100mV.  When in the ESS diagnostics the limit switch inputs are unchecked until they are tripped (as they should be).  However in the Mach diagnostics (default screen), the two limit switches are lit up as though they are tripped and go out when the limits are actually tripped (opposite what is expected).  Although Warp9 specifically says NOT to set the active low in Mach4, I have even tried that.  Even though the display in the Mach4 diagnostics are now correct at that point the machine doesn't move when jogging.  When the active low setting is off in Mach and Mach shows the limit switches tripped, no axis move and the X axis reports that you can's move towards a limit.  I have a solid green light (and no red) on the ESS as I did before adding the limit sensors.

If it helps, the first line in my history shows "ESS: Limit hit" and when jogging away or another axis the Machine State shows "Jogging", but the DRO's don't change and the machine doesn't move.  The diagnostic logging shows: "2015-05-31 23:00:43.168 - API: mcJogIncStart() called. Axis 0, inc = -1.000000" for each jog, but no other information.  After every configuration change I have exited Mach and restarted it.    

I have tried connecting just one, or using the 5V source on the C25 and every other permutation I can think of with the same results.

Has any one else experienced this or have any suggestions? Hopefully I'm just missing something?

I did see a Youtube video by DaztheGaz where he has limits connected to his ESS and they appear to be working.

Thanks!
Title: Re: Mach 4 Bug Reports
Post by: Steve Stallings on June 01, 2015, 10:52:45 PM
there no change log of use to see

PMDX now has a Release Notes Log file that describes  each new build of Mach4.

This file includes lots of items that are only significant to developers so don't be
overwhelmed by it. The file can be seen here:

http://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/Mach4Hobby%20build-release-notes.txt

We also make available our archive of previous builds of the Mach4 installer:

http://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/
Title: Re: Mach 4 Bug Reports
Post by: Screwie Louie on June 02, 2015, 12:45:10 AM
Way to go Mr. Stallings! PMDX to the rescue! Now that's what I call customer service  ;D
Title: Re: Mach 4 Bug Reports
Post by: Screwie Louie on June 02, 2015, 12:47:51 AM
Has anybody noticed when entering and exiting Edit Screens their "Main tabs" panel keeps dropping from the top by a value of 6 then 26 then 36 or something whereas you have to constantly resize and format your panels? Just wonderin...
Title: Re: Mach 4 Bug Reports
Post by: dude1 on June 02, 2015, 12:55:46 AM
its a random bug I have had it a couple of times
Title: Re: Mach 4 Bug Reports
Post by: patton on June 02, 2015, 07:35:32 AM
Has anybody noticed when entering and exiting Edit Screens their "Main tabs" panel keeps dropping from the top by a value of 6 then 26 then 36 or something whereas you have to constantly resize and format your panels? Just wonderin...

I get that too ...I've just gotten used to making sure the screen is up all the way and to the left when I open the screen editor .... if not I move it close the screen editor without saving and re-open it.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on June 02, 2015, 12:20:52 PM
Steve THANKS for the List.  It is a BIG help .

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: cpinfold on June 05, 2015, 08:27:52 AM
I'm running build 2472 and am unable to get limit sensors in Mach4 to work with an ESS and C25 BOB.  The issue is that Mach4 and the ESS conflict in their reading of the switches state and if I get them to agree, I still have no motion. 

I have 2 active low limit switches that I am connecting to my X axis as X-- and X++ limits.  I have added them to Port 2, pins 2 and 3 and selected Active Low in the ESS.  Port 2, Pins 2-9 are set as inputs in the ESS (and that is the only supported config of the C25 on port 2).  I have confirmed by measuring the voltage at the BOB that the inputs are 5V until tripped and then they are ~100mV.  When in the ESS diagnostics the limit switch inputs are unchecked until they are tripped (as they should be).  However in the Mach diagnostics (default screen), the two limit switches are lit up as though they are tripped and go out when the limits are actually tripped (opposite what is expected).  Although Warp9 specifically says NOT to set the active low in Mach4, I have even tried that.  Even though the display in the Mach4 diagnostics are now correct at that point the machine doesn't move when jogging.  When the active low setting is off in Mach and Mach shows the limit switches tripped, no axis move and the X axis reports that you can's move towards a limit.  I have a solid green light (and no red) on the ESS as I did before adding the limit sensors.

If it helps, the first line in my history shows "ESS: Limit hit" and when jogging away or another axis the Machine State shows "Jogging", but the DRO's don't change and the machine doesn't move.  The diagnostic logging shows: "2015-05-31 23:00:43.168 - API: mcJogIncStart() called. Axis 0, inc = -1.000000" for each jog, but no other information.  After every configuration change I have exited Mach and restarted it.   

I have tried connecting just one, or using the 5V source on the C25 and every other permutation I can think of with the same results.

Has any one else experienced this or have any suggestions? Hopefully I'm just missing something?

I did see a Youtube video by DaztheGaz where he has limits connected to his ESS and they appear to be working.

Thanks!

I tried changing the input pins on the C25/ESS from Port 2, pins 2 and 3 to pins 10 and 11 and it works.  My guess is there is an issue because these pins could be inputs or outputs.
Title: Re: Mach 4 Bug Reports
Post by: DazTheGas on June 06, 2015, 03:57:09 PM
This is strange, keeps popping up when I go into the mach configuration
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on June 13, 2015, 07:42:26 PM
After Loading MACH4 version 2491 with the ESS plugin, I noticed as soon as MACH4 comes up, my machine starts running away.  X,Y,Z all start moving full speed in the positive direction.  Keep in mind I never even enabled MACH4.  Just lucky I had an emergency stop button or it would have slammed into the end stops.  MACH4 on the previous several versions did not have this issue.  I have not changed the Ethernet SmoothStepper plugin it is the same April release.  Did anyone else notice this bug in version 2491?

Russ
Title: Re: Mach 4 Bug Reports
Post by: dude1 on June 13, 2015, 07:59:47 PM
check that the settings have not full in off I had that with Darwin re did the setting and it came right
Title: Re: Mach 4 Bug Reports
Post by: cncman172 on June 14, 2015, 09:41:22 AM
I discovered the issue with MACH4 running away and it has nothing to do with the ESS plugin at all.  I had also installed the latest POKEYS plugin 1.67-1.2491 which is the designated plugin for MACH4 2491.  When that new POKEY plugin is enabled and you bring up MACH4 all axis' start moving rapidly in the positive direction.  I do not have the pulse engine in the POKEY plugin enabled at all.  The only thing I had was a matrix keyboard.  I tested this several times and confirmed this is clearly caused by the latest POKEYs plugin.

Russ
Title: Re: Mach 4 Bug Reports
Post by: alcwell on June 20, 2015, 04:39:51 AM
With the latest PoKeys plugin I am getting the axis movement on startup when using the simulator as the motion deivce. I run my machine with the Darwin parallel port driver. When I select Darwin as the motion device I do not get the axis movement at startup.

Althouh this is being tirggered by the PoKeys plugin I think is also has to be looked on as an issue with Mach4. When Mach4 is disabled I would expect all axis movement to be disabled as well.

Alastair
Title: Re: Mach 4 Bug Reports
Post by: dude1 on June 20, 2015, 05:12:48 AM
if you don't need sim remove it. it can make bad things happen on some computers
Title: Re: Mach 4 Bug Reports
Post by: Pedio on July 04, 2015, 11:48:33 AM
If I use a button to select a jog increment (e.g., JogInc.2) the TextJogInc does not seem to know about the change. It continues to show whatever the last value that was achieved by using the btnCycleJogInc.

Am I missing a parameter or is this a bug.
Title: Re: Mach 4 Bug Reports
Post by: Blacksmith on July 11, 2015, 11:39:58 AM
anybody seen this behaver before  ? it happens when i hit cycle stop and hit cycle start again , in the middle of a circle .
Title: Re: Mach 4 Bug Reports
Post by: dude1 on July 11, 2015, 04:40:20 PM
you should not be hitting cycle stop use Feed Hold 
Title: Re: Mach 4 Bug Reports
Post by: ger21 on July 11, 2015, 05:27:18 PM
But that doesn't mean that it's not a bug.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on July 11, 2015, 06:12:59 PM
 very true ger, I reproduced it hitting stop shifts the Zero over it did not happen with feed hold
Title: Re: Mach 4 Bug Reports
Post by: Pedio on July 23, 2015, 02:03:01 PM
Not sure if this has been reported but occasionally the display showing the tool paths that have been run by the machine does not line up with the toolpaths on the display.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 24, 2015, 07:03:12 PM
The Mach4 screen editor is crashing on an hourly basis. You never KNOW what sets it off. A lot of times it is WHEN you go to SAVE that it crashes. AND that is a real treat to endure. When it crashes it locks Windows HARD requiring you to power it down then restart.

NOT good, (;-) TP

Title: Re: Mach 4 Bug Reports
Post by: Steve Stallings on July 24, 2015, 07:17:01 PM
Build 2568 introduced a bug in the core that causes random crashes.

Build 2580 has just been posted and is supposed to include a fix.

http://www.pmdx.com/Downloads_Mach4/Mach4_Hobby_Releases/
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 27, 2015, 12:20:52 AM
Version updates, EVERYTIME I do a version update Mach4 DUMPS OUT all my setup info . I have to start over from scratch EVERY time.
Title: Re: Mach 4 Bug Reports
Post by: dude1 on July 27, 2015, 12:33:31 AM
yer that`s a pain fix it please
Title: Re: Mach 4 Bug Reports
Post by: smurph on July 27, 2015, 01:37:43 AM
Make a copy of the Mach4Mill profile and use it instead.  That way, your settings do not get overwritten.
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 27, 2015, 01:28:09 PM
V2508 seems to have helped the Random crashing. BUT it introduced another bug in the SetVN  . The SetVN is reporting an error in the G code using #vars  EVEN though it was never called to define any named Vars UNLESS there is one hiding somewhere ??  We will get a View table to be able to SEE all the Named Variables that are created/associated. This example would be a good reason to have one.


Thanks, (;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 27, 2015, 02:07:16 PM
Another glitch in the new function that reports the tool change status to the Mach4 status line. It is NOT reporting the status of the tools correctly ALSO the wording NEXT TOOL is wrong ,  that implies that it would be the NEXT TOOL in the Gcode file. The word that is correct would be Selected Tool.

Also the message itself should be standardized as to content   Selected Tool = 1   not == . And yes I know where that comes from.

NOW IT WOULD be nice to be able to see the next tool call in the gcode stack to be called (;-)  I can do it in Mach3.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 27, 2015, 02:54:59 PM
V2580  after a random period of time the toolpath stops responding to panning. All screen views are effected.  To make it work again I have to ether reload the screenset(stock) or load another screenset and it starts workiing again. THEN it works until it stops again.

It still has NOT crashed since I loaded V2580 (;-) Even in the screen editor it has not crashed out.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: BR549 on July 27, 2015, 11:20:18 PM
V2580 there are glitches in teh elapsed timer. It does NOT reset correctly when it is suppose to.

(;-) TP
Title: Re: Mach 4 Bug Reports
Post by: Dazed+Confused on July 28, 2015, 01:18:05 AM
Elapsed Timer problem here also, now starts counting as soon as i start Mach. By the time Mach is ready to use, the counter has already counted to 14 seconds. I think it appeared somewhere after version 2491.
Title: Re: Mach 4 Bug Reports
Post by: simpson36 on August 03, 2015, 07:43:46 AM
Setting up MACH4 with a CSMIO/IP-S

Step/Dir servo powered spindle will not start unless spindle speed is changed via G-code 'S' command or override.

Some of the problem went away with build 2580. M4 works now, but M3 does not.

Based on the behavior, I would speculate that MACH4 only sends speed change info to the plug-in, because altering the speed started the drive.

It would seem that the speed data needs to be sent to the plug-in with any spindle start command. Why M4 works and M3 does not is a mystery.

M3 used alone does not start the spindle, however the following:

S5 M3
S1000

results in the spindle starting. Prior to Build 2580, the same workaround was needed with M4, but that seems t be working now.

Title: Re: Mach 4 Bug Reports
Post by: Chaoticone on August 03, 2015, 11:53:01 AM
Any future Mach4 bug reports should be submitted via a customer support request from our Contact Us page at the following link.

http://www.machsupport.com/contact-us/

Thanks,
Brett