THCAD-10 + hypertherm 45 (nonXP)

More
08 May 2018 18:20 - 08 May 2018 19:29 #110395 by bjames28
I have exactly the same situation with SheetCam and the produced g-code.

Attached please find the screenshot, all cuts start at different heights. Attached the relevant sample g-code program and touchoff subroutine.
The issue is, that LinuxCNC "assumes" that each probing with G38.2 Z-30 needs to go maximum depth of 30 machine units (mm in my case) therefore sooner or later, depending on your machine setup the Z height will be too small to accommodate all those probings.

This topic was raised on this forum, and other ones too, but I could not find any solution.
Attachments:
Last edit: 08 May 2018 19:29 by bjames28. Reason: missing "not" in last sentence

Please Log in or Create an account to join the conversation.

More
09 May 2018 04:11 #110407 by islander261
Guys

I am running what I consider to be an Alpha prototype system to run my table, read not yet ready for production use. I am using a THCAD card to measure the arc voltage for torch height control. Look in the general section for Grotius's thread about the external offsets branch and you will find a description of my system. The other day I cut out 3 sheets of parts with 487 pierces per sheet and had none of the problems you are describing. I do have problems ( look in the Gmoccapy section) with the Gremlin preview screen but not what you are describing. I have to fish for the next 3 days and then weekend markets so I can't go into this in depth until this time next week. I will post example of working (but very complex to deal with my system) gcode with probing subroutine. I am surprised by how well it is apparently working at this point. I am sure there are bugs in there I just haven't found the right set of conditions yet. I will get together a simplified version of my probing code without all of the error checking and retries that will be much simpler to understand.

John

Please Log in or Create an account to join the conversation.

More
09 May 2018 23:31 #110471 by andypugh

I have exactly the same situation with SheetCam and the produced g-code.


You could try asking on the emc-users mailing list. The SheetCAM developer is subscribed to that (or was in January)

(That's the LinuxCNC mailing list, it still uses the old name). You can find the subscription information from the "Community" link on the main LinuxCNC web site. (www.linuxcnc.org, link at the top of this page)

Please Log in or Create an account to join the conversation.

More
10 May 2018 01:55 #110482 by islander261
Guys

SheetCam questions are usually dealt with promptly by Les (the SheetCam developer) on the SheetCam Forum. I know most of the questions there are focused on Mach3 and the CandCNC user base but with CommandCNC growing I am sure he is watch LinuxCNC users now.

John

Please Log in or Create an account to join the conversation.

More
10 May 2018 02:16 #110483 by rodw
I have to agree with John. I have not had any problems either.

Why don't you comment out the part in your touch off that turns on the machine torch and waits for arcok and write a loop that calls it from the one X,Y position say 100 times and see if you run into problems. If you don't, it isn't a probing problem.

Please Log in or Create an account to join the conversation.

More
10 May 2018 04:43 #110490 by islander261
Guys

Actually I think the problem is related to to the part origin and how you are setting the Z zero when probing . I just don't have time to look into it this week. There are a couple of significant differences between how I do the touch off and how you are doing it. More details to follow the beginning of next week. If your problem is following error (FERROR) at the end of the cut then you really need to consider using the external offsets branch and tracking the Z position inside the motion component ( there is a real kludgey solution that I have figured out but haven't tested that is very similar to how this is handled in CommandCNC with external THC hardware if you don't want to use the external offsets branch).Think about how you handle machine and part positions on a milling machine (LCNC likes milling machines not plasma cutters).

John.

Please Log in or Create an account to join the conversation.

More
10 May 2018 05:56 #110493 by bjames28
Hello

Thanks all for the reply, I will raise this issue on SheetCam forum for sure.

@islander261: I agree with you, this should be more about how the probing is done and how the absolute& relative coordinates are put together. I just couldn't find out what exact line(s) of code should be written in different way. I'v reviewed and tried at least five touchoff routines posted on forums, but none of them seemed to solve the issue.

Please Log in or Create an account to join the conversation.

More
11 May 2018 03:07 #110560 by islander261
Guys

Here is what I am doing. First I use two coordinate systems. The machine coordinates set against homing switches at startup and second the work piece set as G54 offsets. In the mainline Gcode I move the torch to what I call the W height from what it is called on my mill, I think the more universal term is safe Z. Then I call my probe_sheet3 sub routine. Next is a simplified version without all of the error checking and retries.
o<simple_sub> sub
M64 P0    (enable probing power supply, relay)
F#<probe_rate>
G38.3 Z-[#<probe_dist>] ( probe down to material surface)
G91
G01 Z-.005   ( push down a little to insure good contact, float switch provides compliance)
G90
M66 P3 L0 Q0 (check for source of probing signal, contact or float switch)
o106      if[#5399 EQ 1]
              (probe was triggered by z-min so we need to add switch offset)
              #<probe_source_flag> = 1
o106      else
              #<probe_source_flag> = 0
o106      endif
F [#<probe_rate>/16]
G38.5 Z1     (raise torch until contact is lost)
o107      if [#<probe_source_flag> EQ 1]
o108           if[EXISTS[#<_ini[axis_z]float_sw_offset>]]
                  G92 Z -[#<_ini[axis_z]float_sw_offset>]
o108           else
                  G92 Z -.06
o108           endif
o107      else
          (set part Z 0)
          G92 Z 0.0000 
o107      endif
M65 P0  (disable plate sensing)
o<simple_sub>  endsub

I then take care of moving to pierce height and firing the torch in the mainline Gcode. I hope this helps with the probing problems. The attached file does have unexplainable (to me) problems displaying in Gremlin preview. The o<endcut> subroutine does nothing at this point, it is just a place holder left over from an external THC or not using the external offsets branch. I have cut several sheets out using this code so I know it works.

The attached Gcode file produces copyrighted parts so please respect my IP, it is how I eat. I am providing it as an example to the community of a complex file that works.

I will post the SheetCam PP that produced this code later when I am on my design machine.

John
Attachments:

Please Log in or Create an account to join the conversation.

More
11 May 2018 03:26 #110562 by islander261
Guys

Please find attached the SheetCam PP that produced the previous G code example. This is a work in progress so it will change.

John
Attachments:

Please Log in or Create an account to join the conversation.

More
11 May 2018 07:59 - 11 May 2018 19:31 #110571 by bjames28
Hi John,

Many thanks for the files you provided.
I went to the shop and quickly loaded the files to my plasma computer.

It worked!! (after some small tweaking, see my comments below). Now all cuts are on the same height level. Excellent. I had no time to analyze what do you do different, but in the evening Ill spend time on it.

I also installed the PP you sent.

There is one "inconsistency" with the multipleif..then..else nesting which originates from PP, and this caused an error when I wanted to load your gcode file to LinuxCNC. I found that one extra o010 else

Please find below the relevant part of gcode with added indents for better readability:
o020 if[ #<_firstTime> EQ 1 ] 
		o010 if[ EXISTS[#<_hal[plasma_tab.use_control_params]>]] 
			o011 if[#<_hal[plasma_tab.use_control_params]> EQ 1]
			 
				o012 if[ EXISTS[#<_hal[plasma_tab.g0-gap]>]] 
				        #<_g0-gap> = #<_hal[plasma_tab.g0-gap]> 
				o012 else 
			                #<_g0-gap> = 20.000 
				o012 endif
				
				
			
				o013 if[ EXISTS[#<_hal[plasma_tab.pierce-gap]>]] 
                                        #<_pierce-gap> = #<_hal[plasma_tab.pierce-gap]> 
				o013 else 
					#<_pierce-gap> = 8.000 
				o013 endif 
				
				
				o014 if[ EXISTS[#<_hal[plasma_tab.cut-gap]>]] 
                                        #<_cut-gap> = #<_hal[plasma_tab.cut-gap]> 
				o014 else 
					#<_cut-gap> = 6.000 
				o014 endif
				
				
				o015 if[ EXISTS[#<_hal[plasma_tab.pierce-delay]>]] 
                                        #<_pierce-delay> = #<_hal[plasma_tab.pierce-delay]> 
				o015 else 
					#<_pierce-delay> = 1.000 
				o015 endif
				
				 
				o016 if[ EXISTS[#<_hal[plasma_tab.w-gap]>]] 
                                        #<_w-gap> = #<_hal[plasma_tab.w-gap]> 
				o016 else 
					#<_w-gap> = 10.000 
				o016 endif 
				
                        ( __SUSPICIOUS extra line:__o010 else )
                        
			o011 else 
				(Use values from SheetCam Below) 
                #<_g0-gap> = 20.000 
                #<_pierce-gap> = 8.000 
                #<_cut-gap> = 6.000 
                #<_pierce-delay> = 1.000 
                #<_w-gap> = 10.000 
			o011 endif
			
			
		o010 endif 
  #<_firstTime> = 0 
  o020 endif

I marked SUSPICIOUS the extra line.

I needed to create an empty endcut subroute, because there was a reference in your code. I don't know what is the purpose of this sub in your setup.

When I commented out the line 774 in PP file, the code is loadable without errors.

Thanks you very much for your help!

Regards
Janos
Last edit: 11 May 2018 19:31 by bjames28. Reason: correcting typo

Please Log in or Create an account to join the conversation.

Moderators: snowgoer540
Time to create page: 0.183 seconds
Powered by Kunena Forum