Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: moorea21 on April 19, 2015, 03:07:27 PM
-
In a previous thread I started (Problems with For Next loop in script), BR549 kindly gave me this script to run in macropump:-
IF Isactive(input1) Then
DoOemButton(1001)
While Ismoving()
Wend
DoOemButton(1003)
Else
End IF
END
According to my logbook, it worked. Next day, the PC died, and has now been replaced. But now macropump code of any sort doesn't work. I then tested the above code in the vb script window; as predicted, it locked up the processor. I tested this code instead (by pressing input 1 switch to make it active; checked in diagnostics screen):-
IF Isactive(input1) Then
Code "G00 X200"
End IF
END
No joy in macropump, but works from VB code window. All this despite 'run macropump' being enabled in general config.
macropump file is called 'macropump.m1s', my xml is attached in case that helps anyone.
Anyone know why macropump code is not being run?
Thanks, R
-
Did you turn ON the macropump??
(;-) TP
-
Erm...
I enabled it in general config, I don't remember there being any more to it than that. Nothing in the manual.
?
-
yep that turns it on, I would double chcek the setting.
DID you place the macropump in the proper directory ?
(;-) TP
-
I triple triple checked... and it's in the right directory. Mystified
-
Then there is no reason for it not to run (;-)
What directory did you place the macropump in?
Have you restarted Mach3 ?
HOW do you know it is not working?
(;-) TP
-
Now it does work, so it must have been pilot error of some sort, although I feel sure I'm not doing anything differently today.
I have made a point of closing and reopening mach after each change to macropump file, but then I'm sure I did that yesterday as well. Maybe not...
Using the MDI line to provide a testable axis movement, it stops the axis (not very abruptly, but well enough for this application,) and gives me a status line that says 'MDI line paused.. hit CycleStart to continue'. As I don't want it to continue with the paused move, but instead go to the next line of code, I was thinking of adding 'DoOEMButton(1021)' twice after the 'Else' statement.
This seems a clumsy way to achieve this, is there a more 'normal' way to get it to execute the next line after stopping the axis's movement?
-
Mach3s Gcode was never intended to be stopped and started as such. Being it is a buffered system it is a fudge to restart without position loss. So to do it smoothly, Well ? it is not going to happen. It is what it is.
(;-) TP
-
Okay, a fudge will do in this instance. But 'DoOEMButon (1021)' twice before 'else' for some reason doesn't work; I get the same status line telling me to press cyclestart. Why might that be?
Also, the script sometimes takes too long to respond, even though it's always activated in the same circumstances while only 1 axis is moving (same one each time.)
I know nothing about 'Brains' yet, but would that be a way to make sure the script runs more promptly?
Thanks
-
Post your code so I can see what you are trying to do.
(;-) TP
-
This is representative of the kind of code; not much to see. The Z drive needs to withdraw until it trips a switch that currently activates input#1. When that happens, I want the Z drive to stop moving, and the next line of code to execute; the one that names the resultant z position as 0. Z works like a syringe driver; it withdraws fully (-40000 is a 'fake' position guaranteed to make the axis go far enough to trip input#1 switch regardless of where it starts from,) and moves to X151 to pick up a tube of paint.
( 4.nc 11/04/2014 18:06:54)
G21
G90
G64
G00 A0.2 F2500
( TOOL CHANGE : 4 )
M06 T4
G00 Z-40000
G92 Z0
G00 X151...
G00 X0 Y0
M06 T1
M30
It only does this at the beginning and end of each file, when it picks up/drops off a new tube of paint to paint with. There is some flexibility built into the physical structure of this axis; if it overruns a bit, no harm, but currently it overruns by about 5-6mm sometimes, which is pushing it.
-
Having just spoken to the manufacturer of my drivers, I may be able to simply use a 'normally closed' switch in series with the lead that runs from the breakout board to the driver, which when tripped by the z axis movement will switch off the step signal to the Z drive, causing the motor to stop. May try this before investigating software solutions, will post something soon.
-
AH OK . You need to rethink your Gcode approach. Simply have the Z refhome to the switch (G28.1 Z0.000) . It will raise until it hits the switch THEN reset the Z to Zero as you do in the Gcode ( G92 Z0.000).
That way you have full control of Z all the time. We use the same approach with Plasma machines only we are looking for the top of the material.
IF it were ME I would do it in a Macro (Zrefhome) that way you could still use run from here if needed. Otherwise in straight Gcode Run from here will not work with a G28.1 call in the code.
(;-) TP
-
Ah, I forgot to say, my Z needs to home in the opposite direction. I hadn't thought to include this information, sorry. The whole reason for this is to keep my Z homing in the positive direction, while this other homing like behaviour goes in the opposite direction. Mach doesn't allow 2 homing directions for the same axis...
Cutting the step signal to the driver works, but when I send the step signal through the 18feet of wire it takes to go from the BOB through the (previously input#1) switch to the driver, the step signal is too weak to trigger any behaviour in the driver it seems. Very annoying that is, as it worked brilliantly with just 4ft of wire. I suppose I could rig something up with an external supply and a relay, but I'd rather not.
So, will putting something like the original script into 'brains' give me a quicker response than using macropump? If it could , problem (maybe) solved.
-
Brains seems to only allow me to have one button push as an end result. Not helpful, as I want to
1001 'feedhold
252 'switch off Z axis
1021 'reset
1021 'reset again
252 'switch z axis back on again
Can an OEM trigger make this run in macro form when the switch (currently input#1) activates?
It seems like it ought to in principle, but heres nothing in the manual for making oem triggers start a macro. Can anyone guide me to that information?
-
try to read something about G31
-
I have, but it seemed to do the same as G28.1, unless I did something wrong.
-
Is it possible to use G31 in the opposite direction to the homing direction for an axis? I thought it wasn't, but the manual makes no mention of that, so I'm not sure what led me to that conclusion.
-
G31 gives you only a exact Information where the Input was hit (Basic idea of probing).
post your code how you tried to use it.
Thomas
-
I would if I could! It was probably at least 6 months ago, and would have been on the old pc that died. I'll try configuring my switch as 'probe' tomorrow, and try a G31 command to see if it works. The description in the manual sounds like the sort of behaviour that I need it to have. Thanks for the suggestion.
-
YEP Use G31 in a macro. Just point it in the correct direction It will run until it hits the switch then reset the Z with G92 X0.
Code"G31 X10 F20" ' it will move in the X positive direction at 20ipm until it either hits the switch or reaches X10.
Code"G92 X0.000" ' Sets the offset to 0.000
(;-) TP
-
With probe set to port1 pin 12 (the switch), and Z set at 25000, I used G31 from mdi line to test, got 'probe ignored...', changed probe to active low, tried g31 z0, no movement on axis, no status line report. G00 etc etc all work fine. What's it doing now?
-
I've read through this thread and your previous one and I could explain to you why the various macro code you've tried does not do what you might want it to do but I'm not sure its really relevant.
Can you explain what it is you're actually wanting to do rather than how your trying to do it? i.e. I think you've fallen into the classic XY Problem. See http://xyproblem.info for what I mean.
-
What I'm trying to do is get the Z axis (syringe driver) to withdraw completely, to the point where it trips a switch telling the axis to stop moving, in order to ensure that has sufficient clearance to go and pick up the next 'syringe' of paint.
When it has done this, the Z drive moves down until it contacts the back of the 'syringe' plunger, then stops moving.
Currently this last operation is achieved using homing. I was hoping to achieve the 'withdrawal' stage using G31, a macro, a hack, whatever, in veiw of the fact that homing the same axis in 2 directions is not allowed in Mach.
-
It turns out that g31 is working ok, just incredibly slowly. I've increased feedrate accordingly, problem solved. Thanks All!
-
Good you got it working. However please in future think about the XY problem - it's an excruciatingly common problem on forums.
If you'd asked "how do I move Z until a switch is closed" or something similar I guarantee you Terry or someone else would have given you the G31 solution in 1 reply.
By posting "Problems with For Next loop in script" and then "mach ignoring macropump code" it's taken 30 posts to get you to your solution.
-
Okay, point taken. I'll think through my title posts a bit more clearly next time too.