Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Davek0974 on January 09, 2016, 04:36:38 PM
-
If I have my axes at say X100 and Y100 and in g-code I want to temporarily move to say curretntX+50 currentY+50 , do something then move back to where i was before, how would I code it??
Do i need to be looking at the DRO's etc as variables and adding/subtracting my move ?? or is there a sensible way??
Anyone care to throw an example my way??
:)
-
http://machmotion.com/cnc-info/g-code.html
you can give this a shot
G91 (change to incremental distance mode)
G0 X50 Y50 (move from current position X+50, and Y+50)
>>>> do something
G0 X-50 Y-50 (move from current position back to the original position)
G90 (change it back to absolute distance mode)
-
Great, thanks,
I wasn't grasping the Incremental/Absolute switch
Should work nicely.
-
Its working nicely thanks, here's the final subroutine code, If there is any surplus code in there please let me know, I have hopefully commented it correctly...
BTW the idea is to use an offset probe as height sensor.
G91 (switch to incremental mode)
G01 X28.00 Y4.00 F6000 (position probe switch)
G04 P0 (wait until the move finishes)
G90 (switch to absolute mode)
#15239=1 (this var is monitored by a brain and triggers the probe cylinder)
G04 P0
G28.1 Z5.000 (probe the surface)
G92 Z0.000 (zero the Z axis DRO)
#15239=0 (raise the probe)
G00 Z#15045 (apply the probe switch offset from settings screen DRO)
G92 Z0.000 (zero the Z axis)
G00 Z5.00 (raise the Z axis for travel)
G91 (switch to incremental mode)
G01 X-28.00 Y-4.00 F6000 (put the axes back to where we came from)
G90 (switch to absolute mode)
M99
%
I'm using G01 moves as the G0 move was a bit vicious.
Queries....
1 - If i remove line 3, it makes the Z motor screech for some reason???
2 - It does not put the axes back where they came from. It varies but is always out by about 0.05mm to 0.15mm every time??
3 - When I press my "set origin" button it makes the Z axis change, this is not wanted, any idea how i fix that??
The button code is...
DoOemButton(1008)
DoOemButton(1009)
DoOemButton(242)
DoOemButton(160)
Many thanks
-
The G04 P0 is not needed . All you are doing at that point is emptying the buffer.
Define G0 as being vicious. Either the machine can do a G0 move or it cannot Which is it ???
The reason Z is screeching is it is loosing steps Find out why.
IF the Machine cannot return exactly from where it came from then it is either loosing steps or the Step resolution is course enough to not allow the last step to move precisely and you come up a fraction of a step move short. TO be made up on the next move.
There is nothing in the button code that should effect Z. What it does is
ZeroX
ZeroY
Regen toolpath
Save Corrds to G59.254
-
Hmm,
Without that G04 the Z emits a very short screech, but at a point when the Z should not be moving at all - right at the beginning? I could maybe video this as it is repeatable.
G0 over a sort distance just seemed unnecessarily hard, time saved is nil, so why beat the machine up doing a short pair of rapids when a smooth co-ordinated move is better :)
Can't be losing steps - this is a DRO issue only, not physical, I have not got as far in testing yet to prove lost physical steps, just that the DRO does not always return to zero which seemed odd as that was where it came from :) But if as you say it is made up then no worries at all, even if its not 0.1mm is bugger all in the real world, metal expansion is probably a bigger issue :)
The button changing Z is worrying as Z definitely changes, again, I could video this action.
-
Violent implies acceleration is too high as it should accelerate smoothly and quickly up to maximum velocity and back down, over a short distance it should never reach maximum velocity.
Suggestions... Half whatever the present acceleration is and rerun the code with g0 and without the pause, what does it run like (quick check and as your experimenting).
What acceleration and velocity do you have for each axis out of curiosity, plus steps per mm (or inch).
-
Will have a look tonight but this is purely a personal thing i think, i have the accelerations as high as possible as its a plasma table.
-
Slightly more compact subroutine...
G91 (switch to incremental mode)
G01 X28.00 Y4.00 F6000 (position probe switch)
G04 P0 (wait until the move finishes)
G90 (switch to absolute mode)
#15239=1 (this var is monitored by a brain and triggers the probe cylinder)
G04 P0
G28.1 Z5.000 (probe the surface)
G92 Z#15045 (apply the torch height offset from settings screen DRO (currently switch offset))
#15239=0 (raise the probe)
G91 (switch to incremental mode)
G01 X-28.00 Y-4.00 F6000 (put the axes back to where we came from)
G90 (switch to absolute mode)
M99
%
cuts out two z moves and three lines of code, should work ok :)
-
Do you need the double incremental and absolute change?
May not require it. As the DRO numbers dont change.
With g28.1 why are you setting the DRO with g92?
Curiosity not expert here.
As it will input the numbers shown on the config homing page (do a screenshot tonight, but from memory its the bottom lhd boxes)
You should not need the first g4, and the second g4 probably required more than p0... Like p1
Again I'm new at this and no expert but always learning
-
Here's how i see it working, this version is untested yet.
G28.1 finds the surface
I know that at the point the probe switch trips, there is a fixed gap between my torch and the metal of whatever I set in the offset box so lets just tell the DRO what the gap is i.e. it's current position, no need to be zeroing and going up and down, just tell it where it is.
The double inc/abs changes are because i have no idea what will happen if i probe when in incremental mode as i only ever run in abs mode, may work, may not.
I figured if it does no harm then just switch back and forth.
The G04's are dubious, without the first one it makes my Z motor screech for some unknown reason, maybe trying to move the Z at the current rapid speed which it cannot do??? Is there a "F" parameter for the probing, maybe throwing in a F1000 would cure it?
-
the g28.1 home co-ords are set by the lower highlighted box on the left hand side and the approach speed is done by the boxes on the right hand size main table.
Go >>> config (top line) >>> Homing & Limits
-
Thanks but,
The speed I can see and understand but what effect / purpose does "G28 Home Location Coordinates" have or do ??
-
Found it, not applicable as its a plasma and Z home is always referenced to the top of the metal at the point of cut not a fixed homing location.
-
You are using G28.1
G28 is slightly different.
G28 I believe goes back to the home position (which are the home offset co-ordinates you enter into the boxes)
G28.1 goes in the direction of the home position and and zero's the axis. (zero is not quite right as it inputs the offset once tripping the home switch ... but you get the idea).
So... G28 just goes there, (slows down at the "slow zone" and moves at the jog speed) ...
G28.1 finds the home position using the home switches (at the jog speed).
Official definition here:
G28 & G30 Return to Home
A home position is defined (by parameters 5161-5166). The parameter values are in terms of the absolute coordinate system, but are in unspecified length units.
To return to home position by way of the programmed position, program
G28 X~ Y~ Z~ A~ B~ C~ (or use G30). All axis words are optional. The path is made by a traverse move from the current position to the programmed position, followed by a traverse move to the home position. If no axis words are programmed, the intermediate point is the current point, so only one move is made.
G28.1 Reference Axis
Program G28.1 X~ Y~ Z~ A~ B~ C~ to reference the given axes. The axes will move at the current feed rate towards the home switch(es), as defined by the Configuration. When the absolute machine coordinate reaches the value given by an axis word then the feed rate is set to that defined by Configure>Config Referencing. Provided the current absolute position is approximately correct, then this will give a soft stop onto the reference switch(es).
-
This might be the clue for the Z motor screech...
"The axes will move at the current feed rate towards the home switch(es)"
My current F rates are way higher than the Z can handle, maybe i should pull the G04 P0 out and put an F1000 in there??
Z is limited to 1300mm/min max
-
The problem with plasma cutters and torch height control, is the THCUP and THCDN commands shunt the z up and down at the maximum z axis velocity * THC Correction Speed (%) [DRO25]
The best (neatest) button / LED / DRO guide or table I found is this one:
https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiY3Of29aHKAhVH7w4KHQhpCIUQFggdMAA&url=https%3A%2F%2Fwww.machsupport.com%2Fforum%2Findex.php%3Faction%3Ddlattach%3Btopic%3D19482.0%3Battach%3D27839&usg=AFQjCNGJn1E7RpKyfyjY7STvwaxPFsA6ng
(hope the link works).
-
Thanks for the link, got that one :)
Yes the THC is a bit aggressive but needs to be really. In my case though the screech was when doing a G28.1 so could well be just the wrong the feed rate somewhere and flushing the buffer with the G04 P0 cures it?
I will try F1000 and no G04 see what happens
-
Robert you are missing teh point with plasma on accelleration and the speed of teh Z. With a plasma mcahine that cuts in the range of 200 IPM you MUST set the axis acceleration values as high as possible to help prevent rounding of teh corners. Cutting at low speed 20-30ipm it is not a probl;em but at 200+ is is a big problem.
The Z HAS to use a slap and go method because with an acceleration curve the event would be over before teh Z could move far enough faste enough to envoke a change. The process would lag way behind the events.
The is NOTHING wrong with it and is only limited by what speed can be used without loss of steps OR you run it fast enough to create an overrun in each direction which causes a sewing machine effect in teh Z axis. THAT would depend on how fast teh THC can react to make corrections.
NOW as to the Z homing speed there is no way to run the Z faster than the Axis parameter values using the G28.1 Ref Home. The machine will only run as fast as the max vel and acceleration will let it in both G0 and G1. You can set G1 as fast as you like BUT it will not use over the Max setting for G0.
G28.1 can play a dual roll. It simply sends the machine back to the switches, trips it then backs off the switch and CAN set an offset position or simply leave it at Zero. OR simply use a predefined position. The G30 will always send it back to the switch position. Those 2 processes are backwards to a normal Fanuc based CNC where G30 would be the variable position and G28 the exact home switch position.
With THC control ON there is no such thing as max Z vel. THere is only a settable base speed based on a percent of Rapid speed. The Z in THC mode can not even get close to teh Max Vel setting as defined in setup Normally it is about 25% as the fastest useable speed and that is because of teh slap and go event. In that motion the Acceleration is the KEY value not Vel. Most moves are only going to be a micro move anyway so there is really no way to reach MAX vel on each commanded move.
THe CNC plasma cutting process is ALL about constant velocities when cutting and acceleration is KING.
Just a thought, (;-) TP
-
Thanks TP but it only confuses my issue more - I have a subroutine that calls G28.1 as listed below, if I remove the G04 P.0 line I get a short screech from the Z motor like its being told to move fast with no acceleration - the same as setting the Z rate way too high and slapping the motor with a move.
WITH the G04 P.0 line in there it works perfectly.
G91 (switch to incremental mode)
G01 X28.00 Y4.00 F6000 (position probe switch)
G90 (switch to absolute mode)
#15239=1 (this var is monitored by a brain and triggers the probe cylinder)
G04 P0
G28.1 Z5.000 (probe the surface)
G92 Z#15045 (apply the probe switch offset from settings screen DRO)
#15239=0 (raise the probe)
G04 P0.4 (allow the probe to retract before moving or we drag it along the plate)
G91 (switch to incremental mode)
G01 X-28.00 Y-4.00 F6000 (put the axes back to where we came from)
G90 (switch to absolute mode)
M99
%
-
Apart from my little oddity with the G04, I need a little help with control logic - brains etc, here's what it needs...
The variable #15239 / 1239 is set to 1 or 0 by G-code in the probe subroutine, this variable is monitored by a brain which activates/deactivates output2 (extends or retracts the probe)
This works perfectly UNLESS g-code is loading or you do a path re-gen and it runs the code again as it does when loading - this has the effect of slapping the probe up and down multiple times as it reads the subroutine at every call.
So I am looking for a smart way to block operation when its parsing code.
I have tried to use the other output and the variable AND'ed together in the brain, which works BUT not when i do a dry run or drill holes with the torch as output 2 controls my extract fan and that is off when dry running or drilling so that idea fails.
Is there a smart way to do this please???
-
Use while Isloading() to block the function so that when it is loading the file it cannot function. With a brain you should be able to monitor teh Isloading LED. Just thinking off the top of my head.
I am not sure what you mean by dry run. Do you run teh entire program ?? I do use a dry run feature but it only runs teh outside contour of the part to see IF it fits the material and it does NOT run the TOM or fire the torch when it runs.
(;-) TP
-
Apart from my little oddity with the G04, I need a little help with control logic - brains etc, here's what it needs...
The variable #15239 / 1239 is set to 1 or 0 by G-code in the probe subroutine, this variable is monitored by a brain which activates/deactivates output2 (extends or retracts the probe)
This works perfectly UNLESS g-code is loading or you do a path re-gen and it runs the code again as it does when loading - this has the effect of slapping the probe up and down multiple times as it reads the subroutine at every call.
So I am looking for a smart way to block operation when its parsing code.
I have tried to use the other output and the variable AND'ed together in the brain, which works BUT not when i do a dry run or drill holes with the torch as output 2 controls my extract fan and that is off when dry running or drilling so that idea fails.
Is there a smart way to do this please???
why do you need to use a brain.... why not an M-code to trigger the output directly?
-
Use while Isloading() to block the function so that when it is loading the file it cannot function. With a brain you should be able to monitor teh Isloading LED. Just thinking off the top of my head.
I am not sure what you mean by dry run. Do you run teh entire program ?? I do use a dry run feature but it only runs teh outside contour of the part to see IF it fits the material and it does NOT run the TOM or fire the torch when it runs.
(;-) TP
How do you control your dry run? It sounds easier than mine which does the full run with TOM and I had to add code to allow it to run motion without an arc-ok signal ;)
WhileIsLoading - would that work during Regen Path too and where would I use it ? I an using G-gode and brain no macro's :)
-
why do you need to use a brain.... why not an M-code to trigger the output directly?
I started out using a macro but was shown it was better to use g-code and a brain - i'll try and find the thread
Here we go...
http://www.machsupport.com/forum/index.php/topic,31543.0.html (http://www.machsupport.com/forum/index.php/topic,31543.0.html)
-
Thanks, where is the list of #vars?? Can you toggle other things too like OEMbuttons and LED's etc?
Rob
-
There is a list, will see if i can find it, you can do quite a few things with a brain
-
In sheetcam I Changed teh ouside profile to include a line after teh M3 runs. It is the Oword for Gcode subs.
(outside profile)
code
code
M3 (fire the torch)
o549
code
code
etc
Then from a button you use a Trick to directly GOTO teh Oword inside the Gcode program. This only works in ONE direction so there is no need for a return M99 as there is nothing to return to.
Code"M98 P549"
End
The prgram will jump directly to teh Oword(o549) and start running the outside profile . The outside profile is the tail end of the Gcode so when it completes it simply rewinds and is ready to run OR repeat the dry run if needed.
(;-) TP
-
Lets see if i grasped this,
you add a line to the POST to place o549 after the outside profile start, then add a button to your screen that calls that part of the code bypassing the M3
To do a dry run you press your new button and NOT the normal start button??
Sounds way better than my version :)
Its a pain running the full code just to check fit etc.
Edit
I can't find "outside profile" anywhere in the sheet cam post docs, is it available in all posts?
-
YOu have teh idea here is a excert from the Gcode program and the Section where teh Post is modified to add teh Oword. You add teh Post code to teh OnPenDown() section.
N6040 X1.0409 Y9.8085
N6050 G28.1 Z0.50
N6060 G92 Z0.0
N6070 G00 Z0.1370
N6080 G92 Z0.0
N6090 G00 Z0.1200
N6100 M03
N6110 G04 P0.3
o549
N6120 X1.0409 Y9.8085
N6130 G01 Z0.0800 F20
N6140 G02 X1.1015 Y9.9299 I0.0911 J0.0304 F130.0
N6150 G01 X1.1047 Y9.9303 F130
N6160 G02 X1.1475 Y9.9024 I-0.0008 J-0.0480 F130.0
N6170 G01 X1.1496 Y9.8986 F130
N6180 G02 X1.4537 Y9.2508 I-2.1754 J-1.4162 F130.0
function OnPenDown()
if(dist >= (refdistance/scale)) then
dist = 0
-- modaltext (" G00")
-- text(" Z")
-- number (pierceheight * scale, "0.0000")
-- eol()
post.ModalText(" G28.1 Z")
post.Number(zrefslowdown, "0.00")
post.Eol()
post.ModalText(" G92 Z0.0\n")
post.ModalText (" G00")
post.Text(" Z")
post.Number (switchoffset, "0.0000")
post.Eol()
post.ModalText(" G92 Z0.0\n")
post.ModalText (" G00")
post.Text(" Z")
post.Number (pierceHeight * scale, "0.0000")
post.Eol()
else
post.ModalText (" G00")
post.Text(" Z")
post.Number (pierceHeight * scale, "0.0000")
post.Eol()
end
if (preheat > 0) then
post.Text ("\n G04 P")
post.Number (preheat,"0.###")
post.Eol()
end
post.Text ("\n M03\n")
if (pierceDelay > 0) then
post.Text (" G04 P")
post.Number (pierceDelay,"0.###")
post.Eol()
end
if (string.find(operationName, _("Outside Offset") )) then
post.TextDirect("o549 \n")
post.Text (" X")
post.Number (Sline1,"0.0000")
post.Text(" Y")
post.Number (Sline2,"0.0000")
post.Eol()
end
end
-
Brilliant, thats going in for sure :)
BTW, what do these lines do?
post.Text (" X")
post.Number (Sline1,"0.0000")
post.Text(" Y")
post.Number (Sline2,"0.0000")
Obviously they are for X & Y but ??
My guess is that they tell it to run form the current X/Y location??
-
Hmm, if i paste this into my post, i get an error and the post fails???
if (string.find(operationName, _("Outside Offset") )) then
post.TextDirect("o549 \n")
post.Text (" X")
post.Number (Sline1,"0.0000")
post.Text(" Y")
post.Number (Sline2,"0.0000")
post.Eol()
end
Are you running SheetCamTNG ???
-
Ok, did a search and found your original Sheetcam thread :)
You need to add this too...
ADD TO OnRapid()
Sline1 = (endX * scale)
Sline2 = (endY * scale)
Trouble I have now is that it does not recognise the outside offset and just pastes the sub number after every M03
Do you have to manually select the operations in sheet cam as inside and outside ops - it normal does this for me.
Any ideas
Edit...
Yes you do or sheet cam makes all op an outside offset. :(
Means remembering to move the outside cut to a new layer I guess :(
-
I never let Scam assign layers I do that part myself. Scam is a bit weird in some aspects and to me auto layer assignments is one of those things. OF course it could just be me BUT I never have problems if I do that part (;-)
That MAY be some of your weird pig tailing on cuts ??????? IF Scam starts on 1 side then ends on the other ??
(;-) TP
-
Hmm, good points I guess, its a toss-up then of your cool preview method and doing the layering myself OR letting scam do the layering and having to run the full code just for a preview.
I think I might opt for your version.
I need to sort out my probe trigger logic now to stop it firing when it loads code.
-
Scam is suppose to do a good job of auto selecting inside from outside. You may want to have a chat with Les over at Sheetcam about it. I am very much old school and do 99% of layering in teh cad stage (Like one should be doing (;-) ) The I do not have to worry about what Scam will do with it. I only really have 4 layers with artsy stuff.
Inside1 (0)
Inside2 (0b)
No offset (2)
Outer (1)
-
Yes, that would work, i'm not so old-school and tend to go with the software ;)
I have the code in the files now, is this all that goes in the Mach screen button -
Code"M98 P549"
End
Also, back with my control logic....
I tried ANDing the trigger variable from the subroutine with the RUN led - this works fine when you run code, BUT when you load a file or do a regen it STILL triggers the probe - this seems to indicate the logic does not work as the RUN led is most definitely off when loading code.
Any ideas how i can brain logic this into working????
-
You may want to try the opposite of the isloading() >>> File loaded (led) Or figure out WHY your logic does not work. It would seem that it should.
Yes that is all that goes into the button script.
(;-) TP
-
isloading will not go in a brain AFIK, I have no macros, just g-code triggering a #var and brain monitoring it and switching an output IF two values are met - the #var being=1 AND the RUN led being on.
Unfortunately it does not work for some unknown reason, it defies logic which makes it all a nonsense.
-
Here is a thought as wth Arts logic when you mix a true/false with a number it does not always go as one would think. Try it by adding teh two values and using that logic 1+1 = 2 so try IF =2 then run . IF you post your brain I can test it here.
(;-) TP
-
Brain attached :)
As for the logic, I'm even more confused :) Would be great if there was a way of seeing the actual values.
-
Try this brain
(;-)
-
Still studying this ;)
Here is a lump of my code, pretty similar to yours...
N0360 M01 (Paused: Hit RUN to continue)
N0370 X70.475 Y33.450
N0380 M08 (Turn on extract fan)
N0390 M98 (HeightSense.tap)
N0400 G00 Z3.8000
N0410 M03
o549
N0420 X70.4750 Y33.4496
N0430 G01 Z1.500 F1300.0
N0440 S20 (DTHC is ON)
N0450 G01 X66.475 F4100.0
So we jump in at o549 but does theG01 Z... line following not cause issues if a TOM setting has not been done - the Z could be anywhere and will try and reach 1.5
-
OK now it is up to you. First you would have set the Prgram origin X0Y0 like you would for any cut. Then simply set teh Z0 to above the work I set it for about 1 inch above the surface. That way you are well clear of the material and the Z will only raise to 1.5 above that.
(;-) TP
-
Fair enough, hopefully the modded brain will work and that will be it sorted :)
I always tend to try and program machinery and software at work with the proviso that if it can happen it will - like pressing dry run without setting the Z to a safe height first, that was my reasoning for asking, I am slowly learning that Mach and the intricacies of g-code does not play as well as a PLC or software :)
Never hurts to try though;)
-
Now there is nothing stopping you from coding in what you want it to do (;-) BUT for the most part you are just replicating processes that you have already done. I alway set teh point of origin for teh program and z about 1 inch hight to start a program run . It then rapids down to teh reference point of .5 ( G28.1 Z.5) then runs the ref home routine. So really there is no lost time or motion and safety is built in.
For the most part Gcode is a very simple motion language. It is like talking to a 3 years old. For the most part there is NO logic involved for normal cutting. Simply motion commands.
(;-) TP
(;-) TP
-
So do you set your Z at 1" and zero it or does the DRO show 1"
My Z is generally parked at 15mm at the end of every code run as that is more thickness than any metal i would likely ever run so no chance of dumping a thick plate on and running the torch into it ;)
My probe is G28.1 Z5.00 but I never get any slowdown or thats what it seems like, not sure why.
-
Also....
If you have a sheet cam job where you have duplicated and nested the parts, you get multiple o549 entries, I gather this will fail when loaded into Mach3??
Obviously on a nested job like this you would not really want to do a dry run, BUT will Mach load the file with repeated subroutine headers with the same name??
Seems like there really is no easy option when it comes to dry-runs?
-
Try this brain
(;-)
Sorry, didn't work.
I have installed the front-end of Mach3 on my laptop (no lpt driver) so i can mess about with it, I can load a code file and you can clearly see the Output3 LED flashing on and off as the code loads/triggers the output.
Some sort of brain logic failure here?
-
Also....
If you have a sheet cam job where you have duplicated and nested the parts, you get multiple o549 entries, I gather this will fail when loaded into Mach3??
Obviously on a nested job like this you would not really want to do a dry run, BUT will Mach load the file with repeated subroutine headers with the same name??
Seems like there really is no easy option when it comes to dry-runs?
Reply edit time-out is too short!
Not only does Mach accept the multiple sub headers but when you call it, it only runs the last block - pretty smart. :)
-
Dry-Run button script...
I have a screen button and a LED (2244) next to it, I would like to get the button to toggle the LED, when the LED is green it jumps to the subroutine, you press RUN and it runs the subroutine, then turns the LED off and rewinds. If you press the button again when it is on it should turn the led off and rewind.
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
Code "M98 P549"
End
setuserled(2244,0)
End If
Above works but does not extinguish the LED after.
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
Code "M98 P549"
setuserled(2244,0)
End
End If
Above does not light the LED but does jump to the sub.
I know this is all bells-and-whistles stuff but why dumb-down a brilliant product like Mach3 by not making every addition as smart as possible?
Can this be done?
-
HIYA Dave , NOTHING wrong with bells and whistles. They make life easier after you get them working (;-) I have buckets full of them here. That is one of the great things about Mach3 . In most things you are only limited by your imagination.
You were close in your first example (;-) you just ENDED teh program before you turned off teh LED.
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
Code "M98 P549"
End <<<<<<<<<<<--------------- You ended too soon
setuserled(2244,0)
End If
######################
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
Code "M98 P549"
setuserled(2244,0)
End If
End
-
IF By chance it does not turn ON teh LED add in a Wait state to give it time to do teh process before jumping over it. IF you have to add in the Wait after each action line
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
While Ismoving()
Wend
Code "M98 P549"
setuserled(2244,0)
End If
End
-
Hi again, brilliant, will try that.
I have just come in from another play and arrived at the destination by turning the LED off in the M05 macro - same result but different way around it, this also cancels the dry-run LED when you press STOP. Seems I have two options here now - great stuff :)
I also discovered I needed to add this - Code "F3000" before the Code "M98 P549" as unless you have already run some code, there is no feed-rate set and the dry-run runs at about 1mm/min :) adding the F3000 works perfectly.
SO, I was on a roll after that success, I thought I'd add a safety feature and stop the Dry-Run button doing anything at all if the RUN LED is on - pressing dry run while code is paused makes it a bit messy ;)
Easy-peasy I thought, just do this...
If GetLed(804)=0 then
If getuserled(2244) Then
setuserled(2244,0)
Code "M30"
Else
setuserled(2244,1)
Code "M98 P549"
End
End If
End If
Of course that didn't work :( then I got too cold and came in :)
ALSO regarding the Brain Logic Failure issue..
It's NOT a logic failure, I did a brain-view and loaded some code and you can see that when loading code, Mach3 sets the RUN led to ON even though the LED does not illuminate !!!
That is why the probe is allowed to trigger all the time!
Now I need to fine a way to fix it :)
-
When I tested you r brain here teh logic failed due to teh fact that you never created a logic condition to compare to in teh #var value side. Teh led is automatically a boolean value true/false, BUT teh DRO value has to be compared to a value to reach a boolean state. #var = 1 == ON so then you compare the Value against 1 IF #var = 1 then it is true.
IF you use the Brain monitorr you can SEE all the values and the STATE of each lobe of the brain. Not saying it cannot happen but I have never seen a state change without it lighting the LED IF there is one.
You also need to be aware that Mach3 does not always treat the value of the GetLED(804) as 0,1. It can be true ,false, and -1,1 And at times it is NOT consistant. AND I do not know why it does it but I KNOW for a fact it does it. I have spent days in the past tracing values and comparing them. I find it best to always treat it as true,False condition(boolean)
AND again you need to move the END to the actual END of the script in this case.
Just a thought, (;-) TP
-
Hi
Yes I can see the need to create a logic condition, BUT if you create a simple brain that monitors the 804 RUN LED you (should) see the brain trigger while loading code even thought screen LED is off.
Edit...
On my laptop test setup, the RUN LED does indeed come on during code load - thats why it triggers then!!
Now, how do we sort the problem out :)
-
YOU find something else to trigger on (;-)
(;-) TP
-
LOL :)
Yes I figured that but as Mach seems to use the RUN function when loading, presumably to parse the code, there doesn't seem to be much left really, Brains don't seem to have any knowledge of code being loaded which is fair enough,.
I messed around a bit tonight but I can't find a way round this so will likely chalk it up to "can't really be done" and move on, sounds a bit defeatist, but 'net trawling, messing about and your very helpful input have come up blank so maybe it just cant be done??
Maybe, Just maybe, a custom "Load Code" button which sets a #var before starting to load and releases it after might the way??
-
You could look at teh cycles start led.
(;-) TP
-
I had to make a phone call to verify but in all the years I have had the DryRun feature here with plasma no one has every hit that button with a program cutting(;-) IF you find one that does just smack him hard with the Dummy stick a time or too and it will not be a problem again .
Just a thought(;-) TP
-
I had to make a phone call to verify but in all the years I have had the DryRun feature here with plasma no one has every hit that button with a program cutting(;-) IF you find one that does just smack him hard with the Dummy stick a time or too and it will not be a problem again .
Just a thought(;-) TP
LOL :)
Don't forget - Bells-and-whistles :) It's all sort of working now. Applying my database software programming rules to this process tells me that when code is running the ONLY buttons that should be live are STOP and HOLD (I think) all others should be disabled, thats how i tend to go.
BTW If Cycle-Start LED is 804 then that is the one that does NOT work - mach seems to "run" the code as it loads so the value of that led is 1 while loading and running. I need something that is 1 while loading and 0 while running or vice-versa.
-
OH NO DOn't talk system programming to a Gcode machine. It will never be the same again . I think you have done a fine job working with it.
(;-) TP
-
OK I went back and checked teh 804 LED and it is working as it should work. On loading it flashes for about .5 sec and then goes back off . Then it ONLY comes on when you press cycle start(run).
I also checked it in a brain and it works ok there as well.
(;-) TP
-
OK I went back and checked teh 804 LED and it is working as it should work. On loading it flashes for about .5 sec and then goes back off . Then it ONLY comes on when you press cycle start(run).
I also checked it in a brain and it works ok there as well.
(;-) TP
Thats odd, what comparison are you doing in the brain. if any???
-
OH NO DOn't talk system programming to a Gcode machine. It will never be the same again . I think you have done a fine job working with it.
(;-) TP
He he LOL :)
-
In the Brain I brought in the RUN LED804 and passed it straight though as it is already a boolean value . Looking at teh brain veiw when the cycle start is pressed it comes ON and when you stop it goes off. It is NOT on during program load but appears to flash momentarily (.5 sec or so)
Then brought in teh DRO you used and compared that to 1 . Then used an AND for teh 2 inputs to trigger an ouput SO if both inputs are true it works if not it does not activate teh ouput.
I used the brain I sent you to test with
-
Thanks for all this,
I did try that brain and it did not work, I will take it out tonight and try it again as it should really work.
-
When you get that working I still have a large bucket full of Plasma related goodies that most people have never seen.
(;-) TP
-
Excellent stuff :)
I tried the Brain and loaded a job with four duplicated parts, each part has multiple IHS calls and when loading the brain flicked on an off 8 times.
I video'd it, give us half an hour and i'll put a link up - its very odd.
:)
-
Here we go - short video of a file loading :)
https://youtu.be/dhpkBF-zgPw (https://youtu.be/dhpkBF-zgPw)
-
DID you veiw the brain to see what part of teh brain drops out ?? OR simply watch the Cycle Start LED. I a large LED on screen to make it easier to see.
Also download the program you ran. Is there anything in it that can cause teh CycleStart to drop out momentarily ?? Again watch teh LED while it is running.
-
It will about a hour before it will let me veiw it from here. Ill check back later
(;-) TP
-
DID you veiw the brain to see what part of teh brain drops out ?? OR simply watch the Cycle Start LED. I a large LED on screen to make it easier to see.
Also download the program you ran. Is there anything in it that can cause teh CycleStart to drop out momentarily ?? Again watch teh LED while it is running.
In the video you will see the setup, I had the brain viewer and the mach screen up at the same time, the bottom line is the #var and that comes on and off as expected, the top line is the Run LED and that is on 100%
Could this in any way be connected to the screen set being customised for the CandCNC control system??
just clutching at straws :)
-
OK WHY were you tapping teh keyboard ??
(;-) TP
-
OK WHY were you tapping teh keyboard ??
(;-) TP
I most certainly was not :)
The tapping noise was either my teeth chattering or the probe firing on and off ;)
G-Code attached...
-
OK I downloaded the program file and the sub file and the brain AND it all works fine here. Everything fires when it should and doesn't when it should not.
I will say that teh CandCNC program file is severely overloaded with gizmos that don't add to your cutting experience one bit . MOST of that is not needed to run an AIR Plasma CNC cutter. Can you explain what all teh M00 and M01 are all about ?? You may consider doing away with a lot of teh Mcode traffic in the cut file.
NOT that I am picking on you it is that I have never seen that much traffic on the Mcodes in plasma cutting before. And Yes I do use CandCNC products from time to time BUT I eliminate 95% of those special gizmos that have little to no REAL value.
(;-) TP
-
NOW IF you cannot get it to work with your system like you want you MAY consider doing away with teh brain and just use a set of macros to turn the output on /off. That way teh Solenoid will never fire on load IF you have that box checked in config.
OR you can do it all in the macropump where you have access to Isloading() to have it NOT activate while Isloading().
(;-) TP
-
Hmm, Ok, it must be connected to the screens then, thanks for testing it all out.
The M01/M00 are my personal addition (there are a few of them) and it enables me to switch on "Stop on M01" on the screen so it pauses between every cut - most of my stuff is arty farty and tip-ups are very common - this gives me a chance to pull the drop out of the way before the torch slams into it, being a home-shop, material is more important than time so wastage is not in my dictionary.
On simple jobs I just set the optional stop off and let her go. The first M00 is a candcnc thing to give a chance to check your settings before the off.
I might look at macros, maybe its the better job for this task.
I presume I need to pull the #var out of the G-code and replace with a macro call?
Couldn't give us an idea of how to switch could you :)
-
BTW that job i sent is a fiddly SOB, lots of very small square holes etc and its cut in aluminium, i use plenty of sheet cam rules to allow me to cut a square 5mm hole pretty well usually, thats probably why it looks loaded with junk :)
I guess I just need two macros - output on and output off then replace the #var lines in my subroutine with calls to the right macro??
-
Converted to a pair of macros and all working well in the test setup, will try it on the CNC tonight. The macros just call activate or deactivate signal(output3), M1050 & M1051
Also been messing with the screen background today, tidied it up, made the tool path window bigger and deleted some junk. :)
And, I even managed to get the "Dry-Run" button script to not run if the RUN led is on, testing for GetOEMLed(804)=0 and putting that If...Then...End If around the button code did the trick.
-
Fully tested and working 100% :)
The IHS subroutine now looks like this...
G91 (switch to incremental mode)
G01 X28.00 Y4.00 F6000 (position probe switch)
G90 (switch to absolute mode)
M1050 (trigger the probe cylinder)
F1300
G28.1 Z5.000 (probe the surface)
G92 Z#15045 (apply the probe switch offset from settings screen DRO)
M1051 (raise the probe)
G04 P0.2
G91 (switch to incremental mode)
G01 X-28.00 Y-4.00 F6000 (put the axes back to where we came from)
G90 (switch to absolute mode)
M99
%
You may notice that the first G04 P.0 has been removed - since changing to macro's rather than the brain the odd screech disappeared and it does not need the extra P04, I have no idea why but it works. The second P04 is needed as it allows time for the probe to lift clear of the plate before it moves.
Are any of the Abs/Inc switches surplus???
-
The only thing I would change its to add the dwells for the switch motion to the macro 1 for extend and 1 for retract use Sleep(200) after the call to activate/deactivate the switch.
Then remove the G04 from the Sub.
You also need to make SURE that you CAM is going to reset teh Feedrate to programed FeedRate after each Sub Call otherwise the next section of Gcode will run at F1300 Feedrate. Actually I am not sure WHY you are calling teh F1300 in the sub ??? What are you trying to set the feedrate for ??? ALL the moves I see COULD simply be done at RapidRate (G00) and avoid teh posibility of a problem.
-
Thanks, i'll move the delays as described, makes sense.
The F1300 was a thing I was messing with yesterday, I found that if for some odd reason the E-stop was pressed when running code, and then restarted, when it ran the IHS it totally thrashed the Z axis, it didn't move but the noise it made was terrible - way too fast attempt. I think that was the sequence anyway, whatever it was, it really made a mess of a Z move ;)
I flung in the F1300 as i was debugging and left it, i will pull it out again and re-test.
There is a certain sequence of events that can cause the Z to be told to move at a speed way above its programmed max speed. The only sure way to fix is to reload the code, very odd, but the noise really makes you jump :)
-
YOu may also want to consider increasing teh G28.1 intermediate point distance 5mm(.200") is pretty close . Here I use a minimum of .500" . IF you have a wavy piece of metal 5mm may cause switch contact problems ???
Also remember IF you have to hit the Estop that means it requires a complete reset of teh program values to be safe . ESTOP does not mean STOP it means DUMP everything.
Just a thought, (;-) TP
-
I have tried other values in the G28.1 Z********* but it never seemed to slow down, will try again.
Yes i see now, this was when i was testing the probe trigger and many times had to e-stop as the brain didn't trigger the probe and would plant the torch in the slats :) Part of the fun of de-bugging ;)
I will be altering the wiring slightly to move my existing limit switch wire on the Z from limits (which are disabled when G28.1 runs) to the e-stop circuit to give some protection in event of the probe failing to trigger etc. they serve no other purpose now anyway. The actual IHS switch is using the Z limit input and the limits were looped into the X/Y limit loop.
I think that will then close this modification exercise, hopefully finish the bracket to hold the cylinder and start tidying things up this weekend.
-
Teh G28.1 Z value is a way point to get back to home via that point . In this case IF teh tip was touching teh surface it would rapid UP to teh Z waypoint then probe back down to the surface . IF it is already above the waypoint it rapids DOWN to teh way point then further on to teh surface.
(;-) TP
-
Just to make sure it is CLEAR teh first stage of G28.1 routine is made at Rapid feedrate then from teh waypoint to teh switch location it travels at teh predefined value you set up in teh Homeing Config page. THAT rate is a % of rapid rate.
It has NOTHING to do with the Fword call.
-
Learning all the time :)
Having a play with this tomorrow
Thanks
-
Ok here we go...
I can confirm that the Z parameter of the G28.1 code does nothing at all, tried many values and none made any change, the Z does not rapid at all when doing a G28.1, it runs at the value % set for Z in Homing and Limits setup.
Made up the bracket and got that fitted, pictures attached of the final setup. I managed to get the Y-axis shift down to zero and the X-axis shift to 20mm.
A video of it doing IHS and setting to 1mm after. Repeatability accuracy is very tight.
https://youtu.be/Fqn4YaQUq8c (https://youtu.be/Fqn4YaQUq8c)
Have moved the post-probe delay to the probe-off macro now, no delays in the subroutine, also gone back to a straight G00 rapid for the probe offset travel.
Works nice :)
-
You can leave it that way IF you want OR you can change it back to use the initial move. Setup / portPins/Millsetup THC settings , check teh box initial move for G28.1.
Personally I like the initial rapid move, but you have teh choice.
(;-) TP
-
You can leave it that way IF you want OR you can change it back to use the initial move. Setup / portPins/Millsetup THC settings , check teh box initial move for G28.1.
Personally I like the initial rapid move, but you have teh choice.
(;-) TP
So thats the reason :)
I will try that and see which one i like best, thanks.
-
Everything working very nicely now, the new set origin button code is faster and does not mess the DRO's up :)
I also now have the Z rapid to slow position during a G28.1 move.
I think this thread has served its purpose well, thanks go to BR549 for all the help, and to any others who chipped in.
A short video of the final setup making a couple of cuts...
https://www.youtube.com/watch?v=FV6WpuQjFE0 (https://www.youtube.com/watch?v=FV6WpuQjFE0)