Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: swolf-sm on October 23, 2016, 05:38:31 AM
-
Hallo everyone,
I try to get probing working in mach4.2.0.2914 (screen wx4.set) with basic success.
But after each "Probing->Single Surface->Measure X" for example the "Go To Work Zero" at "Program Run" does not work any more.
The reason for this is that the values of the registers #4001 and #4002 are divided by 10 witch each call to
CurAbsMode = mc.mcCntlGetPoundVar(inst, 4003) and mc.mcCntlSetPoundVar(inst, 4003, CurAbsMode).
Is this a bug or a feature ?
Build 3208 has the same behavior at this point.
Additionally in build 3208 the probing failed because the new calculated offsets are not correctly stored in the #vars.
Apparently the meaning of var #4014 has changed and function Probing.SetFixOffset in mcProbing.lua should be adapted.
Can somebody confirm this?
Thanks, Steve
-
They #Vars were changed sometime back. The probing module has been updated but I'm not sure if you have the updated version. Not sure what builds it was included in if any. There was also an issue with the #Vars used to set distance modes. I know that is being looked at but not sure if it has been fixed yet or not. Will let you know when I find out.
-
Thank you, Chaoticone, these informations are most welcome.
Of course I can fix the lua script, but relating to #4001 and #4003, in my opinion a save and restore of a variable shall not change the value of that variable. In this case I presume the bug is located in the mach kernel itself. So "mc.mcCntlSetPoundVar(inst, 4003, CurAbsMode *10)" would fix the symptom and solves my problem with the build I use, but doesn't fix the bug itself.
Var #4014 is a different kettle of fish. With an active G54 #4014 in build 2914 is "1" and in build 3208 #4014 is equal to "54". So it looks like a different interpretation of the value. If this change is permanent the lua script has to be adapted. For this it is very usefully to know something about the meaning of the #vars. Do you, or someone else, know whether and where the #vars are documented?
Steve
-
Sorry, there is a typo, the following is correct: With an active G54 #4014 in build 2914 is "0.1" ...
-
I have a fix for you I think. These updates will be in the next release. You have three files in the zip you need to replace some existing files with. They are in the folders they need to be placed in respectively.
-
Thank you very much! I will test it next weekend.
Steve
-
No problem, let me know how it goes.
-
Hallo Chaoticone,
it goes very well. The save/restore issue is solved and the function Probing.SetFixOffset in mcProbing.lua now works as expected, thank you.
I did some minor fixes in mcProbing.lua so now probing in all available variations operate excellently as long as G69 (no rotation) is active.
With G68 (workpiece coordinate system will be rotated) a new issue surfaces. The calculation of retract and back move destinations fail.
This is being caused by the fact, that in equations like "RetractPoint = ProbePoint - BackOff" (line 608 in mcProbing.lua), for example, RetractPoint and
ProbePoint belong to different coordinate systems. ProbePoint references the rotated coordinates i.e. the real position of the probe relative to the workpiece origin, and
RetractPoint which is used as the destination in G1/G31 will be rotated again.
I started to resolve this problem in conjunction with the retract moves by replacing the absolute moves by relative (G91G1..) ones,
so probing works now even with very small rotation angles.
For the back moves to the starting positions the solution is not as easy.
That moves still may fail when the rotation angle of G68 is bigger and the probing is not done near the rotation center.
For this I need some more time (or should be done by the developers) and a documention of the #vars would be very helpful.
Steve
-
Ups,...
of course I want attach the changed file, here it is ...
-
Thanks Steve,
I will check out your edits. I did not develop the probing module but I think it could (and probably should) be restructured.
I did develop the TouchOff module. Have you used it? If not, give it a go. We have to determine where our effort will be spent. Right now the plan (over time) is to remove the probing tab in the default screens and for the TouchOff module to become the defacto default used by those with probes and/or touch plates. My hopes for structuring it the way I did was that it would be relatively easy for users to customize to their liking but the vast majority of users should never have to. I think it does everything the probing screens do except a rapid find (double touch) and probe calibration. Both of which I may add at some point if I get time to.
-
Hi
Sorry to but in
If you do do the swap please bear in mind that a touch plate is different to a probe , so the setting page needs spliting
I normaly have touch (tool setter ) on g31 but the probe is on g31.1
One being NO and the other NC
;) when Warp9 get the g31.x sorted
-
This is why you have options to use probe, probe 1, probe 2, etc. which use the appropriate G31, G31.1, etc. respectively. Even the touch indicator LED will respect this. Wire one up NC and the other NO..... makes no difference to the TouchOff module. Just set your options. The options are already there and will not be split into another screen. That would just over complicate things. With Mach4 you can have your cake and eat it too. :)
-
Oops my bad
Should take more notice when I use the mill
Stuart
-
Hallo Chaoticone,
you are right, I have not used the TouchOff module yet, for any reason I was focused on the probe module.
But I will have a closer look at touching, I only not know when; maybe at the weekend.
Steve
-
Hello Chaoticone,
I've tried to get the TouchOff module working but I'm not sure if have used it correctly.
What I did:
- edited the screen set wx4.set, at the "Offsets" page I changed the
clicked script for the "Set Z" button ("--Set Z button") in the way you can see in the attached file SetZButton.txt
- Added the following settings to machine.ini:
[ToffParams]
ToffProbeRate=100
ToffRetractDistance=2
ToffPrepDistance=15
ToffToolDiam=10
because I need it in the units of millimeters.
To get the function TouchOffZNeg0() in mcTouchOff.lua called from the screen set it needs to be prefixed with "mcTouchOff."
So I got the first move of my probe, but the fixture offsets weren't set.
To find the reason for that I reached the function Code(Gcode, ProbeActive) which I do not understand completely.
I'm sure it should execute "Gcode" and wait until movement is finished.
But what is the purpose of
if (ProbeActive ~= true) then
ProbeActive = false;
end
and how is the probe state after the movement (did the probe touch the workpiece?) returned?
At this point I stopped my activities full of self-doubts. When I did all right, when a lot of fixes are necessary to get the TouchOff module running.
Sure, this module is much better structed than the probing mod, and is definitely easier to maintain, but at the moment the probing module does the most things I need.
Steve
-
Hello Steve,
You should not have to edit anything to use the touchoff module. It has its own dialog and not linked to or used in or by anything on the probing screens. Clicking the touch button opens the TouchOff UI.
-
Ah..., this explains a lot. Surprisingly once I've done it right it works. Great work.
I quickly added the rapid find (double touch) by inserting two lines in the function TouchOff:
Code(string.format('G91 G' .. ToffProbeCode .. ' ' .. Axis .. ' ' .. PrepDistance .. 'F' .. ToffPrepRate), true)
TouchRetract(Axis, Direction * -1)
Code(string.format('G91 G' .. ToffProbeCode .. ' ' .. Axis .. ' ' .. PrepDistance .. 'F' .. ToffProbeRate), true)
A calibration in my opinion is not necessary. The only thing that you have to know is the diameter of the probe, that can easily be measured with a slide gauge.
In the future I would prefer having the TouchOff UI dialog integrated in the main screen.
Thanks, Steve
-
Good deal, Thanks!
The main reason I have not added the rapid touch is it was designed and many will use it with a tool as a probe and a touch plate to complete the circuit. A probe is forgiving and made to over run and bounce back to center. That is not true at all with a carbide end mill. I point this out so others don't see your reply and implement the change on theirs without thinking about it. But I am very pleased you could and did edit it slightly to suite your needs. :) Can't tell you how hard I tried to make that the case. Just remember if you update it will be overwritten unless you save it as something unique and then will have to edit all the bits that load and bring it to the top. I would save a copy somewhere outside the Mach4 directory for safe keeping.
I have done very little with lua panels in screens but I think you could use it in one without much editing. There are no plans to ever have it as part of the default screens.
-
Today I encountered the problem "#4003 assigment value gets divided by 10" too (Mach4 v4310), so here's a quick workaround:
#500 = #4003
G#500