Great input!
Thank you both for your suggestions. I will incorporate them into my file.
Greetings! Thank you Mike for putting this program together. I just got my first Crossfire and am trying to get things dialed in, so this will come in quite handy. I’m new to this, so please correct me if I’m wrong, but I noticed a couple calculations that seem anomalous in the g-code (or at least won’t always function as intended).
First, the calculation for #108 (height of cutout), will only work with the exact line spacing of 0.25" and a outside offset of 0.5"–using any other values will not give you the outside perimeter you desire. For example, let’s just be silly and say that you want a line spacing of 10" with a 1" border around the outside. As written, that makes #108 = 10" spacing * 10 lines +10" spacing +1" outside offset. Which equals 111" for the height of the cutout. However, 10" * 9 (the actual first line to last line spacing) equals 90". Thus, 111" - 90" equals 21", and due to how the program executes, it puts the expected border at the bottom, and the remaining 20" at the top! Not quite what was expected. I believe, if instead it was calculated with #108 = [[#103 * [#105 - 1]] + [#106 * 2]], this should work with your existing variables to always give the proper height of the cutout.
Second, and not really an issue of function, is the length of the cutout, #107. When initially calculated, you only add the outside offset (#106) for one side, which requires it to be added again whenever you use the variable later in your program. At least, I don’t see anywhere that #107 is used without also adding #106 to it. Thus, when initially set up, you could just make #107 = [#104 + #106 + #106], and then you only have to use #107 by itself everywhere else in the program.
Finally, the center feed rate value will only get used during the test if you’re cutting an even number of lines. Not a big deal if you’re aware of it before hand, but this also means that the value is never actually the center of the range of test cuts. For example, if you only want to cut 3 test lines, increasing the feed rate by 10 each cut, and you choose a center feed rate of 100, you end up with a starting feed rate (#109) of 85. This means your three lines will be cut at feed rates of 85, 95, and 105 respectively (which aren’t technically centered around 100). The center feed rate would then only get used to cut the outer perimeter. Changing the number of lines to an even number, say 4, results in a starting feed rate of 80, and subsequent cuts at 80, 90, 100, and 110. Also not centered around 100, but now that value is at least used on one of the test cuts. So again, not necessarily a problem, as long as one is aware of this behavior ahead of time.
Sorry for the long post, and forgive me if I’m interpreting the code wrong, or if these issues have already been addressed (I’m referencing the CalSteel16b.tap file). It’s been a great starting point in helping me get my machine set up, so it’s much appreciated!
Just a heads up, this didn’t work for me. I had to save as: “filename.tap” using start and end quotes
FWIW, you can download versions of this from github at https://github.com/TomWS1/CrossFire/tree/master/Lotos%20LTD5500D/CalibrationG-Code
I’ve updated them since, but these should be close.
3 Likes
Wow! …this is EXCELLENT and will be super useful as I setup my machine. Much thanks to all the contributors!
Can this be used on the CFP or is it Mach 3 only?
try it…it is a TAP file
As @toolboy points out, the files are G-Code files so should work on any system. The only thing that is not in the code that you may need to add is the IHS code needed to set Z. I would not enable THC as they are short cuts and you want to make sure you’re working with a constant height to determine the correct cutting parameters.
2 Likes
Yeah, I tried it yesterday, but it kept giving a “No Cut Speed Found” error. When I get back to the house I’ll post the file I used.
That file relies on local variables and subroutines to increment to each test cut. It may be that FireControl doesn’t recognize the local variables in the G-Code. Does anybody know if this is true or not? Didn’t think of this…
Adding @langmuirsystems to the question.
1 Like
Below is what I tried on a CFP with THC.
(Langmuir CrossFire)
(This file is for testing cutting feed rates for Mild Steel, 16Ga, using variables in the values below)
( Cutter conditions: 30A, 50PSI, Expected IPM: 100)
(original posted by Mike_C on CrossFire Forum, Dec. 26, 2019)
#100 = 100 (Center Feed rate - extrapolated from 16GAa test)
#101 = 5 (Feed Rate Increase per test cut)
#102 = 0 (Y Starting position)
#103 = .25 (Y axis incremental move per cut)
#104 = 5 (X axis length of test cut)
#105 = 10 (Number of test lines to cut)
#106 = .5 (Outside cut offset)
#107 = [#104 + #106] (Length of cutout)
#108 = [[#103 * #105] + #103 + #106] (Height of cutout)
#109 = [#100 - [#101 * [#105 / 2]]] (Starting Feed Rate, center_feed_rate-feed_rate_increment*number_of_test lines/2)
#120 = .1 (Start Pierce Delay in Seconds)
#121 = .1 (Main Pierce Delay in Seconds)
G90
G70
(2D Profile1)
#102 = [#106] (Y start of first test cut)
#104 = [#104 + #106] (X start of first test cut)
G0 X[#106] Y[#102]
M3
G4 P[#120] (Starting Pierce)
G1 X[#104] F[#109]
#109 = [#109 + #101] (Incremental Feedrate)
M5
#102 = [#102 + #103] (Incremental Y Move)
G0 X[#106] Y[#102]
M98 P0001 L[#105-1]
(Cutout)
G0 X-0.1 Y[#108]
M3
G4 P[#121]
G1 X[#107+#106] Y[#108] F[#100] (Cutout uses Center Feed Rate)
X[#107+#106] Y0
X0 Y0
X0 Y[#108]
M5
M30 (End Of Program)
(Sub Program)
O0001
M3
G4 P[#121] (Dwell in Seconds)
G1 X[#104] F[#109] (slots use accumulating feedrate)
#109 = [#109 + #101] (Incremental Feedrate)
M5
#102 = [#102 + #103] (Incremental Y Move)
G0 X[#106] Y[#102]
M99
%
I do not has crossfire, and have not looked into it either to see if it supports macros and variables. Its possible that it might just need different formatting in the variables?
I looked at some other G code that my CFP runs and there are differences. I’m not proficient enough with G code to quantify the differences, but they are there.
Well, it would be really nice if @langmuirsystems commented on whether FireControl recognizes G-Code setting and using variables and supports subroutines. The code can be easily modified to get around the subroutine implementation, but the variables are used to tweak the cuts on each pass and that is key to finding the correct operating parameters.
1 Like
Hi guys, sorry to bring up a dead thread….just wondering if anyone learned any new information in regards to getting this amazing program to run in cfp? I searched high and low and found about a thousand different posts pointing to the original program/mach3, but nothing regarding running in cfp. I don’t know anything about code, but I’d be more than happy to provide some easy/basic nc files that are formatted for cfp or anything else I can do to help.
I’ve been doing this manually with the “straight cut” feature in firecontrol but a program would save so much time.
It would be trivial to convert to FireControl EXCEPT that it relies on ‘subroutines’, something Mach3 and other CNC systems do, but not FireControl that I’m aware of.
It could be done in Firecontrol, but in a different way. If you and others are interested, I can take a stab at it. If Firecontrol can handle variables, then it should be pretty easy. If Firecontrol can’t handle variables then it becomes rather unwieldy as multiple lines would need to be edited for each material test.
@langmuir-daniel does Firecontrol support variables in G-Code?
1 Like
I have been using a test coupon from Fire share.
In fire control you can change the cut speed manually as a percentage of the program cut speed.
If you set the cut speed of the program to 100 the math is easy to change the cuts in 5ipm increments. I just change the speed after each cut.
There is probably a better way to do it but it has worked for me.