Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: peter g on August 23, 2021, 01:19:37 PM
-
Hey,
So I have a question with regards to Mach 4. I want to use a pulse encoder generator (jog wheel) to control the jog movements of my axis. I would like it so if a button is pressed it activates the jog wheel for a specific axis(x) and if a different button is pressed it activates the jog wheel for a different axis(y). How would you or is it even possible to connect the pulse generator to Mach 4. Also, is it possible to edit the jog increments from buttons on a panel? Any help would be much appreciated.
Peter
-
Nice to meet you.
What about MPG?
If so, in my case, I found out by looking at the following article.
URL
https://www.warp9td.com/index.php/faq/faq-pendants-and-mpgs#MultiWirePendantInMachFour
-
Hi,
That article was very informative and helpful and answers a lot of my question.
Peter
-
Hi,
So I have a question with regards to Mach 4. I want to use a pulse encoder generator (jog wheel) to control the jog movements of my axis. I would like it so if a button is pressed it activates the jog wheel for a specific axis(x) and if a different button is pressed it activates the jog wheel for a different axis(y). How would you or is it even possible to connect the pulse generator to Mach 4. Also, is it possible to edit the jog increments from buttons on a panel? Any help would be much appreciated.
All of these things are possible.
If you use an MPG that would have to be wired to your controller/BoB and then to Mach. You could have buttons OR switches to set the active axis and/or the jog
increment. There are some good examples but will still require that you do some Lua coding.
Another alternative is to use a pendant like a VistsCNC P1A, I've been using mine for seven years with Mach4. It has a two rotary switches for the active axis,
speed rate override, incremental/velocity mode, jog increment and more. They cost $160. No wiring, no programming, stands alone from your
controller/BoB so no loss of inputs......
Craig
-
Hi,
lets imagine for a moment that you wish to go the hardwired MPG route, and I have given some thought to doing so myself.
Every once in a while my USB connected pendant loses communication and the machine needs to be power cycled to bring it back,
a PITA....doesn't happen often but when it does that's when I think a hardwired pendant has advantages.
An MPG requires four wires, A+,A-,B+ and B-, unless you create a logic board that would reduce those four wires down to two,
namely Step/Direction, and that neglects the common return, so three wires in truth.
Lets say you had two three position rotary switches, each switch would require three wires (one common and the other two binary coded
for the three positions). Assuming the common return could be shared by the two rotary switches then you would require five wires for
the two switches.
Totaling the wires for this arrangement:
4 wires-MPG
4 wires-binary coded switch position (two switches)
1 wire-common return
This would require 8 spare inputs on your BoB/controller combination. Do you have 8 spare inputs?
If you want or need to economise on the inputs you could do it this way:
2 wires-Step/Dir derived from logic circuit of the MPG
2 wires-one for each of two buttons
1 wire-common return
This arrangement requires a small logic circuit be built into your pendant and that you write some Lua code to cycle through the axes
in the case of the ActiveAxis button and the jog increment in the case of the JogIncremnt button. This would reduce the number of spare inputs
required to four. Do you have four to spare?
Craig
-
Hello.
I'm using Mach3.
In my case, MPG is the following item.
I think it's easy to understand, so please take a look.
https://ja.aliexpress.com/item/1005003156339630.html?spm=a2g0s.8937460.0.0.39eb2e0eawwZPF
There are 2 wires for power supply and 4 wires for A phase and B phase.
The power supply for GND, BOB, and USB is common.
After that, you need a line for the signal.
-
Hi,
if you're using Mach3 then good luck.
Craig
-
Hi,
lets imagine for a moment that you wish to go the hardwired MPG route, and I have given some thought to doing so myself.
Every once in a while my USB connected pendant loses communication and the machine needs to be power cycled to bring it back,
a PITA....doesn't happen often but when it does that's when I think a hardwired pendant has advantages.
An MPG requires four wires, A+,A-,B+ and B-, unless you create a logic board that would reduce those four wires down to two,
namely Step/Direction, and that neglects the common return, so three wires in truth.
Lets say you had two three position rotary switches, each switch would require three wires (one common and the other two binary coded
for the three positions). Assuming the common return could be shared by the two rotary switches then you would require five wires for
the two switches.
Totaling the wires for this arrangement:
4 wires-MPG
4 wires-binary coded switch position (two switches)
1 wire-common return
This would require 8 spare inputs on your BoB/controller combination. Do you have 8 spare inputs?
If you want or need to economise on the inputs you could do it this way:
2 wires-Step/Dir derived from logic circuit of the MPG
2 wires-one for each of two buttons
1 wire-common return
This arrangement requires a small logic circuit be built into your pendant and that you write some Lua code to cycle through the axes
in the case of the ActiveAxis button and the jog increment in the case of the JogIncremnt button. This would reduce the number of spare inputs
required to four. Do you have four to spare?
Craig
Hi Craig,
Thanks for the useful information. I have a spare CNCdrive UC400ETH lying around with the breakout board that goes with it. I have it setup and running in Mach4. I used the script which will be below this post. I am able to use a series of switches to enable either the x y or z axis and also either x1 x10 x100 these all work. The only thing i cannot get to work is the MPG. I have assigned Pin A and Pin B in the plugin and mapped UC400EETH/Encoder 1 to MPG#1. I can see the LED indicators on the board change when I move the jog wheel. But it just doesnt jog the axis is there something wrong in the gcode?
-
---------------------------------------------------------------
-- Monitor the switches on the Pendant.
-- We break the three different mechanical switches into three separate function calls, since each function has a separate job.
-- We don't need to assign the MPG wheel since Mach handles that for us.
---------------------------------------------------------------
SigLib = {
[mc.ISIG_INPUT10] = function (state) --If you are not using INPUT10 for the Axis Selection X, change the INPUT#!!!!
PendantAxisChange() --This is called if there is a change with the Pendant's Axis Selection Switch Posion X
end,
[mc.ISIG_INPUT11] = function (state) --If you are not using INPUT11 for the Axis Selection Y, change the INPUT#!!!!
PendantAxisChange() --This is called if there is a change with the Pendant's Axis Selection Switch Posion Y
end,
[mc.ISIG_INPUT12] = function (state) --If you are not using INPUT12 for the Axis Selection Z, change the INPUT#!!!!
PendantAxisChange() --This is called if there is a change with the Pendant's Axis Selection Switch Posion Z
end,
-------------
[mc.ISIG_INPUT13] = function (state) --If you are not using INPUT6 for theX1 Selection, change the INPUT#!!!!
PendantSpeedChange() --This is called if there is a change with the Pendant's Rate Selection Switch X1
end,
[mc.ISIG_INPUT14] = function (state) --If you are not using INPUT7 for the X10 Selection, change the INPUT#!!!!
PendantSpeedChange() --This is called if there is a change with the Pendant's Rate Selection Switch X10
end,
[mc.ISIG_INPUT15] = function (state) --If you are not using INPUT8 for the X100 Selection, change the INPUT#!!!!
PendantSpeedChange() --This is called if there is a change with the Pendant's Rate Selection Switch X100
end,
-------------
[mc.ISIG_INPUT16] = function (state) --If you are not using INPUT9 for the Pendant EStop Switch, change the INPUT#!!!!
PendantEStopChange() --This is called if there is a change with the Pendant's EStop Switch
end,
-------------
--These next three are not part of the Pendant code, but show you a few more options for inputs
[mc.ISIG_INPUT17] = function (state) --Performs a Cycle Start
InputCycleStart()
end,
[mc.ISIG_INPUT18] = function (state) --Performs a Cycle Stop
InputCycleStop()
end,
[mc.ISIG_INPUT19] = function (state) --Performs a reset
InputReset()
end
}
---------------------------------------------------------------
-- The Input Signal for a Cycle Start Occurred. This is not needed for the rest of the pendant example
---------------------------------------------------------------
function InputCycleStart() --This will do a cycle start because of a button push
CycleStart()
mc.mcCntlSetLastError(inst, "Input Cycle Start")
end
---------------------------------------------------------------
-- The Input Signal for a Cycle Stop Occurred. This is not needed for the rest of the pendant example
---------------------------------------------------------------
function InputCycleStop() --This will do a cycle stop because of a button push
CycleStop()
mc.mcCntlSetLastError(inst, "Input Cycle Stop")
end
---------------------------------------------------------------
-- The Input Signal for a Reset Occurred. This is not needed for the rest of the pendant example
---------------------------------------------------------------
function InputReset() --This will do a Reset because of a button push
mc.mcCntlReset(inst)
mc.mcSpindleSetDirection(inst, 0)
mc.mcCntlSetLastError(inst, "Input Reset")
end
--In Mach's Config tab for MPGs, if you don't have the ESS's encoder for the pendant assigned to MPG#7, change the 7 to the number you are using:
local MachMpgNumberForPendant = 1
local PendantStepSize = 0.001 --This is in your Mach4's units, mm or Inches, whichever one you have it set to
local PendantDistanceX1 = PendantStepSize * 1 --Multiply by one
local PendantDistanceX10 = PendantStepSize * 10 --Multiply by ten
local PendantDistanceX100 = PendantStepSize * 100 --Multiply by one hundred
--These shouldn't need to be modified, but they reduce the amount of apparently random numbers in the code:
local UnmapMPG = -1 --Use this one for when Axis selector switch is set to OFF
local AxisNumber_X = 0 -- Linear axis X (one of six coordinated motion axes)
local AxisNumber_Y = 1 -- Linear axis Y (one of six coordinated motion axes)
local AxisNumber_Z = 2 -- Linear axis Z (one of six coordinated motion axes)
--Coordinated motion means all six coordinated axes get to the destination point at the same time.
--Not coordinated with motion means that axis can be doing whatever, whenever. Like a conveyor belt that is always running.
---------------------------------------------------------------
-- The Pendant's EStop switch changed...
-- This will process the Pendant's EStop Switch
-- THIS ESTOP SHOULD BE CONSIDERED A COURTESY SIGNAL, since it based on softare
-- You should still have a EStop that is pure hardwre that can disconnect power.
--If you start Mach with the button pressed in, it will not work when you need to press it!
---------------------------------------------------------------
function PendantEStopChange()
local hPendantEStop
local PendantEStop
hPendantEStop, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT9) --If you are not using INPUT9 for the Pendant EStop Switch, change the INPUT#!!!!
PendantEStop, rc = mc.mcSignalGetState(hPendantEStop)
if (PendantEStop == 1) then
mc.mcCntlEStop(inst) --Activate the EStop signal in Mach
mc.mcCntlSetLastError(inst, "Pendant EStop Activated") --Show a message in the Screen Set
else
mc.mcCntlSetLastError(inst, "Pendant EStop Cleared") --Show a message in the Screen Set
end
end
---------------------------------------------------------------
-- The Pendant's Speed switch changed... Reconfigure appropriate settings in Mach4
--This will process the Pendant's Rate/Speed Selection Switch
---------------------------------------------------------------
function PendantSpeedChange()
--Variable prep first for handles
local hX1
local hX10
local hX100
--Variable prep for signal values
local Step1
local Step10
local Step100
hX1, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT13) --If you are not using INPUT6 for theX1 Selection, change the INPUT#!!!!
Step1, rc = mc.mcSignalGetState(hX1)
hX10, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT14) --If you are not using INPUT7 for the X10 Selection, change the INPUT#!!!! -- X10 Port 3 Pin 4
Step10, rc = mc.mcSignalGetState(hX10)
hX100, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT15) --If you are not using INPUT8 for the X100 Selection, change the INPUT#!!!!
Step100, rc = mc.mcSignalGetState(hX100)
local msg
if (Step1 == 1) then
mc.mcMpgSetInc(inst, MachMpgNumberForPendant, PendantDistanceX1 )
msg = "Jog Distance X1 = " .. PendantDistanceX1
mc.mcCntlSetLastError(inst, msg) --Show a message in the Screen Set
elseif (Step10 == 1) then
mc.mcMpgSetInc(inst, MachMpgNumberForPendant, PendantDistanceX10)
msg = "Jog Distance X10 = " .. PendantDistanceX10
mc.mcCntlSetLastError(inst, msg) --Show a message in the Screen Set
elseif (Step100 == 1) then
mc.mcMpgSetInc(inst, MachMpgNumberForPendant, PendantDistanceX100)
msg = "Jog Distance X100 = " .. PendantDistanceX100
mc.mcCntlSetLastError(inst, msg) --Show a message in the Screen Set
end
end
---------------------------------------------------------------
-- The Pendant's Axis switch changed... Reconfigure appropriate settings in Mach4 and turn the Pendant LED ON/OFF
--This will process the Pendant's Axis Selection Switch
---------------------------------------------------------------
function PendantAxisChange()
--Variable prep first for handles
local hAxis_X --Position X on Pendant Switch
local hAxis_Y --Position Y on Pendant Switch
local hAxis_Z --Position Z on Pendant Switch
--Variable prep for signal values, MAKE SURE YOU MATCH THE ONES IN HERE WITH THE ONES JUST ABOVE
local SelectAxis_X
local SelectAxis_Y
local SelectAxis_Z
hAxis_X, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT10) --If you are not using INPUT0 for the Axis Selection Switch X, change the INPUT#!!!!
SelectAxis_X, rc = mc.mcSignalGetState(hAxis_X)
hAxis_Y, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT11) --If you are not using INPUT1 for the Axis Selection Switch Y, change the INPUT#!!!!
SelectAxis_Y, rc = mc.mcSignalGetState(hAxis_Y)
hAxis_Z, rc = mc.mcSignalGetHandle(inst, mc.ISIG_INPUT12) --If you are not using INPUT2 for the Axis Selection Switch Z, change the INPUT#!!!!
SelectAxis_Z, rc = mc.mcSignalGetState(hAxis_Z)
--This is the Pendant's LED, and it will be ON when an axis is active on the Pendant's switch
local hLedForActivePendantAxis
hLedForActivePendantAxis, rc = mc.mcSignalGetHandle(inst, mc.OSIG_OUTPUT1)-- Pendant LED Port 3 Pin 1
--Now actual axis Selection Switch processing code
if (SelectAxis_X == 1) then
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, AxisNumber_X) --Map the MPG to control the X Axis
mc.mcCntlSetLastError(inst, "X Axis Selected") --Show a message in the Screen Set
mc.mcSignalSetState(hLedForActivePendantAxis, 1) --Turn the Pendant's LED ON to show an axis is active
elseif (SelectAxis_Y== 1) then
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, AxisNumber_Y) --Map the MPG to control the Y Axis
mc.mcCntlSetLastError(inst, "Y Axis Selected") --Show a message in the Screen Set
mc.mcSignalSetState(hLedForActivePendantAxis, 1) --Turn the Pendant's LED ON to show an axis is active
elseif (SelectAxis_Z== 1) then
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, AxisNumber_Z) --Map the MPG to control the Z Axis
mc.mcCntlSetLastError(inst, "Z Axis Selected") --Show a message in the Screen Set
mc.mcSignalSetState(hLedForActivePendantAxis, 1) --Turn the Pendant's LED ON to show an axis is active
else
--None of the Axis Switch inputs are active, so unmap the MPG from all axes (by assigning an invalid axis -1)
mc.mcMpgSetAxis(inst, MachMpgNumberForPendant, UnmapMPG ) --Unmap the MPG, so it won't control any axes
mc.mcCntlSetLastError(inst, "NO Pendant Axis Selected") --Show a message in the Screen Set
mc.mcSignalSetState(hLedForActivePendantAxis, 0) --Turn the Pendant's LED OFF to show no axis is active
end
end
--We will now call the three functions we made
--This is so the functions will be initalized to the current pendant values
--When the Screen is loaded by Mach4
PendantEStopChange()
PendantSpeedChange()
PendantAxisChange()
-
Hey,
So I have got it working. I am able to use the physical switches to select axis and jog rates. I intend on using a Siemens PLC with a HMI I have lying around and use the screen to have button to select the "x" axis "y" axis and "z" axis as well as "x1" "x10" and "x100". If I have enough spare inputs I will also add "Cycle Start" "Feed Hold" and more. The code above does work I just had a loose connection:)
Thanks for your help
Peter
-
Hello Peter.
It was good.
I also have something to tell you.
If you know the answer to my question, please let me know.
Are you sure?
-
Hi Toshio,
I am not sure I understand your question?
Peter
-
Thank you.
Do you know the "Calibration" tab in Probing?
In my case, it looks like this:
At the end, Mach4 will stop.
If you know the solution, please let me know.
There is a video. Please see.
Video: https://www.youtube.com/watch?v=9LvV6iC3zmY
Matters
-Click "Calibrate X Y Offset" in the "Calibration" tab of mach4.
・ Z Axis drops to "Z measurement positon: -0.2"
・ Displayed as No contact with probe
・ Mach4 stopped
-
Hi, I am not familiar with this issue. It could be because you are using the demo mode and if I remember it has some limitation or something. Are you able to see the property when its activated in the machine diagnostics page?
Peter
-
Hello.
＞ Are you able to see the property when its activated in the machine diagnostics page?
Excuse me.
I don't understand this meaning.
Please tell me in detail.
-
Hi Toshio,
if you have the probe setup correctly in the config page when its activated you should see it light up on the "diagnostics" tab. I have attached a screen shot. The LED light should turn on when the probe is activated.
Screenshot link : https://imgur.com/aqIOl6g
Peter
-
Yes.
That's okay.
In my case, the LED on the Probe lights up.
The problem is
The behavior of Probe is different from video.
Vdeo:
1, Calibrate XY Offseto Click
2, probe descent: video 3 minutes 52 seconds
https://www.youtube.com/watch?v=9LvV6iC3zmY
3, probe pause
4, probe Contact the work piece 4 times in front, back, left and right
In my case, the operation of No. 3 is strange.
The probe will stop, not pause.
In addition, I am testing Mach4 in the state of the photograph.
-
Hi,
I am really not sure what the issue is as I haven't seen this issue before. The only thing I could think of is either Mach 4 demo has some limitations or the setting have been setup incorrectly.
Peter
-
Look at my settings.
Is it the same as you?
-
Hi,
in the early days (6.5 years ago) I tried using a manual switch to simulate a probe but did not have good results.
I did reach a conclusion as to why that was the case, but is just a pet theory of my own, whether it makes sense to you,
and even more importantly whether it's correct.....
I was trying to simulate a probe before my machine was complete, that is to say not all of the axes were operable.
Once all axes were operable and I instituted a good probe circuit probing has worked fine for me ever since.
I use Autoleveller, a software utility that probes a printed circuit board blank to measure its deviation (small, typically less that 0.2mm)
from flat, and thence modify the Z axis ordinate of the Gcode to isolation route the PCB. I have used it for years and probing a PCB blank
in ten or even hundreds of locations is commonplace, and I do it daily. I would have expected if there is a fault with Mach4 probing I would have
found it over the six plus years I've been using it.
The probing routine that you are using is not a native Mach4 operation, but is in fact a macro consisting of dozens of instructions to enact the
whole routine. ALL probing relies on the g31 code. If you don't understand how the g31 code works and its limitations then it should
come as no surprise that any macro built up of g31 blocks will fail.
An excellent description of the exact sequence of events when a g31 block is executed is given in Mach4Hobby/Docs/Mach4API.chm, look under
'Plugin Development/Probing' headings.
The shortened version goes something like this (mm units):
g31 z-5 f200
is interpreted as a more common g1 move from the controlled points current x,y,z location to x,y,-5 at a speed of 200mm/min
UNTIL the motion controller detects a probe event. On receipt of a probe event the motion controller stops, reports an AllAxesStopped
and then reports its x,y,z location, ie the probe position. The remainder to the Z axis travel, that is to z=-5mm is aborted.
That your probing routine passes a number of probe events it suggests that your motion controller and Mach4 must be co-operating
to successfully complete g31 blocks.
In practice all g31 blocks must be followed with a retract move, for instance:
g31 z-5 f200
g0 z5
This combination of moves will probe in the negative z direction until the probe event is detected, and once the position is reported back to Mach
then it will retract (at raid traverse rate) to z=5mm.
Now as the Z axis retracts you would expect the probe circuit to go open circuit right? Lets imagine that for some reason, fault or otherwise,
that the probe circuit does not open circuit. What is Mach to do? It has detected a fault....and as it may be required to do another g31
block in short order, has it not detected a fault that would preclude it from being able to do so?
When I was simulating a probe wit a button I believe that when the retract move was executing my motion controller was monitoring the
probe circuit and if it did not open circuit in some respectable time it would fault.
This is the basis of my pet theory.......but I have no evidence for it other than when I was trying to simulate a probe with a button, while
it would work with the 'probe closing event' it would often fail at the 'probe opening event' ie that I was not fast enough on the button.
What I did find is that when I got my Z axis working properly and a good probe circuit that kind of fault never occurred again. I presumed
that because the probe would open circuit within micro seconds of the Z axis retract block being executed that my motion controller was
happy enough that the probe circuit is operable.
As I say this is my own theory....whether its correct or not is up to you to decide.
Craig
-
Hi craig.
Thank you for the long sentence.
I found "Motion plugin probing procedure."
I want to be able to understand.
I also didn't get good results when I tried to simulate "TOUCH" using a manual switch.
I've had success from time to time, so I got the point.
It was successful by pressing and holding the switch.
However,
I don't think this issue is due to a manual switch.
Because, if you look at the behavior of video.
https://www.youtube.com/watch?v=9LvV6iC3zmY
1, plobe descends.
2, plobe does not come into contact and stops temporarily at a certain position. (Video 3: 50 ~)
3, Next, it automatically contacts the front, back, left and right.
My situation
1, plobe descends.
2. It automatically descends to "Z measurement position" and mach4 stops. "ERROR: No contact with probe" is displayed.
In other words, I haven't turned on the manual switch, so I don't think the manual switch is the cause.
We would like to thank Mr. Craig for the MPG program.
I reduced the program for the X Y Z axis and attached an LED for the X Y Z axis so that I could see On Off.
-
Hi,
In other words, I haven't turned on the manual switch, so I don't think the manual switch is the cause.
I think you may have found the problem.
As I posted earlier:
g31 z-5 f200 gets interpreted as:
g1 z-5 f200, but would stop at a point where the probe makes contact, lets say z=-2.5mm. But what happens if the
probe DOES NOT make contact, then the machine will drive to z=-5mm WITHOUT a probe detection event and Mach will know
that the probe is faulty or for some other reason the surface was not detected and post a "ERROR: No contact with probe"
statement.
So the fault you are describing COULD be caused by a manual probe button NOT being activated (to simulate a natural probe event)
BEFORE Mach reaches it g31 endpoint.
Craig
-
Thank you, Craig.
＞ So the fault you are describing COULD be caused by a manual probe button NOT being activated (to simulate a natural probe event)
BEFORE Mach reaches it g31 endpoint.
that's right.
If the manual switch is turned on before the Probe reaches the "Z measurement position", the probe will contact the front, back, left and right four times each.
But I can't find a solution.
-
Hi,
if the controller does NOT detect a probe event BEFORE it gets to the g31 endpoint, its a fault.....end of story.
I'm not quite sure what you would expect.
Essentially what you are saying when you execute a g31 block like g31 z-5 f200 is 'advance to z=-5mm but expect to stop
before you get there', if you don't get the signal to stop, ie a probe event what do you want Mach to do? It did not detect the surface
it expected to find......thats a fault isn't it?
Craig
-
Looking at the video, the probe goes down and pauses at "Z measurement position",
Next, it looks like the probe is moving back and forth and left and right.
However, in my case, it is stopped at "Z measurement position".
I just don't know the cause. I am troubled.
If you know any solution, please let me know.
-
Isn't the cause that the real XY axis motor is connected to the BOB?
-
Hi,
you are using the Probing module, the fault could be in the code, or it could be your probe simulation set-up, or it could
be a machine fault.
Why don't you try writing some MDI code to test the g31 cycle, your machine and simulation procedure?
Once you have proven all those to your satisfaction THEN try running the module code. Note tat the Lua source code is
freely published for you to inspect, read, edit as you wish.
Mach4Hobby/Modules/mcProbing.mcs
Craig
-
I used MDI.
g31 z-5 f200
Then
ESS: failure! Probe0 never hit or the allowed distance was traveled. Swiiiitching from
It looks like this, is the motor tab setting wrong?
I attached a photo.
I set the motor with Stepping Motor Cont Per uint400 pulse / rev.
-
excuse me.
Below is the History.
ESS: failure! Probe0 never hit or the allowed distance was traveled.
Switching from probing to normal state.
-
Hi,
No, the problem is that the probe event is not happening before the g31 block hits its end point.
There is (probably) no fault of the motor, no fault (probably) of the mcProbing module code, it's operator error,
you are not activating the probe button before the g31 finishes.
As an experiment try:
g31 z-5 f10
If the probe starts a z=0 it will take 30 seconds before the Z axis descends to z=-5mm and should give you plenty of time to hit the button
before the window of opportunity finishes.
Craig
-
The result was the same.
I haven't touched the probe manual switch.
Just press the Start button.
It took about 30 seconds to press the Start button and reach 0 to 5 mm.
-
Hi,
I haven't touched the probe manual switch.
THATS WHY IT FAILING....you have to operate the probe switch before it reaches the end.
Craig
-
＞ THATS WHY IT FAILING .... you have to operate the probe switch before it reaches the end.
So does the probe move back and forth and left and right after it descends and touches the bottom of the gauge?
When I watch the video, it looks like the probe is descending and the probe is moving back and forth and left and right without touching anything.
https://www.youtube.com/watch?v=9LvV6iC3zmY
Around 3:50.
-
Hi,
will you just try to operate the manual switch BEFORE the g31 endpoint. The error message you are getting is BECAUSE
Mach is not detecting a probe event.
Craig
-
Hi,
you should not be running the probing routines....you can't get a regular g31 block to execute let alone the probing routine.
Execute MDI g31 moves only. Once you have got that mastered then move on but not before.
Jog to 0,0,0 then MDI g31 z-50 f10 and make sure to manually open the probe circuit before the move terminates.
Craig
-
understand.
I watched the video and learned about the function of Calibrate XY Offset.
However, it seems that he understood it by mistake.
Thank you for teaching me various things.
Now you can buy Mach4 with confidence.
Thank you for staying with us until the end.
-
Hi,
kool, starting to make some progress.
A probe, a good one, should go open circuit if it touches and deflects in the Z axis AND/OR the X and Y axes as well.
As you now understand Mach is looking for, and will error out if it does not get, a probe event BEFORE the terminal
of the g31 move.
When I probe circuit boards I zero the Z axis on the top surface of the PCB. Thereafter the probing routine will move to a series of
preplanned x,y locations and probe in the Z axis. The moves are:
g31 z-2 f200
g0 z2
g0 x...y...
g31 z-2 f200
g0 z2
g0 x...y... etc.
So the machine moves to a probe location, then probes and expects, not only expects, but requires a probe event before the Z axis descends to
z=-2. It will stop, record the probe coordinates, retract to z=2 then rapid traverse to the next probe location.
Thus it would make no difference if I used this:
g31 z-20 f200
g0 z2
g0 x...y...
g31 z-20 f200
It would just mean that the machine will drive downwards until the probe event, lets say z=-0.054mm....but if the probe circuit were faulty it will carry on
and drive my probe tip to -20mm and totally wreck it. So there is distinct value in specifying a terminal g31 position so that a crash is not too catastrophic
should Mach/controller miss the probe event. On te other hand if I speciified:
g31 z-0.5 f200
g0 z2 etc
and at this particular location the top surface of the PCB is at -0.65mm then my probe would never detect the surface and throw an error such as you
have already seen.
A thorough understanding of how g31 works will help immensely when you go to write your own probing routines or try to diagnose faulty routines.
Craig
-
This probe thing has me stumped as well. I think what Toshio.K is experiencing is something similar if not the same as me. I have a DIY probe connected to the machine set to open circuit upon probe touch.
While trying to run a probe calibration on x & y the probe descends in z direction then pauses at the predefined z probe height like it's ready to move/probe in the x or y direction but instead of moving it throws up the error
ESS: Failure! Probe0 never hit or the allowed distance was traveled. Switching from PROBING to NORMAL state.
ERROR: No contact with probe
My probe works fine if I use the touch button screen and perform single edge probes but if I try to use the multi axis x&y probe routines I get the same error.
-
Mr.gyrojeremy.
Hello.
In your case, what's happening on a real milling machine?
-
Just as I described above
-
Hi,
the error is exactly as I have described previously, that is that the g31 move is reaching its terminal WITHOUT having encountered
a probe event.
The routine you are using has multiple g31 probe blocks, at least one of those blocks is misconfigured such the the g31 block
terminates before the probe encounters the surface it was supposed to detect. You need to open the Lua code file and trace it until
you find how or why the g31 is misconfigured.
You could start by causing each g31 block to issue either a wx.Message block or a status bar message, that would at least tell you which of
the g31 blocks is misconfigured. You might also try compiling a log file, it too should assist in determining where in the Lua file
the faulting g31 is located.
Craig
-
Could you tell me where the g31 lua code is located. Shouldn't it be configured from standard? I don't think I've messed with that?
Or is that a macro I need to install?
-
Hi,
g31 is a native Gcode, and is most unlikely to be faulty, from your description and Toshio.K's at least some of the g31 code block have executed
successfully, ergo the g31 code is being correctly interpreted by the Machs interpreter and executing in conjunction with your motion controller.
The probing routine you are using is a part of the mcProbing module:
Mach4Hobby/Modules/mcProbing.mcs
Craig
-
Brilliant!! Thanks Craig. I'll try to make sense of that and see what I can do.
-
mr. gyrojeremy.
Hello.
If the current obstacle is resolved, please let me know how to solve it.
Thanking you in advance.
-
Just having a look and it seems the issue is that it is doing a g31 for the Z movement to the measure height and just probe erroring when it reaches that height and hasnt touched off anything
-
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G%.1f Z%.4f F%.1f", ProbeCode, ZMeasPos, FastFeed))
mm.ReturnCode(rc)
rc = Probing.CheckProbe(1, ProbeCode); if not rc then; do return end; end
if you replace the two instances of the above code in the mcProbing.lua with :
rc = mc.mcCntlGcodeExecuteWait(inst, string.format("G0 Z%.4f F%.1f", ZMeasPos, SlowFeed))
mm.ReturnCode(rc)
double check before full use as I'm no lua expert but it seemed to work for me
-
Mr.nc42.
Hello.
Please look at the photo.
Apparently it was successful.
Thank you.
Thank you.
I was worried because I don't understand the Lua language.
This solved it.