Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Dan13 on December 20, 2014, 05:28:29 AM
-
I have a simple probing routine. Something like this (but actually written in VB macro):
O0200
G91
G31 Z-10 F500
G01 Y0.2
M99
Repeated 200 times or so. However, every know and then a movement in X starts on its own (no where in the code is it commanded at all). Or the Y axis takes off at some crazy speed that the drive can't keep up. It will work fine 5-10 times, and then do that quirk.
Used version .062 and then reverted to .057 which seems to have less quirks, but still has them. It is in Mach3Turn if it makes a change.
Thanks,
Dan
-
Is it all done in VB, or is there a mix of g-code and VB? From what I've read, if you mix g-code and VB, there will be problems in all versions of Mach3.
-
Hi Gerry,
I will be more specific. I have made sort of a wizard where I enter values in user DROs (like feed, Zstart, Zend) which which a VB macro then reads and does the probing. Don't have the macro on this computer, but it looks something like this:
M40
While GetDRO(2) > Zend
Code "G91 G31 Z-10 F" & "Feed"
Code "G00 Z1"
Code "G01 Y0.2"
Wend
M41
G90
msgBox "Probing Completed Successfully"
Think there is a problem using Gcode inside the macro like I do?
Thanks,
Dan
-
Terry is the one you need top ask (BR549)
-
Yep... he must know this better... will wait for him...
Dan
-
OH MY (;-). You have run into the LOST MACH syndrome . It is where SOMETHING in the XML is corrupt and it make MAch3 do strange things at times.
My suggestion is to backup all your special stuff then wipe out mach3 completely and start over from scratch.
DO you have an original XML that you saved at the beginning of your adventure ??? NO the saved XMLs from mach won't do as you do not know at what point it started going bad.
ALSO make sure you delete all of the backup xmls (wipe out the directory).
NOW from scratch recreate mach3 AND THEN when everyting is working SAVE a copy of the XML to a safe place OUTSIDE of the mach3 directory. THat way IF it starts again just copy the OLD XML over the NEW XML and off you go again. I had a BATCH file I ran from the DOS prompt that did the whole show in a wink.
That Helps to stabalise Mah3 when you are working in macros and mixed Gcode. Can'rt say why and ART could never find what it was that triggered it.
NOW down to your Probing macro. It will cause problem when you try a While loop with mixed Gcode. The CB and Gcode are runing in seperate threads and get messed up Faster PC have more problems with this than slow PCs ALSO single cores seem better than multi cores . SOMEWHERE someone got the multi threading UNSTABLE.
NOW that is for MachMILL who knows what works in MachTURN.
So what exactly are you trying to do ? Your code is a bit confusing without seeing the whole picture. I assume that you are doing a probing routine in TURN.
(;-) TP
-
NOW as to the actual probing routine it would BEST be done as a SUB routine using #vars. You can USE a Mcode(macro) to program the routine using the #vars.
This Routine is STONE COLD reliable in its use. You just have to program what you want instead of using a WHILE LOOP like in a MACRO.
NOW for the record MACH4 should be as reliable in the fact that you can use conditional Gcode . I have not been able to TEST mach4 Conditional yet but in "THEORY" it should be dependable. It works well in Fanucese and Haasese (;-)
IF you need more help holler, (;-) TP
(;-) TP
-
Hi Terry,
Thanks for your reply. I did as you suggested - deleting MAch3 directory and starting from scratch. Didn't have a backup for the XML so took me a few minutes to take screen shots of all the settings and have them set back again. Now have the XML saved separately. Haven't yet tried to probe and see how this affected the buggy behaviour.
Now about the application. It is for probing a feed screw with an alternating lead. Y axis is the rotation axis. Z is the longitudinal axis. I have User DROs on the screen for setting feedrate, Zstart, Zend, Probing lengths limit, and probing resolution (how many probing points per single revolution of Y). I could have used pure Gcode with a sub and Vars, without using VB at all. However, I have to have a way to determine where to stop probing. I can't use a sub as I don't know the number of reps (the lead is not constant). This is why I am using While loop.
Oh.. and I am using an Ethernet SmoothStepper for the controller.
Do you think you have a better way of doing what I am trying to do?
Thanks,
Dan
-
OK when using a SS the SS is what will control probing IT IS a different ballgame.
" probing a feed screw with an alternating lead "
To use a sub just calculate the distance and divide the pitch for the number of total turns then add a couple for good measure. I am still not real clear on what you are doing. Are you trying to map the screw ????
(;-) TP
-
Yes, Terry. I am mapping the screw. It is a feed screw like those used in injection moulding extruders. The lead is not constant - can start from 50mm per turn and then gradually increase to 80mm per turn, then back to 70mm and 60mm. So calculating number of turns isn't going to help much.
Dan
-
Well you KNOW how long it is correct ? Otherwise you will never be able to fill OUT the DROs for Yend. It will NOT hurt to trim the data if you overrun the length while probing. OR if you parse the screw data you can trim it to length there.
IF you are doing an index of the screw then probe it will still catch all the data for the total length of the screw reguardless of the pitch variations you just have to plan for it in the sub program.
Just a thought, (;-) TP
-
ARE you trying to do this as a TURN application or a MILL application ?? Are you probing the screw itself OR probing the table motion ?? Are you probing the top edge of the screww OR the side of the flank ?
It all depends, (;-) TP
-
Hi Terry,
Again the screw is the workpiece. It is mounted between centres on a lathe and the probing is of the side of the flank.
Dan