Messages

3141

Mach4 General Discussion / Re: enable output

« on: February 02, 2019, 07:25:00 AM »

Hi,
yes it is possible to do that. Mach4 has the following behavior when being enabled.

When the machine is first switched on the machine is disabled. That means that OGIG_MACHINE_ENABLE is low.
Machs core will ensure that the output signals OSIG_ENABLE0, OSIG_ENABLE1, OSIG_ENABLE2 etc are likewise set low.

When you hit the <Enable> button it causes an internal Mach action (Up Action) 'Enable On' as is seen in screen edit mode looking
at the event properties of the <Enable> button.

Looking at the <Enable> button properties, again in edit screen mode you can see that the 'Machine Enabled' signal is affected
by the <Enable> button.

Machs internal actions 'Enable ON' and 'Enable Off' are not available for us to see or edit. It is plain though that if the
function 'Enable On' is called (as signaled by OSIG_MACHINE_ENABLE) then OSIG_ENABLE0, OSIG_ENABLE1 etc are all
turned on pretty much simultaneously.

In order to have the axes enable in delayed fashion it is necessary to disconnect the 'Enable On' and 'Enable Off' actions.
That is possible, in effect the Up Action and Down Action events must be left blank. Note however that there is allowed
an Up Script and a Down Script. Thus you can write your own scripts which could turn on (enable) axes in a delayed
fashion. In essence your scripts run INSTEAD of Machs built in functions.

Given that you are new to Mach4 I'm wondering if you think its a good idea to delve into writing scripts this early?
I can imagine that if you had really big servo drives or something then staggering the enable signals might reduce
the in-rush currents but they would have to be huge servos to warrant such behavior.

If you think you absolutely need to do so then have at it. Otherwise just box on with Mach......the vast majority of
machining operations can be done WITHOUT having to write any special scripts and I suggest that's what you do.

There will come a time when you need something a bit different to the standard Mach offering and then by all means
write your own code, Mach4 is generously provided with the means to customize your installation. Customizing your
machine when it doesn't really need it however is a great way to waste a lot of time and make few if any chips.

Craig

3142

Mach4 General Discussion / Re: How to generate gcode to do pearling

« on: February 02, 2019, 05:00:49 AM »

Hi billskeen62,
did you end up using this code?

I have been reading/studying/experimenting with wxLua and have come up with some code that will
accept data from user on-screen input. The data is stored in registers so is persistent between sessions.

I have attached a pic of what the input dialog looks like.

Craig

3143

General Mach Discussion / Re: Touch plate + touch probe connection

« on: February 01, 2019, 11:17:40 PM »

Hi,
Mach3 has only one probe input.

You could dedicate another spare input as another probe signal but it will be too slow.

The current (one and only) probe input is a real-time input. Thus Mach decelerates/stops  the Z axis within a few usec of receiving
a probe signal ie very quickly or 'realtime'. A normal input would be signaled back to Mach from your motion controller
(either parallel port OR external controller) but it will take up 10-12 msec. Mach would then have to issue a decelerate/stop
command to the Z axis and therefore another delay of 10-20 msec. The total delay could be anywhere up to 40 msec.

If you probed very VERY slowly you could do that without to much inaccuracy. At normal probe speeds the probe
would seriously overrun the contact point and risk smashing the probe or workpiece and even if that didn't happen the
overrun would screw your accuracy.

Mach4 has four independent probe inputs, g31, g31.1, g31.2, g31.3. Mach3 has one, g31.

Craig

3144

Mach4 General Discussion / Re: How can I smooth out motion in my LUA script

« on: February 01, 2019, 11:02:34 PM »

Hi,
I'm not sure you can, at least as you have written your code.

You are using mcCntlGcodeExecuteWait(), thus Mach will execute the instruction (or instructions) and wait UNTIL
they have been executed BEFORE progressing to a new instruction. That is by definition 'Exact Stop' mode and is discontinuous.

In earlier versions of Mach it was not possible to have GcodeExecuteWait() statements one after another. It was required
that you concatenate a number of moves together and then send the whole bunch to the Gcode interpreter and motion controller.

To illustrate I will take a fictitious example. Say you want to execute this series of moves:

g0 x50 y50
g1 x100 y100  z-1 f250
g1 x150
g1 y50
g1 x50
g0 x0 y0.

You could use successive mcCntrlGcodeExecuteWait statements:

mc.mcCntrlGcodeExecuteWait(inst,"g0 x50 y50")
mc.mcCntrlGcodeExecuteWait(inst,"g1 x100 y100 z-1 f250")
mc.mcCntrlGcodeExecuteWait(inst,(inst,"g1 x150.......

and so on. This would result in a brief pause between successive moves.

As I said earlier in previous times such a technique would have resulted in an error. It was necessary to concatenate the moves:

mc.mcCntrlGcodeExecuteWait(inst,"g0 x50 y50 \n
                                                    g1 x100 y100 z-1 f250 \n
                                                    g1 x150 \n
                                                    g1 y50  \n...............................\n")
and so on. This results in one bunch of code being dispatched to the Gcode interpreter as a text string with embedded line
feed characters. In this circumstance Mach behaves normally (if in CV mode, ie normal operation condition) and blends one
move into the next.

Thus to improve the fluidity of movement you will have to rewrite your code to use very much fewer mcCntlGcodeExexcuteWait()
statements.

There is another API that may be of some help....mcCntlGocdeExecute(). As you will observe it does not wait. Thus a move will
be committed to the motion controller but the function will return to the calling program before the move has finished.
Mach can then be in the process of planning the subsequent move. It might sound like that is the answer to your prayers
but it is not.

Lets say Mach does indeed plan a second move and it dispatches it to the motion controller. It cannot blend the preceeding
move into the current one as the PREVIOUS MOVE IS ALREADY COMMITTED and CANNOT BE CHANGED. Therefore despite
the apparent ability of Mach to plan a move before the last one has executed it cannot use its normal CV blending routines.

For all that it may be worth experimenting with mcCntlGcodeExecute() because it would allow Mach to be executing a physical
move at the same time that another instruction is being processed. If that instruction is another move no advantage will be
obtained. If however the instruction DOES NOT require a physical move then the separate instruction may execute more
smoothly one after another rather than waiting as in mc.CntlGcodeExecuteWait().

Craig

3145

Mach4 General Discussion / Re: Mac4 seems to scrub the surface when moving from Work coord zero to the 1st. cut

« on: February 01, 2019, 07:04:04 PM »

Hi,
I don't claim any expertise at reading Gcode but does this line:

Code: [Select]

G28 G91 Z0.leave the Z axis at zero and  shortly thereafter the line:

Code: [Select]

G0 X41.57 Y100.524drives to the location of your first cutting move......but at Z=0!

I would estimate that machine is doing what it is told......its just that you, or rather your CAM program have told
it to do something you don't like.

Try editing the line to:

Code: [Select]

G28 G91 Z10and with any sort of luck the initial move will be 10mm above the material.

Craig

3146

General Mach Discussion / Re: Problem with stepper motor

« on: January 30, 2019, 12:44:21 PM »

Hi,
that the stops/stuttering decreased suggests that the X axis motor is overloaded and decreasing the speed reduces the overload,
hence the improvement.

There are some possibilities that need to be worked through.

First the motor could be faulty. Can you swap it for either the Y or Z motors?
The driver could be faulty. Can you swap either the Y or Z drivers?

If neither help then you will have to replace the motor with a more powerful unit. Note that steppers are sold on the
basis of their holding torque. That is only half the picture. Often high torque comes at the expense of high inductance
so the motor can only produce high torques at low speeds. Thus often a seemingly good and torquey motor will actually
perform less well than another which despite having lower holding torque has lower inductance and out perform the larger
motor at speed.

What voltage are your drivers rated to? All steppers lose torque the faster they go. One way to try to counteract that is to use
the highest voltage your driver can handle. Good brands like Geko will be rated to 72V.

Craig

3147

Mach4 General Discussion / Re: Finial switching over to Mach4 amd Ihave a few question.

« on: January 30, 2019, 12:45:02 AM »

Hi,
I don't use a fourth axis as so can't answer your question definitely.

I have heard that many have had success with using inverse time mode, this is a modal Gcode setting,
not a Mach4 setting.

Look up G93 page 54 in "Mill GCode Programming" manual in the Mcah4 Docs folder.

Craig

3148

Mach4 General Discussion / Re: Un-Supported wxNumberEntryDialog

« on: January 29, 2019, 05:49:51 AM »

Hi Daz,
thanks for your reply. Slowly getting the hang of it.

It seems that wxWidgets is vast bewildering array of options/classes/conventions/syntax.
Having the code synthesized before your eyes is very impressive.

Craig

3149

Mach4 General Discussion / Re: Anyone use mach4 recently; version 2?

« on: January 29, 2019, 04:43:45 AM »

Hi,
I've been using Mach4Hobby for 2,5 years and am of the opinion that it is light years ahead of Mach3.

I am picking that most complaints come from people who think Mach should behave 'their way' and if it doesn't
they complain bitterly. I'd further add that they also lack the imagination/inclination/capacity to understand Mach4.
Not likely to be a popular opinion but there it is.

Craig

3150

Mach4 General Discussion / Re: Un-Supported wxNumberEntryDialog

« on: January 29, 2019, 03:40:27 AM »

Hi Guys,
I have another lame newbie question.

I have set up a dialog with an TxtCtrl box and an OK button:

Code: [Select]

UI = {}


-- create MyDialog
UI.MyDialog = wx.wxDialog (wx.NULL, wx.wxID_ANY, "", wx.wxDefaultPosition, wx.wxDefaultSize, wx.wxDEFAULT_DIALOG_STYLE )
UI.MyDialog:SetSizeHints( wx.wxSize( -1,-1 ), wx.wxSize( -1,-1 ) )

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

UI.DataEntry = wx.wxTextCtrl( UI.MyDialog, wx.wxID_ANY, "", wx.wxDefaultPosition, wx.wxDefaultSize, 0 )
UI.MyDialogSizer:Add( UI.DataEntry, 0, wx.wxALL, 5 )

UI.m_button9 = wx.wxButton( UI.MyDialog, wx.wxID_ANY, "OK", wx.wxDefaultPosition, wx.wxDefaultSize, 0 )
UI.MyDialogSizer:Add( UI.m_button9, 0, wx.wxALL, 5 )


UI.MyDialog:SetSizer( UI.MyDialogSizer )
UI.MyDialog:Layout()
UI.MyDialogSizer:Fit( UI.MyDialog )

UI.MyDialog:Centre( wx.wxBOTH )

-- Connect Events

UI.m_button9:Connect( wx.wxEVT_COMMAND_BUTTON_CLICKED, function(event)
--implements wxID_OK

event:Skip()
return
end )
local rc=UI.MyDialog:ShowModal()
if rc==wx.wxID_OK then wx.wxMessageBox('success') end
if rc==wx.wxID_CANCEL then wx.wxMessageBox('failure')end

Note that I explicitly attached the button which result in:
 UI.m_button9:Connect( wx.wxEVT_COMMAND_BUTTON_CLICKED, function(event).

The problem is that when I single step through it all goes swimmingly until I get to the:
local rc=UI.MyDialog:ShowModal() statement. It executes and the dialog pops up, I can enter a string and exit with
a <OK> button click. The code executes the event handler function but at the end of the function re-encounters
the ShowModal()  function again and the dialog pops up again in a never ending loop.

As you can see I even tried putting a Return statement in the event handler but it returns straight to the ShowModal() function
again.

I'm struggling with what code needs to go in the handler that allows the handler to execute and then return WITHOUT
executing what amounts to its own calling statement.

I have read the explanation for event:Skip() but am far from sure that I understand its intent.

Craig