Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: Davek0974 on December 26, 2015, 04:50:04 AM
-
I'm looking at testing a new initial height sensing method on my plasma table, it currently uses G28.1 I think and the Z-limit as the response input from the floating z switch.
I want to trigger the Aux-B relay before lowering the Z to probe and release Aux-b relay after a good probe.
SO the sequence would be
Probe request,
Trigger Aux-B relay
Lower head until Z-Lim is tripped
Lift head back to safety height
Release Aux-B relay
Lower head to pierce height
Continue to M3 etc
Trouble is, while i can do the mechanicals, i have little knowledge of how to achieve the control in my case.
I can tweak the G-code post processor in sheet cam pretty well though :)
Any tips?
-
I think this maybe all done in the post-processor, been playing with code and can do this (lines marked ********* added)
N0210 G00 X36.000 Y17.475 Z15.000
N0220 M900 (Check for Z active)
N0230 M08 (Turn on extract fan)
N0240 M07 (Insert probe switch) ***************
N0250 G28.1 Z3.00 (Start Touch-Off )
N0260 G92 Z0.0
N0270 M09 (Retract probe switch)**************
N0280 G00 Z3.400 (Switch Offset Lift)
N0290 G92 Z0.0
N0300 G00 Z3.8000
N0310 M03
N0320 G01 Z1.500 F1300.0
N0330 S20 (DTHC is ON)
N0340 G01 Y11.475 F4100.0
......
I think that will do it, it retracts the probe before lowering the head to pierce height i think.
Might need some short delays adding but testing will prove that.
Might work????
-
BTW The idea is to fire an air cylinder to insert a small, very accurate switch under the plasma tip to sense plate height without pressing down on the plate and causing it to deflect.
-
someone has just replied over on the sheet cam forum about placing all his touch-off code in a custom macro, the post then only has the one macro call and any changes to switch offset only need making once in the custom code.
trouble is, this was on a linux build, can this be done in a custom mach macro in the same way i.e the g-code calls a custom macro and waits for that macro to do the touch - off???
never done any stuff with macros really.
-
Am i on the right tracks here or not...
Custom ref macro M1100.m1s copied from another macro mostly.
Dim Switchoffset
Switchoffset = GetOemDRO(1045)
If Switchoffset > 0 Then
Code “M07”
Code "G28.1 Z3.000"
Code "G92 Z 0.000"
Code “M09”
Code "G00 Z " & Switchoffset
Code "G92 Z 0.000"
While IsMoving()
Wend
Else
MsgBox("Your Switch Offset value in MACH needs to be set")
Code “M30”
End If
Can i use the M07/9 macro within another macro or do i need to use something like ActivateSignal(????) instead to put the mist coolant o/p on & off?????
When called from the g-code file, will the g-code wait until this macro is complete??
-
OK from the top. IF you are to fire a solenoid to position a very sensitive switch to detect the metal surface (TOM)then the motion ACTION of the solenoid will more that like trip your sensitve switch(Been There).
It is NOT a good idea to use M7 M8 M9 as they are interrelated and if you turn on M8 then M7 and tried to ONLY turn off M7 with M9 you end up turning off M8 as well.
Yes it is BEST to do all the needed TOM (Top of Material) functions from a macro. There are several advantages on being you have all the needed code in 1 place and you can modify it once and it is a gobal update. Also RFH ( run from here) works very well as the motion Gcode G28.1 does NOT run from a macro when the RFH is called. BUT sometimes Mach3 can pitch a witch with running Mcodes So it is all a tradeoff.
You may want to consider Ohmic touch off and use it with teh Z switch as a combined backup IF the ohmic misses then the Zswitch will kick in. OR in your case if you use the 30A consumables then it can simple run from the Zswitch . OR you can use a combination of ALL that and still have your solenoid lower a probe tip for the ohmic side.
The ideal way would be to create a function to minimize mixing Gcode and macro script in a macro. Do as much Motion in straight Gcode as you can and not have it run inside the macro. YES that sounds mixed up as I say earlier that doing teh function is better from a Mcode BUT mach3 can be a funny bird sometimes (;-) It all depends
Yes it always a bad idea to call a macro from inside of another macro you can run into timing issue with Mach3. There is a WAY to run outside script code from inside of a macro that does not involve calling teh Mcode. It is only doable in the later versions of Mach3. Check teh Mach3 CB programers manual for details.
NOW to add to the confusion The more that you hybridize the function the harder it is to deal with in the real world of program useage. You would never be able to share any of your Gcode OR use other's Gcode to run on your table.
I am willing to help you in any way I can so you can try all your options (;-)
(;-) TP
-
One way around teh switch being effected by motion is to just use the solenoid to swing a transfer bar into play between the material and the switch. That way the switch never moves only the transfer bar does.
Also a way to keep more direct Gcode into play would be to use a SUB routine to hold the motion code for teh TOM routine and call it as a SUB (M98) . Subs are very stable in Mach3. You would store teh SUB in teh SUB directory and call it as needed .
(;-) TP
-
Thanks for that, some great tips there,
There is a logic to my reason for experimenting here -
1 - I was going to buy an Ohmic kit for my table until i realised they will not work on the 30A consumables on my PM45 as the nozzle is not shielded so no ohmic contact to connect with the plate surface.
2 - It was suggested to fudge a contact for the 30A setup by adding a contact or stud, but as the cut height is a mere 0.5mm here this sounds a recipe for pulling the torch off mid-cut.
3 - Then i found a capacitive height sensor - this looked good but only went to 1mm min and would likely not be too happy about sensing near the edge with half the sense ring having no metal below, plus the accuracy was listed at +/-0.5mm so not that good.
4 - I like experimenting ;)
The solenoid was just a suggestion, my favoured device would be a small air cylinder - these can be controlled, damped, etc so no need to ram it in and out, you can also have a nice controlled in-stroke and rapid return easily. Air is on hand nearby so seems an ideal choice, a 50mm stroke ram at 45deg should give clearance to the torch when cutting i think.
My M1100.m1s looks like this now
Dim Switchoffset
Switchoffset = GetOemDRO(1045)
If Switchoffset > 0 Then
ActivateSignal(Output2)
Code "G28.1 Z3.000"
Code "G92 Z 0.000"
DeActivateSignal(Output2)
Code "G00 Z " & Switchoffset
Code "G92 Z 0.000"
While IsMoving()
Wend
Else
MsgBox("Your Z Switch Offset value in MACH needs to be set")
Code “M30”
End If
I think that gets the important bits in the right places and does away with the M-code for relay control.
Is there a code to replace the M30 with?? Or just ignore that one??
Might need a short delay here and there, who knows?
I'm not too worried about sharing code, my post processor is already heavily tailored to my system anyway, if i needed to share i could just send the dxf file.
-
One way around teh switch being effected by motion is to just use the solenoid to swing a transfer bar into play between the material and the switch. That way the switch never moves only the transfer bar does.
Also a way to keep more direct Gcode into play would be to use a SUB routine to hold the motion code for teh TOM routine and call it as a SUB (M98) . Subs are very stable in Mach3. You would store teh SUB in teh SUB directory and call it as needed .
(;-) TP
Thanks again, post overlap there;)
How do subs work in practice?
I see I have a subroutines folder in Mach, it has one testfile in it but how does the M98 call it??
any examples of the flow from sheet cam to mach??
-
Hmm, mostly guesswork here...
I have a subroutine file called HeightSense.tap in the subs folder of Mach
I have a custom macro M1101 which has one line - ActivateSignal(OutPut2)
I have a custom macro M1102 which has one line - DeActivateSignal(OutPut2)
The HeightSense.tap file contains this....
M1101
G28.1 Z3.000
G92 Z 0.000
M1102
G00 Z my switch offset goes here
G92 Z 0.000
Am i getting there?
I gather you cannot access the switch offset DRO from g-code?
The main part g-code would then be like
N0200 M00 (Paused: Check the DTHC Settings Hit RUN to continue)
N0210 G00 X11.000 Y7.475 Z15.000
N0220 M900 (Check for Z active)
N0230 M08 (Turn on extract fan)
N0240 M98 (HeightSense.tap)
N0250 G00 Z3.8000 (set pierce height)
N0260 M03
-
You have the general idea with teh SUB. Yes you CAN access the Values of a range of DROs through Gcode directly with #vars in the Gcode (;-).
There is a list here on the site somewhere I will look for it again. This comes up about every 2years or so (;-).
What exactly are you checking for in teh M900 ?? To see IF teh Z switch is stuck on ?? I would do this in teh M3 macro and eliminate teh M900 all together.
As to making the ouput active yo MAY want o consider doing this from Gcode and use a simple brain to do teh switching eliminating 2 more macros.
Simply have the Gcode Set a #var to either 0 or 1 and have the brain watch that dro # that is matched to teh #var. That range should work both ways modify either one and it updates the other.
Now you have eliminated any problems or delays that you could run into from using Mcodes .
Just a thought, (;-) TP
-
Dave if it helps the OEMdros 1000 - 1255 as supposed to be mapped to #Vars 15000 -15255.
(;-) TP
-
Thanks for that, i will now need to read up on brains and #vars ;)
this is a post modded by CandCNC for their MP3000-DTHC2 system, the odd thing is M900 does not exist in my running Mach setup so I can only guess it does absolutely bugger all??
I did a search through my backup archive and i did find a M900.m1s - it has this in it
'code to stop a touch off if the Ohmic is stuck on
if IsActive(_8_) then
Response = MsgBox ("Touch - Off sensor jammed. Clear and hit RUN to continue ", 4 , "Clear Z Jam")
code "M00"
end if
but i don't use the post it was related too, might be some post code overhang from another version?
I guess it checks input 8 to see if it is on at the time it wants to start IHS and stops if so???
I had to modify the input number as bracket-eight-bracket seems to convert to a smiley :)
Might be easier to pull the code from the post to tidy up a bit?
So my HeightSense.tap now looks like...
#???? = 1
G28.1 Z3.000
G92 Z0.000
#???? = 0
G00 Z#15045
G92 Z0.000
M99
%
Need to find an unused DRO number for the brain to monitor
-
Thanks for that, i will now need to read up on brains and #vars ;)
this is a post modded by CandCNC for their MP3000-DTHC2 system, the odd thing is M900 does not exist in my running Mach setup so I can only guess it does absolutely bugger all??
I did a search through my backup archive and i did find a M900.m1s - it has this in it
'code to stop a touch off if the Ohmic is stuck on
if IsActive(_8_) then
Response = MsgBox ("Touch - Off sensor jammed. Clear and hit RUN to continue ", 4 , "Clear Z Jam")
code "M00"
end if
but i don't use the post it was related too, might be some post code overhang from another version?
I guess it checks input 8 to see if it is on at the time it wants to start IHS and stops if so???
I had to modify the input number as bracket-eight-bracket seems to convert to a smiley :)
Might be easier to pull the code from the post to tidy up a bit?
So my HeightSense.tap now looks like...
#? = 1
G28.1 Z3.000
G92 Z0.000
#? = 0
G00 Z#15045
G92 Z0.000
M99
%
Need to find an unused DRO number for the brain to monitor
-
Ok, getting there now,
I have this as a Subroutine "HeightSense.tap"
#15239=1
G04 P0.5
G28.1 Z3.000
G92 Z0.000
#15239=0
G00 Z#15045
G92 Z0.000
M99
%
And the G-Code looks like,
N0190 M09 (Turn off extract fan)
N0200 M00 (Paused: Check the DTHC Settings - Hit RUN to continue)
N0210 G00 X36.000 Y17.475 Z15.000
N0220 M900 (Check for Z active) **this line will be removed soon - does nothing
N0230 M08 (Turn on extract fan)
N0240 M98 (HeightSense.tap)
N0250 G00 Z3.8000
N0260 M03
I tried to use a screen OEM LED numbered 1239 so i had a bit of bling but it would not work so i gave up on that and altered the brain to switch the output directly from the #15239 value and it works, the output has a button and LED on my screen anyway so i do get a little feedback as to where its at. I think this was the right way to go anyway as it's simpler.
One query - I pulled the var 1239/15239 from thin air - is there a way to see if vars are already used??????
As the G-code loads you can see it run the macro at each call so I guess thats good?
The brain was the easy part, almost ladder-logic and i'm used to that from PLC programming.
Hardware changes next, this will have to wait until I return to work as all my pneumatic stuff is there :( unless i get desperate and drive in to pick it up ;)
From measurements, a 40mm stroke cylinder at 45deg will give plenty of safety clearance when retracted, 10mm bore is plenty as no power is required, it can easily be bolted to a bracket using bolts already in place on the floating head - this makes it an easy task to fit and remove if it fails.
As it stands right now I still have made massive improvements I think as the probing and IHS is now relative to the machine and NOT the g-code so any mechanical changes will mean not having to recreate my stock code files over - nice :)
Thanks for the guidance, especially at this time of year, been a fun project so far.
-
One thing i have just noticed is that as the code is loaded, it triggers the probe output as it is scanned clearly a bad thing,
I think i need to add an additional condition to the brain but what is best to monitor???
-
Ok need more help here :(
been messing with the brain, i want to activate output3 only if #var15239 is = 1 AND the run led is on i.e. not loading code etc.
I have tried many variations and nothing seems to work here, I had two inputs - #15239 & LED804 then a >0 comparator on each then an AND then the output3 but this does nothing at all.
Any brain guru's around??
Can't be that complicated surely?
-
Sorted it, couple more hours of reading and testing and it works perfectly if you use the pass-thru option and don't do any comparative ops on the signals.
input1)
) -->Pass-thru--> AND --> output
input2)
-
For the most part you can look in the screen editor to see IF you have used OEMDROs 1000 -1255 as these are tied to #vars 15000 - 15255 internally. Also you will figure out soon enough that you cannot reference from a macro #vars 15000 - 15255 with GetVar or setvar. Art stopped allowing you to access them at about 13000 from CB. BUT you still can use Code" #15000 = XX" to set those VARs from a macro if you need to.
Soon enough you are going to figure out that you can do most of the CandCNC stuff without all the CandCNC stuff and even a bit MORE they don't want you to know. (;-)
(;-) TP
-
Thanks TP,
I will double-check the screen editor for the used DRO's as suggested just to make sure.
I have no idea why that M900 was there as there was no M900 macro so i guess it was just skipped by Mach. For the most part the CandCNC stuff works well, I won't recommend them anymore due to an issue I had previously which they did not help me out with satisfactorily and even tried to extract more money from me to replace stuff that was not faulty.
Anyway, i think what i have in place now is an improvement and when I add the new hardware it may be better or not but at least how it is now makes making changes far easier.
-
Good Job Dave, If you ever get interested I have been working with a UCCNC unit(UC300) it has a LOT of native I/O(5 ports full plus an analog port) including analog in and out. It is already is a good Plasma controller . I hope that it gets even better in the near future (;-)
Cand CNC does have good basic hardware they just went WAY overboard and made a lot of it over complicated for the average user. And they went way overboard on manuals.
(;-) TP
-
Almost there now, I need to sort out how to trigger the probe when I am in "dry run' mode as otherwise it just crashes the Z into the plate :(
Currently the probe control valve circuit is only live if two parameters are met -
The user variable 1239 must be = 1 (this is controlled from g-code)
The Extract fan (output 1) is turned on (this stops the probe from triggering as the G-code is loaded into mach as it only comes on during a live run)
So I thought add another brain that triggers the output if the 'Dry-Run' LED (UserLed 2244) is lit AND the Run LED is lit but it did not work.
Is there a way to achieve what i need here easily??
Can you run two brains against one output??
-
This has been resolved now, the final solution is here...
http://www.machsupport.com/forum/index.php/topic,31649.80.html (http://www.machsupport.com/forum/index.php/topic,31649.80.html)
:)